Conference Starts Tuesday – Register Now
The SSWUG SQL Server Virtual Conference is coming to your computer starting on Tuesday – make sure you register ASAP if you’ll be attending. Have you seen the schedule? Information on all of the base items you need to know for SQL Server is included. From TSQL 101, 2 and 3 to understanding replication to working with Access and SQL Server.
A Virtualization Tool You’ll Want to Have
Our friends at SQL Sentry have really been helping out a lot of people with virtualized environments. It might seem odd at first to think about the tool in that light, since it’s about managing your job subsystem. But, if you consider the resources that could be in contention in a shared, virtual environment, all of a sudden you see that you can make a *huge* difference in performance, reliability and functionality for your systems. How? By managing the resource impact of jobs and coordinating that impact across virtual instances on a server so the physical server can operate at peak efficiency. Find out how to control your schedules across virtual servers, physical servers and more. Get more information here – you won’t be sorry.
Virtualization Feedback from Readers
I talked yesterday about how different implementations have used virtual servers to sandbox installations, and asked for feedback on how you’re using it.
Ken wrote: "We run Microsoft’s Dynamics AX on a SQL Server 2005, 64-bit platform. Do we sandbox? You better believe it. Our live system is based on dual Dell 1850 blade servers, both running Windows Server 2003 x64. One is the AOS (application server), the other is the database server. We also have a development environment where we actually do our coding. Our hard and fast rule is that code is only written in this environment. We have then two sandbox / test environments. One is on a similar server as production, but the AOS and DB are combined on one server, rather than split. This environment is for testing hardware intensive operations, like a regen for MRP. It is also where we play around with settings to see their affects. We don’t test modifications to code here, just changes to settings in the standard AX environment. We keep it refreshed live data, but it’s code base is shared with the live environment (so it is always in sync). The other sandbox environment is on the same physical server as the development environment. Here is where we test functional mods. So we are actually testing code changes here.
It is difficult to keep everything in synch, but AX is really built to make it easier. We can export code changes from Dev into Test by wrapping up all the modified objects into what they call in AX world a “project”. This project can then be imported into any of the environments. AX also works in layers, so these projects can be imported into just about any layer, thereby segregating standard code from Microsoft or a third party from our internal code. So once a mod is thoroughly sandboxed, we do an entire layer transfer from the test environment to the live environment. Since the MRP test environment and the Live environment share code, doing this once from the mod testing environment refreshes both the other environments.
Then, periodically, we take the code that exists in Live and flush it back into the test and dev environments. The goal here is to prevent us from getting out of synch. This means that the developers have to pull their in-work mods out of dev, then put them back into dev after it is synchronized with Live.
It’s difficult to manage, but it’s worthwhile and is definitely worth the investment to be able to try different things out, whether they are mods or settings changes. We also use the sandbox environment for training."
Diane writes: "Yes I have production SQL 2000 and 2005 servers running in Virtual Environment and do not seem to have any other issues that I would not have on a normal physical server. As long as you set it up correctly it seems to run fine.
The best example of a high end application which we just placed on Production is Biztalk Server Databases, I admit it’s only been a month since going live, but performance is better than it was on Physical box. Otherwise, most other Produciton databases on Virtual are not so demanding. Things like SAP are still on physical box’s. Livelink on Physical but the remote caches on Virtual.
All DEV/Train Instances on Virtual.
I was reluctant at first but under pressure proceeded with caution and constant evaluation and it has not turned out as bad as I though it would."
Featured White Paper(s)
SQL Server Fragmentation Explained
As the data in Microsoft SQL Server tables changes, their indexes change. Over time, these indexes become fragmented. This fr… (read more)
MS SQL Server – An Overview
Whether you’re running a small business that’s ready to take the next step in its growth or an SMB that’s ready to “grow into… (read more)