SQL Server Cruiser

We have a boat load of older servers. Dual core machines that used to run SQL Server in production. Newer technologies and demands on IT have required us to buy newer servers with quad and hex cores. So who says we have to retire these perfectly good dual core machines? Unfortunately Microsoft does. Licensing by the CPU means we can get quad and hex core licensing for the same price as dual core CPU's. With licensing being incredibly expensive at the enterprise level we cannot reasonably license these older servers and upgrade to newer technologies. Here is a recent conversation I had with a Microsoft technology specialist on the idea of bundling together these older servers for cheaper licensing: I have a question that someone at the SQL Saturday event said you would have some comment on even if the answer is basically no. I have a bunch of HP DL320's laying around with Dual Core processors. Now it is not economically sound to license these servers with enterprise SQL Server a...

Let's suppose you have this table: We have made last name the primary key in this table Now lets import some rows into the table and check the fragmentation Notice the fragmentation at 96.48% and all we did was one import of 16426 records. So now we have several questions: How bad is this? Fragmentation causes SQL Server to skip around to read data from your tables. For a one time read on a small table this is virtually meaningless. In a job that may need to read millions of records, this could tear apart your performance. Ok this is bad. How did it happen? The primary key on a table is clustered. This means the data will be stored according to the primary key. In our case, last name. When data doesn't come in the same way you store it (i.e. Customer names are not coming in alphabetically, but rather randomly) SQL Server must constantly split pages to store the data correctly. This causes data to be "fragmented" into multiple areas of the disk instead of one continuou...

Tired of editing your SSIS package configurations every time you move your package to another instance of SQL Server? Try adding a configuration file. Having your packages enabled to run on different instances sounds like overkill but it is so easy to setup that not doing it is a crime. All those packages that you have that are ONLY needed for this one server will eventually need to be moved to an upgraded server right? What if you consolidate servers? WHAT IF? That massive workload of editing every single package and redistributing could be eliminated if you just add some dynamic configuration to your packages. Check it out here .

I went to SQL Saturday this last weekend in Dallas and listened to a bunch of great speakers. During the day Jen McCown encouraged everyone to start blogging just for our own needs. I am particularly bad about remembering how I did something even a few weeks ago, let alone years ago so hey, here I am!

I had an interesting problem come up recently that I thought I would share. We had an immediate need to create a support site for customer service to support our stores directly. Our requirements: Cannot use production for queries Cannot change schema Development must be minimal No new equipment will be purchased Data must be able to be changed on either server and distributed to the other server near real time. Normally I would want to crucify the people that came up with these requirements, but we did it to ourselves. Knowing we couldn't ask for more equipment, we didn't have time to develop a solution, and the developers would scream if we changed production schema, we had to try to solve the problem this way. So we started exploring options: Log Shipping - Quick and easy with only one fatal problem for us. We need the data to be near real time *snap*. Data Mirroring - We cannot buy new equipment *snap* Custom ETL - The best option IF we could spend some time doing developm...