Saturday, November 22, 2008

SQL Replication - A Good Look in the Mirror

As I explained before, I am working on an upgrade to my company's back-office software suite. Part of this upgrade has been a migration from a legacy database technology (BTrieve) to a more modern one (MS SQL 2005). The changes are obviously stark and glaring, to say the least.

In any case, about 2 years ago, when we first embarked on this upgrade journey, we had investigated, with the help of some consultants, what technology we would be using to provide for high-availability (HA) and high-security of our data and application. At this time, many of the available SQL Server 2005 technologies were presented, including database mirroring, transactional replication, server clustering, etc.

In particular, database mirroring at first looked very promising. Early on, however, we received some advice from one of our highly-respected consultants that fully led us to conclude the mirroring was entirely unsuited for our needs. Several reasons were cited by this individual, the details of which are, at this point, long-forgotten, but suffice it to say that we fully dismissed database mirroring as a viable option for us and did not pursue it one bit after that.

We went head-long down the path of transactional replication with queued updateable subscribers, providing for high security of our data and the ability to point at any available database in the population of participating servers for up-to-date data. This was all working quite well for us until, unfortunately, very late in the game.

Once we began pushing our full production load of transactions on the server, the performance level of this technology became very suspect. In fact, during one test, when we "failed" our application over to the "subscriber" database for primary services, it was quite apparent that the "queued updateable" portion of this technology was woefully inadequate. Each minute that passed, we were falling 30-50 seconds FURTHER behind in transactions, meaning that we could, for all intents and purposes, never switch back, since the data would be horribly outdated. This was, for us, an absolute show-stopper.

What were we to do? We called in experts. We scoured blogs and websites for any assistance we could muster to see what we could have configured wrong to make the performance so poor. But during that effort, I took some to think outside the box and do some "re-investigation" of other technologies.

Database mirroring came back into my view, with fresh eyes this time. I realized that the reasons we had dismissed it in the first place were misunderstandings and misrepresentations. After a few days of research and trial, we moved our efforts to database mirroring.

The option we chose for now was the High Security mode of operation, foregoing the need for the Witness server for now (it can always be added in later). Configuration of the mirrored pair took all of about 3 hours (most of which was recovering from an operator error on my part).

The best part is that the performance of the mirroring is spectacular, even under our load (about 10,000 transactions per minute all day, every day, with peaks that exceed 15,000). We have been able to fail over and back whenever necessary without any degradation of our services whatsoever. The built-in monitoring tools are mature and very relevant.

Overall, my feeling is that when replication "grew up" in the Microsoft SQL Server world, it became mirroring.

Fun with partitions

At work, we are preparing for a major release of a new suite of software to run what we call our "back-office." Essentially, without getting too much into details, I am responsible for a 24x7 network service that is, at least in part, dealing with life-safety and we are planning to swap out the software responsible for this with a new generation of software. All this has to be done without skipping a beat. Lots of preparation has gone into planning this move and we're "this close" to releasing.

We have had a few last-minute gotchas pop up recently, though. One of them is that the people who built our SQL Server machines (64-bit Windows Server 2003) built them in such a way that there was a C-drive partition of 10GB for the operating system and a D-drive partition of 22GB for the applications (not to mention a SAN-based area for data storage). Well, the 10GB of operating system storage just wasn't enough, or at least, didn't seem enough. We had gotten to about 100MB of available space and couldn't do OS updates.

So, we began investigating how we could dynamically and non-destructively change the partition sizes. Our network/server engineer made some tech support calls to HP while I resorted to my old stand-by...experts-exchange. I received many postings with great ideas. Some were saying that 10GB should be big enough. Others were linking me to some freeware tools. Still others to more expensive professional tools. Boy, did I learn a lot!

First, I learned that my C-drive was not so clean. There were "installation" folders for both the original O/S install, as well as the service pack installs, sitting on the C-drive. I was able to move them off by copying them to the D-drive and editing my registry to point to the new folder. (See this site for some specifics on moving the "Service Pack Files" folder - there was a similar copy/edit for the AMD64 folder in the C-drive root). So, after these folders were cleared out, I suddenly had almost 2GB free. Probably enough, but I was not satisfied.

I pursued the route of the gnu-tool for partition editing - GPartEd. This was recommended to me, so I figured I'd give it a shot before plunking down $500 or more on some "professional" package to do the same job.

Download and CD creation was a breeze with the ISO image. Booted to the CD and the tool could not be more intuitive and simple to use. Click here, drag there and boom! the partitions were changing right before my eyes. Shrink one, grow the other...2 hours later, I was ready to reboot and feeling confident.

Um...not so fast. When I booted, I got a message that my C-drive had ZERO free space - this after ADDING 5GB to the partition! And to go along with that, my D-drive was nowhere in sight. GONE! I freed up a LITTLE space (140MB or so) and was able to use the Disk Manger to recover the D-drive, which was still there and healthy, thankfully.

Then I rebooted and upon logging in, I saw that there was a new 7GB "pagefile.sys" file sitting on the C-drive. Somehow, GPartEd must have dropped all this newly created space into that file. I confirmed that I was not using this file (my swap file was on the D-drive) and deleted it. Voila! I'm now swimming in free space on my O/S partition. All this I did on a STAGING server and not one that I was planning on using for our upcoming deployment (thankfully).

I probably will not be using GPartEd on my production server(s), as I just don't think I can trust it (they say you only get ONE first-impression, and while the final result was good, the road there was not great). The 2GB I have free on that machine now will suffice for the foreseeable future and should the need arise to fix that, I will probably bite the bullet and purchase some "professional" software to do the job, though I certainly know that it no guarantee, but at least there's someone at the other end of a tech-support line should something go wrong.

My Newest Printer

For years, I have been a huge fan of the HP line of inkjet printers. I have had the old Deskjet 550C. I have had the 950C. Most recently, I had the 5180 AIO. All of them were pretty-much top-of-the-line printers in their day. And when I first got them, the "photo" quality seemed astounding. Really, it did. Unfortunately, my wife, being a photo-buff, was never all that impressed. She was typically underwhelmed and disappointed with my prints, which meant that all those digital pictures I was taking were sitting on the PC doing nothing.

Well, recently, my 5180 died (stopped recognizing new ink cartridges) and was already out of warranty. So I had a decision to make. HP or not HP, that was the question.

After some research, I decided to part ways with HP and move over to Epson. The Epson Artisan 800, to be exact. I just picked it up today. I'd like to give a first-day, first-impression review. In a word, "stunning!"

The printer setup was pretty much a breeze, though this beast is quite a bit bigger than my old HP, which was a challenge on my space-deprived desk. I managed to fit it in, though. Installation was smooth and error-free. I have it hooked up via USB on my main computer, but also via wired network for my laptop machines (2), which caused no problems. I didn't need to venture into wireless setup, which I assume would have been just as easy.

Printing photos on Epson's best paper in the best mode was, quite simply, the BEST prints I've ever seen come from a personal printer. And the best part came when I showed my wife some of the prints. Her response was a matter-of-fact, "I'm happy with that" statement that almost left me speechless. It was as if I had discovered the Holy Grail!

Now, I have not played with much yet...a scan here, a copy there and a few dozen prints in various quality modes on various papers. I have yet to see anything that I was not impressed with. This printer is absolutely fantastic thus far and I certainly hope it continues. And for the price I paid ($229), I cannot complain one bit.

After one short day, and I certainly hope this doesn't change, I have to whole-heartedly recommend this printer for anyone looking for true photo-house quality prints from their own desktop.

Welcome to Random Acts of Technology

This is the first of what I hope will be quite a few entries in my new blog. But before I go too far, perhaps an introduction is in order first.

My name is Jim and I am a software engineer by trade and a self-proclaimed geek by nature. As long as I can remember, I have been interested in just about anything to do with technology - particularly, things dealing with electronic gadgets and/or software development.

My hope is that this blog will allow me an outlet for some of the information that I have. I foresee that the topics in this blog will be rather eclectic and wide-ranging. Mostly, I hope that the various posts that I make will help and/or educate the reader(s) that may happen by.