OTN Appreciation Day: Dataguard

OTN Appreciation Day: Dataguard

Thanks Tim Hall for the idea about OTN Appreciation day. The feature I like the most in oracle is a rather “old” one, but it can be extremely useful: Dataguard. Why dataguard? I find it extremely easy to set it up, maintain it and it can save you a lot of “troubles”. Especially on big(ger) databases it takes down the time to recover in case of a failure down to seconds instead of hours.

The concept is simple:

Dataguard configuration

(image borrowed from the oracle documentation) It consists out of a primary (mostly live) database and we replicate all the redo to a target / standby database. This in real-time or if needed, with delayed apply.

One of the nice things about it, even how you mess it up, you get it up and running every time again, so it’s virtually unbreakable. Is it? Maybe not, but even it lags behind, it’s fairly easy to bring your standby database up to date with incremental backups and go on with your daily tasks.

Nowadays, I (and lots of my colleagues) use it a lot for hardware migrations. Almost everything can be done on beforehand, the moment of the big switch, you just switch the db, adapt the connection strings and done. You even can test your migration easily by breaking the redo stream (or in current versions use the snapshot standby) and test the applications on the new platform.

One of the nicest things I ever used it for was a exadata to exadata migration from Germany to The Netherlands. That client decided to switch from datacenter and all the equipment must be moved from Germany to the Netherlands, but with as few as downtime as possible. Switching over 45 databases (not too big, only a couple of TB in total), took only minutes and the end-users weren’t even aware that a complete DC move had been done.

All those nice features, active dataguard, snapshot standby, … they all make our live a bit easier. So thanks for this nice feature which makes my life a bit easier.

 

Comments are closed.
%d bloggers like this: