4GB Limit of Microsoft SQL Server Mobile Edition

Use this forum if you have installed hMailServer and want to ask a question related to a production release of hMailServer. Before posting, please read the troubleshooting guide. A large part of all reported issues are already described in detail here.
Post Reply
Melibokus73
Normal user
Normal user
Posts: 87
Joined: 2009-06-26 20:13

4GB Limit of Microsoft SQL Server Mobile Edition

Post by Melibokus73 » 2009-07-16 15:28

What happens if I some time reach the internal 4GB limit of the default Microsoft SQL Server Mobile Edition included in hMailServer 5.x

Does somthing bad happen? Do I get a warning before ?

Keba
Normal user
Normal user
Posts: 126
Joined: 2009-04-11 11:43

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by Keba » 2009-07-16 15:57

Given the database holds meta data and not the actual messages (they are stored on disk as individual files) you will be very hard pressed to reach the 4 Gb limit...

Normal operational monitoring should be put in place if you are creating that much database information, and that would catch the database growing near its limit. You could then 'upgrade' to a database engine that doesn't have a 4 Gb limit I guess.
Keba

Melibokus73
Normal user
Normal user
Posts: 87
Joined: 2009-06-26 20:13

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by Melibokus73 » 2009-07-16 16:14

Keba wrote:Given the database holds meta data and not the actual messages (they are stored on disk as individual files) you will be very hard pressed to reach the 4 Gb limit...

Normal operational monitoring should be put in place if you are creating that much database information, and that would catch the database growing near its limit. You could then 'upgrade' to a database engine that doesn't have a 4 Gb limit I guess.

I did read that this 4GB should be reached with about 10Million Mails. In a office with some users that should be not a so far Limit.

How do I have an easy look how big or full my SQL database is?

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by martin » 2009-07-16 16:19

Use a "real" edition of Microsoft SQL Server if you expect to store more than a million messages on the server.

To determine the database size, look at the SDF file in the \hMailServer\Database folder.

Melibokus73
Normal user
Normal user
Posts: 87
Joined: 2009-06-26 20:13

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by Melibokus73 » 2009-07-21 08:38

martin wrote:Use a "real" edition of Microsoft SQL Server if you expect to store more than a million messages on the server.

To determine the database size, look at the SDF file in the \hMailServer\Database folder.

OK .. but I plan to use MySQL.

Some (Dummy) questions ;-)
What should I use as Database engine? MyISAM or InnoDB ? and what default Characterset ?

^DooM^
Site Admin
Posts: 13861
Joined: 2005-07-29 16:18
Location: UK

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by ^DooM^ » 2009-07-21 09:29

Depends how busy your server will be.
Shiloh wrote:Generally speaking, either use MSSQL2005 or MySQL5 with InnoDB style tables. Either of those will perform well. Just pick the one you have the most experience using. If you use MySQL, do not use MyISAM style tables, because those do table level locking. Table level locking is great for small tasks, but does poorly on large DBs. If you use MyISAM tables, you will wish you had used InnoDB at some point in time as your DB grows. So use InnoDB when you start if you use MySQL.
If at first you don't succeed, bomb disposal probably isn't for you! ヅ

User avatar
martin
Developer
Developer
Posts: 6834
Joined: 2003-11-21 01:09
Location: Sweden
Contact:

Re: 4GB Limit of Microsoft SQL Server Mobile Edition

Post by martin » 2009-07-21 10:45

If you're using MySQL, use InnoDB. Do not use MyISAM.

Even if performance isn't a problem, MyISAM tables does not support database transactions. hMailServer uses database transactions when updating the database to newer versions. Without transactions, there's a risk that the database gets in a state between two different versions. Of course, backups should always be taken prior to upgrading but still..

Post Reply