It’s fairly easy. At least, I think it is if a salesperson can do it.
Alex Yates, salesman extraordinaire at Red Gate Software, spent a lunch hour recently setting up a CI system so he could better understand how hard, or easy, it can be for customers. He wrote about his experiences using the Jenkins CI server.
Check it out. If Alex can do it, I bet most of you developers and DBAs can as well.
This editorial was originally published on Mar 15, 2009. It is being re-run as Steve is away on the 2013 SQL in the City tour.
Is it inevitable that SQL Server will move to the cloud? In a word, yes.
But like absolutely everything else with databases, “it depends” applies as well. I am sure that we’ll have support for SQL Server in the cloud, something much more advanced than the current state of SQL Server Data Services, before too many more releases.
Paul Nielsen says inside of 2 years, and in 5 we’ll be leaning cloud first, local server second. I think that’s a bit aggressive, and I do think Denis Gobo has some great thoughts about a few things that need to be done before SQL Server can move into the clouds, but it’s going to get there for many people. Not everyone, but many people.
If you think about it, we are already moving towards a cloud type architecture. SQL Server has supported the idea of master/target servers for awhile, and with the addition of Policy Based Management, we are moving towards a way of telling SQL Server how we want it to work and behave and letting it then handle the details.
Much of IT is slowly moving down this path of requesting and using resources, and not necessarily specifying the details. We have implemented SANs that hide the disk architectures from us. For the most part they work, as long as those engineers in the deep bowels of SAN-storage land continue to replace disks as they fail.
In 2007 and 2008 is seemed many companies were also looking beyond individual servers by provisioning virtual machines and letting our hypervisors handle the details of getting the required resources to the calling server instance. There’s still work to be done here to allow database servers to take advantage of this, but it’s a matter of when now, not if.
Tomorrow we’ll take a look at another aspect of SQL Server in the cloud.
Steve Jones
The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.
You can also follow Steve Jones on Twitter:
Overall RSS Feed: 
or now on iTunes! 
Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.
If you’ve ever worked in a large environment, where the numbers of nodes number in the thousands, or tens of thousands, then you know many software packages don’t scale to that size very well. I’ve seen quite a few pieces of software that were well written, and ran well with hundreds of items, but choked miserably when the count crept past a few thousand. Typically those are edge-case sized installations, and most applications aren’t designed for, or tested at, those scales. I haven’t registered 1,000 instances in SSMS, but I could guess that it would not necessarily run smoothly with that many instances being examined.
Software designed at scale tends to take the “install another central node” and manage multiple central nodes individually. That quickly becomes a pain point for the humans that administer the systems as they must learn and remember where individual systems are being managed. It’s not much different for hardware as well. When a system exceeds the capacity of a single node, we often find that we are adding multiple modes and managing them individually. Many backup systems work this way, adding new units to handle the additional backup space requirements.
However there’s a staffing cost as well, and it’s one that can be overlooked as a company grows. More systems mean more backups, more maintenance, and more failures. Even with automation and standardization, there’s a physical workload increase on your staff, and also a stress level increase from managing more systems. It can be easy to overwhelm your staff, assuming they can easily handle the additional load because they have plenty of tools to do so.
Tools are required, and whether you build or buy them, you’ll make use of them if you want to minimize your salary costs. However you still need to make sure you grow your staff, train them, and give them time off. The last thing you want is to overload and burn out a small staff of one or two. I’d bet that the week your staff quits or takes ill, your systems will choose to fail.
Steve Jones
Video and Audio versionsToday’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
|
I ran across a twitter conversation about a post recently. The post talks about detaching or attaching databases in bulk.
I agree that detaching databases in some cases is bad, but it’s not necessarily something I’d avoid. Detach is a good way to prep for upgrades, movement, etc. It may or may not be faster than backup/restore, depending on your environment, but it’s something to consider.
However.
If you are going to detach, there are a couple things I’d recommend. First, make sure you have a good backup. A backup is just that, a backup plan, a backup file, a way to recover when things go wrong. It isn’t your data, it’s a copy. A detached mdf is your data. Make sure you have a backup before detaching and messing with files.
Second, never move files. Never, ever, ever, ever, move database files. Detach/attach is a valid way to move databases, but always copy the files.
Voice of the DBA 