June 21, 2006 | Comments: (0)
I have been in contact with MS about the problem with Team System I blogged on earlier this week. They've admitted it was just an oversight and are responding quickly. I just love it when companies take responsibility for simple mistakes. We're all human and things get overlooked. What I can't stand is when they try to pull the wool over our eyes about it. Besides, it's just a CTP anyway, it's not like this is RTM code. Anyway, keep up the good work SQL Team, I like what you're doing over there.
They're targeting the fix for tomorrow, 6/22. Here's a cut and paste directly from the email they sent me about how it's going to work.
I think it's easier than trying to reword it...
What I am planning to do is create a self-extracting exe that contains the files from the ISO image. When a user runs the exe it will prompt for a directory to unzip all the files to and then the user can run the setup.exe from the target folder. I will include in the exe updated data files that the setup uses and remove the references to MSI 3.1 so that uninstall works. If the user uses the self-extracted files to install / reinstall / uninstall the product, it will work as expected.
I will also see about posting an updated data file that users can download to make it so they don’t have to get the self-extracting exe if all they want to do is reinstall their existing installation.
Read my book reviews at:
http://www.ITBookworm.com
Posted by Sean McCown on June 21, 2006 07:22 PM
June 19, 2006 | Comments: (0)
Team System for DBAs First Look
I got a copy of the new VS Team System for DBAs at TechED last week and went to install it this evening. The install went flawlessly... that is, until I went to run it. There's just nothing there. I see the documentation in the Visual Studio program menu, but nothing else indicates that the product was installed.
I went to repair the install, and the first step is to install windows installer 3.1, which it can't find on the CD. I downloaded and installed it manually. The install program still insisted on trying to install it and failed. I searched the CD and couldn't find the .exe either, so at least it's not lying.
I can uninstall it just fine. I ran the uninstall, rebooted, and installed from scratch again. I find it worth mentioning that windows installer 3.1 isn't part of the base install for some reason, just the repair/reinstall. So, again it installed without issue and completed just fine. I rebooted for completion's sake and again, there was nothing there.
Once I get this worked out I'll let you guys know more about what it's like to work with and how well MS is answering our real problems in code management.
Read my book reviews at:
http://www.ITBookworm.com
Posted by Sean McCown on June 19, 2006 06:54 PM
June 15, 2006 | Comments: (0)
Microsoft Sells SQL Server to Oracle
OK, to be honest, MS hasn't sold SQL to Oracle. I just needed a catchy title to make sure you read this post.
I follow the rule that if you don't have anything brilliant to say, then point to someone who does. There's a fairly new blog on msdn that you really can't afford to ignore. It's Paul Randal's blog, and he's the Sr. Program Manager at MS for SQL Server, or maybe just the storage engine, I honestly forget. The important thing is he's the guy who wrote DBCCs for SQL Server like CheckDB, and IndexDefrag, etc. In his new blog, he's giving away some very cool secrets on the internals of SQL Server and how some of these things work together.
If you really want to learn about SQL Server, you have to read this blog. Add it to your feed list, and link to it as much as possible. This is info we want out there, and Paul is the one to bring it to us. I spent several hours talking to him yesterday and he definitely knows his stuff (he was a good student, and I'm proud of him).
Anyway, here's his blog, so go often... he's posting a lot so you don't wanna get too far behind.
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
Read my book reviews at:
http://www.ITBookworm.com
Posted by Sean McCown on June 15, 2006 04:35 PM
June 07, 2006 | Comments: (0)
Idera has issued a press release outlining their new world record backup benchmark. As it stands, the benchmark results are reported in a misleading fashion, so let me go through some of this for you.
"Using 'off the shelf' technologies available today to any data center customer, the companies achieved backup speeds in excess of 4.5 terabytes per hour and restores speeds in excess of 2.3 terabytes per hour. These metrics reflect a more than 20% and 75% performance increase, respectively, over previously documented benchmarks for SQL Server backup and recovery."
OK, that's directly out of the press release and I think it outlines a couple really important parts. First, look at the backup speeds... 4.5 TB/hr. Man, that's fast. In fact, it's a lot faster than any backup benchmark out there, so they're right about that. However, what did they do to make it so fast? I mean after all, I've never known them to be that much faster than LiteSpeed or Red Gate. The secret is found where they say that the hardware is open to any data center. It didn't take me long to chase it down after I read it just a little more closely.
What's going on here is they're using Solid State Disks (SSD) on their system. For those of you who don't know what SSDs are, they're really super fast disks that are basically huge banks of RAM instead of platters. Their speed is measured in microseconds instead of milliseconds found in SCSI. The bottom line is that SSDs are exponentially faster than SCSI, but the cost also reflects that as well. In fact, they're really just way too expensive for most shops to even consider.
While Idera isn't really being deceitful (because they are disclosing the hardware details), they are being deliberately sneaky by not telling us that SSDs are what's being used. In fact, they're using a 16-way 64-bit box with SSDs. That's just an insane system and it better damn well be faster than anything else out there. And sure, SSDs are available to anyone who wants to buy them, but who's going to do that?
The reason I say they're being sneaky is because absolutely nobody out there is using SSDs in production, and they didn't take any other backups to use as a baseline. If it were a responsible benchmark it would have listed the SQL Server native backup times and then the Idera backup times. Of course they beat everyone else's benchmarks, they're running on hardware like a gazillion times faster, but how does it do against the other vendors on the same hardware? Will it still show such incredible results? My guess is NO. Hell, you could probably put a single-threaded QBasic application on that system and still record a world record benchmark.
Doing the benchmark this way is the same as a car company saying that their car is the fastest on the road by going from 0 to 120 in 5secs. Of course, they used nitrous oxide, and special tires, but that part is completely irrelevant. The point is they have the world record for street cars.
OK, to keep this kinda short, I'm just going to bottom line this for you real quick. It's not really Idera's job to make sure you understand the details of their benchmarks. That's my job. Idera's job is to put nice big headlines up saying 'world record benchmark' so you'll see that and buy their code.
I speak out against this kind of chicanery when I can because I honestly believe it's wrong. If they wanted an honest benchmark that would stand the test of production, they would have used SCSI. Their hardware platform is something that nobody will be able to reproduce, so their results will never be reproduced either. DBAs are going to be wondering why they aren't seeing the awesome results they read in the benchmark.
So for the record there is no world record benchmark here. It's just a marketing device used to catch your eye and steer you away from the fact that Idera is about as fast as everyone else. The data and compression level also play a huge role in these types of benchmarks too. A while back I did a comparison benchmark between LiteSpeed and Idera and depending on the data I used, and the compression level, each one of them was able to beat the other one at different times. That's just the nature of the game. So, what's likely here is they're probably using something similar to SAP data, which is easily compressible, and they probably also used their lowest compression level. I don't blame them on that part. I know the LiteSpeed guys use their lowest compression level when they do their benchmarks too. The difference is they use hardware that people are actually using in production.
I'd still like to see this benchmark done on the same data set with LiteSpeed and Red Gate, and MS native.
Here's the hardware spec:
• Intel Itanium 2 Processors
• NEC Express5800/1320Xe
• Emulex LightPulse® 4Gb/s LP11000 HBAs
• Texas Memory Systems RamSan-400
• Idera SQLsafe v3.0
• Microsoft SQL Server 2005
• Windows 2003 Datacenter Edition
Read my book reviews at:
http://www.ITBookworm.com
Posted by Sean McCown on June 7, 2006 06:59 PM
TOP STORIES
IBM boosts BlackBerry accessIntel to develop PC with Alibaba
Adobe refreshes Flash Player
Cybercriminals can rent a botnet
Comcast to buy Plaxo social network
Rootkit for Cisco routers
Leopard interface tweaks
Icahn to launch proxy fight
Office VBA and Mac IT
Test your Geek IQ
ADDITIONAL RESOURCES

- Application Security: Threats and How to Counter Them
- Why Linux Threats Mean Business
- Virtualization: A Step by Step Approach to Success

- Is your smaller organization ready for High Availability?
- Is system maintenance doing more harm than good?
- Virtual Test Lab Automation: Manage development infrastructure


