2010/09/22

finally back!

A thousand apologies for the lack of news. Well, it's been a wild ride since the last post, way back in March!

On the work front:

We finally finished the new DR site. And it's all working fine.
Not just that, though: a LOT more!

If you go here you'll see in the files area a presentation on how we do SAN-driven DR database replication. It works with SE Oracle, EE, or any other kind of Oracle licence, if you have a SAN. A little better than Dataguard, which only works in EE.

But I'm quite sure it's all "bad practices" of a dba 1.0 dinossaur. Never mind it's saved us a bundle in licensing costs, as well as being a lot easier to manage and upgrade. Ah yes, that's right: "dbas are expensive". So are Oracle licensing costs - much more, in fact, than it cost to pay me to get this going - in case someone at Oracle hasn't noticed!...

We are also now actively using the lpars and micro-lpars of our Power6 IBM i570 super-server. This system is simply awesome! We can basically carve it in many little or big individual lpars, independently bootable, some with AS400 (i-series) OS in it, others with AIX and/or Linux.

And at any time we can use the hypervisor console to allocate/apportion resources to each virtual box, dynamically or statically and on a schedule, depending on the capabilities of the application software running on each partition. It's mind-blowing! I'm having a lot of fun with this, and so are the "Unix boyzz" at our site!

On another front: we now have a Wintel super-server running VMware, with a few *big* virtual boxes quite happily running SQLServer full systems in them! With SS2008 and Windows Server 2008, it's all quite possible and manageable *if* we take care in allocating resources, disk and memory.

The secret to acceptable performance is to be liberal with the disk allocations, reserving individual SAN LUNs to each of the major I/O impact areas in the SQL Server instances. Namely: the Windows paging file, the tempdb, the log files and the high volatility data files. Plus a few other odds and ends that I won't go into now. And the server VMs are now all referrable via virtual aliases by the app servers.

All this is not just some gratuitous pandering to the "cloud" nonsense. It has a very definite purpose: we can use the virtualization setup to quickly and efficiently clone to DR any environment we need, if/when needed, without any major impact on operations or major scripting hurdles, with just a few mouse clicks! A couple of them and hey presto: the app and the db server are anywhere we want them to be.

Now, to me that's what virtualization is all about. Not the ridiculous claims about "cost reduction and efficiency increase through cloud" and all that jazz: they are true, but not the main driver for this sort of work.

It's been a crazy ride to get all this working, particularly since we still have to provide a fully functional environment to the business. But we're almost done, and it's working like a charm.

And *NO*: it neither cost a fortune in licensing, nor hardware or human resources. And at least having done it in-house, we *know* its limitations and short-comings as well as the ins-and-outs. Which is something outsourcing would never give us! So please, spare me the "cost" comments, OK? You don't know what cost-to-delivery means, if you think this sort of thing is expensive because it was done in-house!



On the personal front:


I was dragged kicking and screaming by some very old friends to spend 10 days in one of the places where I grew up: East Timor!

A group of high school colleagues decided to organize a meetup of students from the 60s and 70s at our old high school in Díli (pronounced dilly). Strangely enough, if you check the meaning of that sound, it accurately reflects what the place is: extraordinarily *delightful*! We had people from all over the world: Cape Verde in Africa's West Coast, Portugal, Mozambique, Timor, Australia, USA, UK, you name it!

I was very reluctant to go there: the place holds some great teenager memories for me and I wasn't sure I'd feel OK when I found out things were a lot different now. They had to be: it's been 41 years since I left and there have been two wars and 25 years of foreign occupation in-between!

I needn't have worried.

Díli is still as amazing a place as it ever was! With the most stunning smiles, stunning sunsets, pristine beaches and coral reefs I've ever seen, and I've been to a LOT of such places. Probably the only place that even *remotely* approaches it in raw beauty is Fiji.

Sure: not all is perfect. The madness of destruction heaped on ET (as we like to call it) by the pro-Indonesian militias after the independence referendum in 99 has left huge, ugly marks... In the city, the country and the people.

But like all other such ugly things, we humans tend to forget them and only recall what is lovely. And there is much to fall in love with, over there. As I hope some of the pics below will convey to you.


East Timor is one of the few places in the Indo-Pacific where coastal coral reefs can still be seen without any human-induced or crown-of-thorns starfish damage:



I call this one "Fallen Star". One of the many species of starfish at the Areia Branca beach.



A volute shell attacking a starfish. This one was a lucky find: this kind of thing is very hard to see live.



Nobel peace prize laureate and current president of East Timor, José Ramos Horta: a high-school colleague and a friend, despite our ideology differences. And Fernanda, a childhood friend who was instrumental in convincing me to go - may your God bless you!



So many great old friends from 41 years ago...



The bay of Díli is a stunning place, every bit as lovely now as back then:



Arbiru Beach Resort, where we stayed. It belongs to a great friend I call my only brother:



This was a very emotional moment: that's the tree I climbed as a teenager to watch the boats entering the harbour. The dark yellow house behind it is where I lived with my parents...



Our old high school, the current university. As lovely now as it was back then.



The view from the city to the Christ statue on the other side of the bay, where the sixth photo above was taken from:



A typical daily sight in Díli. Words fail me to describe its beauty:



And so many others. So many great moments with great old friends, so many emotions...
Catchyalata, folks!

6 Comments:

Anonymous Doug Burns said...

at least having done it in-house, we *know* its limitations and short-comings as well as the ins-and-outs. Which is something outsourcing would never give us! So please, spare me the "cost" comments, OK? You don't know what cost-to-delivery means, if you think this sort of thing is expensive because it was done in-house!

Welcome back, mate ;-)

It might *seem* like you've done a lot of living over the months, but if I can't hear you online, you don't exist, right? LOL

Thursday, September 23, 2010 8:25:00 am  
Blogger Noons said...

Look who's talking:
Captain Late Post!
(evil grin)

Thursday, September 23, 2010 9:53:00 am  
Anonymous Doug Burns said...

Yeah - got me ;-)

btw, sounds to me like you've built an elastic cloud in a box. Who would have thought it? tee hee

Thursday, September 23, 2010 4:15:00 pm  
Blogger Noons said...

Yeah, but it's across sites to the DR stuff as well. That's what makes it handy: we can go clickety-click and suddenly it pops up in the DR site, 40 miles away.
Love it!

Thursday, September 23, 2010 5:10:00 pm  
Blogger Joel Garry said...

Maybe I'm just going blind, but not sure which files is the SAN-driven DR database replication?

word: bardba

Saturday, September 25, 2010 7:22:00 am  
Blogger Noons said...

@jgarr:
I assume you're talking about the prezzie in the Sydney Meetup?
If so, it's the entire FRA. Archived redo logs are there as well.
The lot is sent to DR with on-demand replication.

Then we snapshot it in DR so we can mount the FRA and restore in DR, while the on-demand replication continues to the snapshot master in background.

That lets us use the DR copy for spot recovery, for example if someone drops something they shouldn't: get it back in 2 hours, without needing a huge flashback area - we generate 1GB redo changes in < 30 seconds in a peak period, no way a small flashback can cope with that.

For the SQLServer stuff, it's simple: synchronous replication of all luns for each major instance.

Saturday, September 25, 2010 10:53:00 am  

Post a Comment

Links to this post:

Create a Link

<< Home