It is interesting to see how different organisations respond to new technology. Some eagerly adopt the latest and greatest releases and ironically advertise for people with experience, sometime far beyond the times since the release date. If you ever see such a requirement don’t do business with that organisation it could be a fastest way to lose your time and money and it indicates that management are basically clueless.
Bleeding edge technology is fine for the development teams to play with but rarely smart for your productions systems. As a general rule of thumb for Microsoft products wait until the first service pack or 12-18 months before upgrading and adopting the newest Office, operating system or database technologies. They may work fine and then again they may not. There other common problem is lack of support by your third party vendors. Some still run only on SQL Server 2000 for example, yes even in 2012 some vendors have yet to move. If this is the case it may be time to switch vendors and move to another compatible application. In March 2013 Microsoft will cease all support for 2000 so if you haven’t planned for the move, and some need 12 months for this kind of thing, then if it goes bad you only have yourself to blame, or your management.
I finally got sick of Dragon Age 2 not enough playing and too many cut scenes. So I fired up Fallout 3. Have not started playing it yet but I hear and read good things.
Industry News
Running out of space in your organisation? Hitachi has a new hard drive for you. They already have a 4TB drive but the new one is enterprise ready the Thunderbolt. It has 5 platters and spins at 7200 rpm. Supports SATA 6GB (as it should) and has 64MB of cache. The data transfer rate is speced at 171 MB/s. This gives Hitachi a brief jump on the competition who are left back at the 3TB mark. Expect Seagate and Western Digital to respond soon but don’t hold your breath on Toshiba and Samsung, they are still back in 2TB territory. The Hitachi uses less power and has 5 power management modes using less than a watt in sleep and standby.
It has been long enough since I bought my new PC that the following news doesn’t surprise me. Intel has a new budget 330-series solid-state drive (SSD) coming out on Friday, 13 April. The new units run at about double the performance. The SATA 3 devices will come in 60GB, 120GB and 180GB and clock up to 500MB/s on sequential reads and 450MB/s on sequential writes. Or in layman’s terms damn fast. The highest capacity will sell for around $240 in the US. At this price I expect to see a lot of these babies move and will make a nice new C: drive for a lot of people in the near future.
“There is an app for that!” This used to be said with a little humour but these days there really seems to be an app for everyone and if you have an Android phone then there is probably a free version. I downloaded angry birds space a couple of days ago for free. If you own an iPhone that will be a small charge please. I still surprised when I see people with an iPhone especially if they just bought one. There are simply no advantages compared to say the Samsung Galaxy S2. I just grabbed a push up app that detects your head either using the proximity sensor or when you touch your nose to the screen. The app claims to have me doing 100 push-ups in the near future, we’ll see
Technical Stuff
With my DBA stint coming to an end I di d find out a few interesting tricks. First off if you have SQLServer 2008 Enterprise or SQLServer 2008 R8 Standard or better then you have access to a compression option when making a backup. Now you may think that compressing a database would take extra time and then on the other side when you are restoring but some testing I did turned up different results.
I started with a 42 GB database backup, yes that is quite large and the backup is always a little smaller than the main data MDF file. I created a Database backup Maintenance plan and set the compression option to compress. The following morning I had a 5 GB file (did I mention this was in a production environment?) The older backup job took 14 minutes and the new one 12. So step one saved time and a whole lot of space.
Since the database concerned was also being copied to three others servers one of which was a disaster recovery server offsite the transfer time was significantly reduced, quite a lot given the reduction in size. Performing a test restore on the disaster recovery box I found the restore time shortened by about a half, 8 minutes compared with a bit over 15 minutes for the restore.
So my conclusion is to use compression in any environment where space is an issue and where you are copying the backups to other servers. I had expected to have some disadvantage somewhere in the process but for the testing I did the results were good at every stage of the process.
The other little tit bit I’d like to pass along is the process of replacing one server with and upgraded one. In the production world this is a common one. You decide the Prod1 has outlived its maintenance life and you want to upgrade your SQL Server version at the same time.
The normal process is to set up a new server box, say Prod1New and do some installation and testing to make sure the new configuration works perfectly. At some predetermined time you retire Prod1 by taking it offline or renaming the server and then change the new box’s name to Prod1 so that all the external networking links are happily preserved. This would be such a common practice that you also expect that Microsoft has this process in mind and has a nice set of procedures for performing this task. You would be wrong.
The recommended process is to rename the server and reboot. Then rename the SQL Server instance using a couple of sp_ SQL procedures and reboot again. The problem is that you lose your maintenance plans and access to your user databases.
The latter part is fairly easy, you copy across the MDF and LDF files and attach them or you make sure you have a very recent backup and restore it. The maintenance plans you can get back by restoring msdb from the original system. You will also need to redo some permissions on the logins. This will leave a few bits and pieces of the original SQL Server and MS Server instance names sitting in a few places but the result is workable. If you really want to be sure uninstall SQL Server after the Server name change and reinstall it then copy across and restore your user databases and the msdb. You can look up how to restore msdb because is it not a simple as a user database.
No comments:
Post a Comment