Like most SQL Server users I'm rather frustrated by Microsoft's insistence on making the really cool features only available in Enterprise Edition. And it really doesn't help that they changed the licensing for SQL 2012 to be core-based, so now it's like 4 times as expensive! It almost makes you want to go with Oracle. That, and a desire to have Larry Ellison do things to your orifices.
If that statement returns true, it fails. (the print statements are just placeholders) Go ahead and test it on Standard, Workgroup, and Express editions compared to an Enterprise or Developer edition instance (which support everything).
Once again thanks to Argenis Fernandez (b t) and his awesome sessions on using Sysinternals, I was able to watch the exact process SQL Server performs when setting up a mirror. Surprisingly, it's not actually implemented in SQL Server! Some of it is, but that's something of a smokescreen, the real meat of it is simple filesystem primitives.
The NTFS filesystem supports links, both hard links and symbolic, so that you can create two entries for the same file in different directories and/or different names. You can create them using the MKLINK command in a command prompt:
This creates a symbolic link from my data and log folders to my Skydrive folder. Any file saved in either location will instantly appear in the other. And since my Skydrive will be automatically synchronized with the cloud, any changes I make will be copied instantly (depending on my internet bandwidth of course).
So what does this have to do with database mirroring? Well, it seems that the mirroring endpoint that you have to create between mirror and principal servers is really nothing more than a Skydrive link. Although it doesn't actually use Skydrive, it performs the same function. So in effect, the following statement:
The 5022$ "port" is actually a hidden system directory on the principal and mirror servers. I haven't quite figured out how the log files are included in this, or why you have to SET PARTNER on both principal and mirror servers, except maybe that mklink has to do something special when linking across servers. I couldn't get the above statement to work correctly, but found that doing mklink to a local Skydrive folder gave me similar functionality.
One wrinkle you will encounter is that the mirror server will show the data and log files, but you won't be able to attach them to the mirror SQL instance while they are attached to the principal. I think this is a bug in the Skydrive, but as it turns out that's fine: you can't access a mirror while it's hosted on the principal either. So you don't quite get automatic failover, but you can attach the files to the mirror if the principal goes offline. It's also not exactly synchronous, but it's better than nothing, and easier than either replication or log shipping with a lot less latency.
I will end this with the obvious "not supported by Microsoft" and "Don't do this in production without an updated resume" spiel that you should by now assume with every one of my blog posts, especially considering the date.
We are about to roll out a dual web/internal transactional application where each client has their own database. Each database is very small - under 50MB each, so we were wondering if it would make sense to use SQL Express 2008 instead of the full SQL Server.
This seems to have the advantages of distributing disk I/O across servers while saving massive $$$ (since small 15K drives and used dual core servers are both inexpensive). If at some point we need too many servers, we can upgrade to SQL Server ... but with dozens of internal users this just seems too expensive right now (particularly since we'd need a failover box).
SQL server likes lots of RAM. The more the better. As the SQL Server can't load data into cache that'll put additional load on the disks. You should look at the Web Edition or Workstation edition of SQL Server. Those editions have higher limits than the Express edition, but cost less than Standard Edition.
We have used SQL Server Express for quite long, and its good and much better then earlier MSDE, we have more then 200 simulatenous connections, but we only have one database of size 2GB, and everything is smooth. We never had any problems provided we avoid expensive joins and we do good indexing. Now we are using SQL Standard, but till your database size is more then 4GB and your number of users are less then 200-500, you can certainly live with SQL Express.
What is your plan for backups? You don't have to use the SQL Agent but it sure makes a DBA's life easier. You could write T-SQL/SMO/PowerShell/whatever scripts that do your backups and then execute via sqlcmd or PowerShell using a Scheduled Task.
What is your plan for database maintenance? Over time, those databases will need to be defragged and checked for consistency. Standard Edition has all kinds of goodies to make this e-a-s-y whereas, in Express, you have to work (again with the scripting and scheduled tasks).
Part 2 of this is asking you how many clients you plan on supporting on this - both at launch and after one year? If you say, "100 clients", then 100 50MB databases will not suffice on Express - you just don't have enough memory. Heck - depending on how much delta you have, you might max out at 15 DBs, I don't know.
Transactional operations such as INSERTs are still written to memory so don't expect that you need less memory support. In fact, depending on how many INSERTs you do, you might have larger memory needs than most with that number of users. If you are loading lots of data that people won't really be using then it still occupies memory. You might run into contention issues between "data that users are querying frequently" and "data that users are loading up that no one will query for a while". SQL protects us by preserving the data people are querying more frequently in memory longer but you still will have contention.
At this point, I'm rambling lol. And 200 concurrent users doesn't jibe with me either for Express. Let's say 64k is average connection memory requirement, how many connections will your apps make? Will you use connection pooling?
All in all, my gut feeling from reading your description says, "No - Express Edition just isn't powerful enough." And I hate the Workgroup Edition - think it's a bad deal - so Standard seems right to me.
It can certainly be used for significant production applications. We have used it at over 1500 healthcare clinics all with separate SQL Server Express instances installed to process millions of transactions each day.You can easily get around the SQL Server Agent disadvantage by using one of the following:
SQL Express is a free and feature-limited edition of SQL Server that has been being published since the SQL Server 2005 version and it still continues to be published by Microsoft. Nowadays, Microsoft has released the Express edition of SQL Server 2019. We can use this edition for lightweight data-driven mobile, desktop or web applications. However, when we decide to use this edition, the supported features have to be checked in the Editions and supported features of SQL Server 2019. For example, the database size can not exceed 10 GB and the SQL Server Agent feature is not supported by the Express editions. As a result, we must take the limited features into consideration before planning to use the SQL Express Editions.
We can download the express edition of SQL Server 2019 from the Microsoft official web site. On this download page, we can find out the express edition download link. When we click the Download now link, we can begin the download process:
After downloading the setup package, we can start the installation steps. We will right-click the installation file which is named SQL2019-SSEI-Expr.exe and select the Open option in order to start the installation process. In this step, we must make sure that the logged-on user already has the necessary rights to install the programs on the computer. Otherwise, we can face problems during the installation steps:
The Custom installation method offers more advanced installation options so that we can configure the features and other options of the SQL Server installation. We will use the Custom installation method. In the next screen, we will set the path of the setup files to be downloaded and then click the Install button:
After the completion of the download, the SQL Server Installation Center will meet us. In this screen, besides installing the SQL instance, we are able to install SQL Server Reporting Service, SQL Server Management Studio or SQL Server Data Tools and we can also upgrade the installed version of SQL Server.
In the Install Rules screen, the potential issues will be checked by SQL Setup that might be occurred during the installation. We will click the Next button and skip the next step:
At the same time, we can determine the service account of the SQL Server Database Engine and SQL Server Browser. In the Collation tab, we can customize the Server collation option of the SQL Server:
In the Mixed Mode, the SQL Server can be accessed with both Windows authentication and SQL Server authentication. For this installation, we will select the Mixed Mode option, so we will set the password of the sa login of the SQL Server and we will also add a windows login. We can directly add the current windows user to the windows through the Add Current User button:
Tip: If you predict over workload on the TempDB database for your SQL Server, you can change the number of the tempdb files. Microsoft recommended the following rule as a best practice:
3a8082e126