the san is in

This weekend the new SAN hardware was installed.

Apart from a minor hickup in communications - someone assumed changing disk storage infra-structure didn't imply downtime of databases... - the whole exercise was almost easy. It did help the folks who did the installation knew what they were doing. I worked for this company for a few years. They have some very competent people there, when it comes to SAN hardware and facilities management.

As far as the databases were concerned, we did a backup to ensure we could recover just in case. Then took them down and let the SAN folks work their magic. At the end of 12 hours, we had all our file systems and their contents moved to very fast premium disk LUNs, with enough capacity to last us another year - at least - and room to grow twice again.

It's this type of smooth transition that folks like with SANs: they make it easy to do reorgs like this. I can't imagine how many secret incantantions we'd have needed, had we used native disks and controllers instead.

Plus all the hassles of "disk load spread" and such other ancient methods of tuning physical IO. Yes we're running RAID-10, not RAID-5: relax folks, I didn't give in completely to the dark side!


Don't get me wrong: if you want top performance in OLTP-type databases, you still should get familiar and intimate with all that disk/controller magic. There is no substitute for specialisation, when it comes to ultimate performance.

But for a DSS and DW database which hardly - if ever - see time critical processes other than simple ETL?
Quite frankly: give me a SAN any day. I value my free time too much to waste it trying to extricate the last 20% of performance. 80% will do me fine and cost a LOT less! And I think my senior management shares that with me.

Oh, nearly forgot: it's been said before ad-nauseum, but spending some time studying new versions of Oracle is always worth one's time. I forgot how many scripts I've seen that shutdown the Oracle TNS listener to switch log files. This has not been necessary since release 8: all you have to do is use the "set log_file <filename>" lsnrctl command and you get a smooth, orderly transition to a new logfile.

Then do whatever you need to do to the old one. Don't know what its name was? Do a "show log_file" before, in your script.

Done. Easy, no downtime, no problems, no locks, no failures.

Much better than shutting down the listener, renaming the current logfile and restarting. What happens if your rename fails for any reason? You end up with no listener, don't you? Because your script never reaches the re-start, doesn't it?

Anyways, nuff work stuff!

Oh no, someone killed Mickey:



I do love these calm late afternoons:

Makes it all worthwhile.

catchyalata, folks!


Blogger Connor McDonald said...

Quite frankly: give me a SAN any day

True, but you still come down to all those ancient rules...eg, our SAN administrator/management, bless their little hearts, had filled ours with 400G SATA disks under RAID-5...

"Sansational" it aint...

Monday, March 19, 2007 11:34:00 pm  
Blogger Noons said...

LOL! Classic!
It's the "family value package" syndrome all over again, ain't it?

Tuesday, March 20, 2007 10:53:00 am  

Post a Comment

<< Home