{"id":1120,"date":"2006-11-02T12:00:00","date_gmt":"2006-11-02T12:00:00","guid":{"rendered":"http:\/\/orcldoug.com\/blog\/?p=1120"},"modified":"2006-11-02T12:00:00","modified_gmt":"2006-11-02T12:00:00","slug":"recovery-design-part-4-you-need-more-than-one-database","status":"publish","type":"post","link":"http:\/\/orcldoug.com\/blog\/2006\/11\/02\/recovery-design-part-4-you-need-more-than-one-database\/","title":{"rendered":"Recovery Design part 4 &#8211; You need more than one database"},"content":{"rendered":"<p>There was a good reaction to <a href=\"http:\/\/18.133.199.212\/?p=1117\">part 3<\/a> with sensible comments from people who&#8217;ve obviously &#8216;been there, seen it, done it, bought the t-shirt&#8217; and handled their share of tricky system failures, so thanks to all. The comments are interesting reading for other perspectives and ideas.<\/p>\n<p>Although the sub-title to this part is &#8216;you need more than one database&#8217;, I hope that the last part already convinced you that, if you really want to protect your data from the widest possible range of failures with the fastest possible recovery, some form of <i>replication<\/i> is a &#8216;very good idea&#8217; (TM). I&#8217;ll divide how\u00a0you decide what approach\u00a0to take into two groups of factors.<\/p>\n<p><b>Technology<\/b><\/p>\n<p>This is the easy bit. What particular technology you use is a matter for you, but there are options. I&#8217;ve worked at sites which used one or more of the following. (I haven&#8217;t included the use of Oracle Streams here because I haven&#8217;t used it personally, but anyone who\u00a0has or does\u00a0should feel free to comment.)<\/p>\n<ul>\n<li>User-configured Standby Databases. I include these for historical reasons, because it was the first approach I used on a 7.0.15 database. I vaguely recall that Oracle offered full instructions on Metalink for maintaining a Standby Database by shipping archived redo log files, but didn&#8217;t officially support it. Nevertheless, it worked well for us although we only ever used the Standby for disaster recovery and as the source of the backups and didn&#8217;t use it for user reporting.<\/li>\n<\/ul>\n<ul>\n<li>Oracle Dataguard. The modern name for a Standby Database and I tend to forget to use it because it sounds to me like a marketing tag for a basic concept. However, I must admit that the modern implementation is much improved and easier to use and people tend to be more familiar with the name &#8216;Dataguard&#8217; these days, so I&#8217;m trying to use it &#128521;<\/li>\n<\/ul>\n<ul>\n<li>Quest&#8217;s Shareplex. I worked at one site that used this for everything &#8211; dozens of databases worldwide, some of them extremely active. We did run into one or two problems with it but my personal hunch is that it was no worse or better than Oracle&#8217;s technology, it was just that this particular site had the hots for standby databases. It was used so heavily that we would have probably run into some problems whatever we used. (Although I know a few ex-colleagues who might want to leave a few curses in the comments!)<\/li>\n<\/ul>\n<ul>\n<li>Extra disk mirrors. By this I mean something like synchronising disks on a SAN so that updates to one set of disks are propagated to another set, either syncronously or asynchronously. We use a lot of this at my current site, but there are maximum distances if you want synchronous updates and unless you have the technology and the storage administrators who understand it, this won&#8217;t be an option for many people.<\/li>\n<\/ul>\n<p>Speaking of synchronous and asynchronous updates brings me on to the next area to consider.<\/p>\n<p><b>Update lag (or currency)<\/b><\/p>\n<p>There is a tension at the centre of any disaster recovery-related replication design. <\/p>\n<p>On the one hand, we want the copy or standby database to be the most up-to-date copy possible because if we need to use it, we&#8217;ll have less redo information to apply to bring it up to date, which will improve recovery time and we&#8217;d ideally like to implement a no data loss solution. i.e. Unless a transaction commits on the Standby, it won&#8217;t commit on the Primary so the databases should always be identical. This is what Data Guard&#8217;s Maximum Protection mode offers and it sounds like another excellent idea. <\/p>\n<p>If you ask the users how much down-time they can stand and how much data they can afford to lose (and you absolutely have to ask), then their first answer will nearly always be &#8211; no down-time and no data loss.<\/p>\n<p>On the other hand, that could cause a number of problems.<\/p>\n<ol>\n<li>The Primary is now dependant on the Standby being operational. If the Standby is down, Oracle has to shutdown the primary or the Standby wouldn&#8217;t be synchronised any more. That doesn&#8217;t sound promising to me because it makes everything <em>more<\/em> fragile and failure-prone.<\/li>\n<li>In the event of someone screwing up on the Primary, you can guarantee that the same error is going to exist\u00a0on the Standby &#8211; that&#8217;s the way it works!<\/li>\n<\/ol>\n<p>The worst news is that I&#8217;m not going to give you any answers here &#8211; just more questions. I&#8217;m like that &#128521; <\/p>\n<p>In the old days there was a built in time lag of anything that was in the current online redo log file, plus how long it took to ship the archived\u00a0copy over to the standby server and apply it. These days you have more options and\u00a0need to think about them.\u00a0For example, a\u00a0time lag of several hours would give you time to notice someone screwed something up on the primary before allowing it to be applied to the standby but, then again, maybe flashback features are more useful for that kind of thing?<\/p>\n<p>I think the next blog will probably be the last &#8211;\u00a0wrapping up this mini-series, forming some unsatisfactory conclusions and offering some very satisfactory sources of further information.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>There was a good reaction to part 3 with sensible comments from people who&#8217;ve obviously &#8216;been there, seen it, done it, bought the t-shirt&#8217; and handled their share of tricky system failures, so thanks to all. The comments are interesting reading for other perspectives and ideas. Although the sub-title to this part is &#8216;you need&hellip; <a class=\"more-link\" href=\"http:\/\/orcldoug.com\/blog\/2006\/11\/02\/recovery-design-part-4-you-need-more-than-one-database\/\">Continue reading <span class=\"screen-reader-text\">Recovery Design part 4 &#8211; You need more than one database<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1120","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":1117,"url":"http:\/\/orcldoug.com\/blog\/2006\/10\/31\/recovery-design-part-3-what-is-it-with-rac\/","url_meta":{"origin":1120,"position":0},"title":"Recovery Design part 3 &#8211; What is it with RAC?","date":"October 31, 2006","format":false,"excerpt":"For the next few parts of this mini-series, I'm going to start looking at the initial high level design for the system and how well it meets the requirements. First of all I'm going to talk about the most critical database from the business perspective. I'll call it the User\u2026","rel":"","context":"With 16 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1124,"url":"http:\/\/orcldoug.com\/blog\/2006\/11\/07\/recovery-design-part-5-wrap-up\/","url_meta":{"origin":1120,"position":1},"title":"Recovery Design Part 5 &#8211; Wrap-up","date":"November 7, 2006","format":false,"excerpt":"It's been a very mini-series but I hope I've highlighted some of the challenges when designing systems that need to recover from failures quickly. Here are a few ideas and I'm sure others could add their own.Careful planning is essential.Ask tough questions and imagine the worst.Always be aware of the\u2026","rel":"","context":"With 7 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1306,"url":"http:\/\/orcldoug.com\/blog\/2007\/08\/07\/full-volume-database-refresh-part-3\/","url_meta":{"origin":1120,"position":2},"title":"Full Volume Database Refresh &#8211; Part 3","date":"August 7, 2007","format":false,"excerpt":"After solving the jigsaw puzzle and waiting for tape drives to do their thing, we've finally got a running test instance accessing a full copy of production. (Well, there was some recovery, faffing around with database names, control files, tempfiles, putting the database in noarchivelog mode and the rest, but\u2026","rel":"","context":"With 10 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1337,"url":"http:\/\/orcldoug.com\/blog\/2007\/11\/04\/the-reality-gap-2-disaster-recovery\/","url_meta":{"origin":1120,"position":3},"title":"The Reality Gap (2) &#8211; Disaster Recovery","date":"November 4, 2007","format":false,"excerpt":"I'm going to keep this one short and sweet because I've talked about it before. Because it's based around a single shared database, RAC will not (and was never designed to) protect you from Database corruption Erroneous updates or deletes by a user (or DBA!) More to the point, all\u2026","rel":"","context":"With 16 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1304,"url":"http:\/\/orcldoug.com\/blog\/2007\/08\/04\/full-volume-database-refresh-part-1\/","url_meta":{"origin":1120,"position":4},"title":"Full Volume Database Refresh &#8211; Part 1","date":"August 4, 2007","format":false,"excerpt":"(... or the Refresh from Hell) This weekend will be the final practice run (there's been one already) for a database refresh procedure I'll be working on for a further four weekends. It's a full copy of one of our production databases that forms part of a user acceptance test\u2026","rel":"","context":"With 17 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1376,"url":"http:\/\/orcldoug.com\/blog\/2008\/01\/12\/8-useful-technical-posts\/","url_meta":{"origin":1120,"position":5},"title":"8 Useful Technical Posts &#8230;","date":"January 12, 2008","format":false,"excerpt":"That number in the title is not a joke or an attempt to drag out the pain. However, OraNA has been flooded with '8' posts this week, so I thought it worthwhile to post a quick list of some really nice technical posts I've noticed over the last couple of\u2026","rel":"","context":"With 2 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1120","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/comments?post=1120"}],"version-history":[{"count":0,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1120\/revisions"}],"wp:attachment":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/media?parent=1120"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/categories?post=1120"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/tags?post=1120"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}