Database Continuity
Ever just have a burning desire to do something that never seems to go away? For me, that desire has been to write a book; more specifically an Oracle technology-based book. (Okay, maybe a novel later on in life...) I thoroughly enjoy researching Oracle technology and finding solutions to puzzling questions. I am, however, pragmatic and seek to understand that which I can put to good use in the future.
I was recently discussing this desire with a colleague. I told him that I felt there was a need for a really good backup and recovery book. Actually, I expounded a bit and said that there is a need for a good database continuity book. It just feels that backup and recovery is an overused phrase for a dramatically underutilized and uncultivated set of skills. After all, how frequently are we involved in backup and recovery exercises? I would guess that backup and recovery activities comprise less than 5% of the time spent by a DBA during the course of any given year. That would be less than 100 hours in a full work year. I suspect it could be much less for some.
Isn't spending little or no time on backup and recovery a good thing? That does imply our systems are resilient and few faults surface that require us to exercise our recovery plan. And, in the age of RMAN we simply don't have to worry about the nuances of recovery, right? RMAN knows exactly what is needed for restoration, and all the DBA needs to do is execute a few commands to restore and recover the database. What technology has afforded us with regard to ease of backup configurations and redundant infrastructure, it has equally reduced our ability to confidently take control when up against a critical database recovery scenario. In short, we become complacent and our knowledge of backup and recovery diminishes over time. How confident are we that our backup strategy meets the recovery point (RPO) and recovery time (RTO) objective of our business?
I digress. Let’s get back to the conversation with my colleague and this notion of database continuity. I defined for him database continuity as follows: Database continuity is a superset of knowledge, processes and tools that fulfill the data protection requirements of an organization. By consequence, backup and recovery become processes in the continuity methodology. Database continuity is a broadened perspective of Oracle database recovery and is intended to include: disaster recovery, standby databases, archive log management, user-managed backups, RMAN, RPO and RTO, etc. Each of these aspects of database continuity requires the DBA to have a firm understanding of Oracle database recovery. If we truly understand recovery these different continuity dimensions converge rapidly. You can plug in your knowledge of recovery to assist with any dimension. So, while the notion of database continuity has greater breadth at face value, it can be reduced to recovery mechanics, constructs and objectives.
That being said, I have many ideas about a book on Oracle database continuity. However, I want to hear from you. What do you find lacking in the backup and recovery books on the market? Maybe one text speaks to an aspect for which you wish the author had given more detail. Or, maybe there is an overindulgence of certain topics that you wish had been left out. What material would help you retain and reuse your recovery knowledge? I am not out to write a book on RMAN or Data Guard; thousands of pages have already been devoted to the treatment of these technologies. I view guides on such topics as utilities to affect my recovery objectives and mobilize my recovery knowledge.
I was recently discussing this desire with a colleague. I told him that I felt there was a need for a really good backup and recovery book. Actually, I expounded a bit and said that there is a need for a good database continuity book. It just feels that backup and recovery is an overused phrase for a dramatically underutilized and uncultivated set of skills. After all, how frequently are we involved in backup and recovery exercises? I would guess that backup and recovery activities comprise less than 5% of the time spent by a DBA during the course of any given year. That would be less than 100 hours in a full work year. I suspect it could be much less for some.
Isn't spending little or no time on backup and recovery a good thing? That does imply our systems are resilient and few faults surface that require us to exercise our recovery plan. And, in the age of RMAN we simply don't have to worry about the nuances of recovery, right? RMAN knows exactly what is needed for restoration, and all the DBA needs to do is execute a few commands to restore and recover the database. What technology has afforded us with regard to ease of backup configurations and redundant infrastructure, it has equally reduced our ability to confidently take control when up against a critical database recovery scenario. In short, we become complacent and our knowledge of backup and recovery diminishes over time. How confident are we that our backup strategy meets the recovery point (RPO) and recovery time (RTO) objective of our business?
I digress. Let’s get back to the conversation with my colleague and this notion of database continuity. I defined for him database continuity as follows: Database continuity is a superset of knowledge, processes and tools that fulfill the data protection requirements of an organization. By consequence, backup and recovery become processes in the continuity methodology. Database continuity is a broadened perspective of Oracle database recovery and is intended to include: disaster recovery, standby databases, archive log management, user-managed backups, RMAN, RPO and RTO, etc. Each of these aspects of database continuity requires the DBA to have a firm understanding of Oracle database recovery. If we truly understand recovery these different continuity dimensions converge rapidly. You can plug in your knowledge of recovery to assist with any dimension. So, while the notion of database continuity has greater breadth at face value, it can be reduced to recovery mechanics, constructs and objectives.
That being said, I have many ideas about a book on Oracle database continuity. However, I want to hear from you. What do you find lacking in the backup and recovery books on the market? Maybe one text speaks to an aspect for which you wish the author had given more detail. Or, maybe there is an overindulgence of certain topics that you wish had been left out. What material would help you retain and reuse your recovery knowledge? I am not out to write a book on RMAN or Data Guard; thousands of pages have already been devoted to the treatment of these technologies. I view guides on such topics as utilities to affect my recovery objectives and mobilize my recovery knowledge.
posted by Eric S. Emrick at 3/04/2009
6 Comments:
Eric,
I shall start from saying that its just SO GOOD to see you back in the blog wagon, hope the fuel tank of it is completely filled to keep it running for a much long time :-) .
About the book, its an excellent idea. For me a book should be collection of technical details, both in the terms of theory and practical plus, it should contain the wisdom and thoughts of the writer about the topic. A book just talking about, Recover Db , Restore db and its know hows only, is just a B/R book.
Now, as the technical part have come up and we are talking about B/R, I believe,giving the readers a good understanding of the architecture involved, explaining the issues with the methods to resolve them are some things which are must. But if one wants to make it Database Continution book, there should also be talks what to do before hand so that these errors must not come, a proactive approach, if we may call it so.
I would suggest you to check the 2 top notch books of B/R, atleast in my opinion and see what more you can add to them/in their writing/content.
1) Backup Recovery by Rama Velpuri
2) Backup Recovery 101 by Smith, Haisley
Regards
Aman....
Thanks for the feedback Aman. I hope the juices keep flowing. Strangely enough, sitting on the bookshelf behind my desk are the two books you have mentioned. The only other text I have are BR are the Oracle docs. I remember meeting Haisley at a symposium. He is a really nice person and has a great grasp on recovery.
Rama's book is still my favorite as it is still the best on the market with regard to recovery internals. It still sells on Amazon for $50 USD.
As for the book, I was thinking about dedicating several sections to recovery internals: the constructs, the mechanics and the semantics. Everytime I think of recovery I think in terms of pictures and timelines. If the reader truly "gets" the mechanics involved in recovery then any scenario can be handled with confidence. There is so much information in the data file headers as well as the v$ views, that if interpreted properly, can give great insight into a recovery issue at hand.
What about proper archive log managment? I have seen too many environments' recovery plans be comprised by bad archive log management: great database backup plan, horrible archive log management.
Database continuity could start with a solid treatment of the recovery mechanics, constructs and semantics. Then topcis like RPO and RTO can be discussed. How do you really know you can meet your RTO if you have no idea how long it takes to recover N bytes of redo in your database. There are approaches to determine this without the presence of a standby database and it has much to do with redo-clustering: what is the average density of our redo change vectors? Density could be defiined by the ratio (number of redo records)/ (number of blocks required to replay those records). If your density is high, then you are reading fewer blocks to perform recovery and get greater recovery throughput.
I could go on and on, but I think you get the idea. The database continuity features of Oracle converge at recovery. With a firm grasp of recovery a DBA can tackle that scary recovery, build that standby configuration, ensure RPO and RTO, manage archive logs/flashback logs, etc. I'll stop now :)
Hi Eric,
If possible, I would love to see
/ co-author a book that covers the whole spectrum of database environments and associated business continuity aspects(from ones residing on a standalone windows / linux box to ones residing on allmighty SAN).
Various kinds of architectures involved and how business continuity for databases residing in such environments could be maintained.
I think, HA/Clustering should be covered also (the degree could vary). Lot of these architectures are so closely intertwined that merely confining ourselves to the database nitty gritties contribute to the in-the-silos decision making process during any business continuity scenario.
Perhaps, this increases the scope of your original thought, however, I believe, this will be much more value for a would be buyer's money.
-Rajeev
Eric,
Saw your blog by chance when looking for some information. Any book which is a good read is a good book, so go-ahead and write it. Having said that, your post of Continuity is simply recovery. Customer build backup solution with a backup plan not a recovery plan. Think about it, recovery is simply dependent on the resources you have or plan to acquire,the 3M's, Man , Machine and Money.
DR again is continuity, like RAMA Velpuri's outstanding recovery case studies that we grew up learning in the early ninetines, you can write something similar, case studies on DR. Continuity can spawn off so many scenarios, believe me the permutation and combinations that can be built with NEAR SITE DR and FAR SITE DR grows depending on what you can spend.So a book on continuity is not a bad idea atall and I am sure you can pull it off. Good Luck.
I believe you may be also interested in the tools backup restore outlook2007
Thaank you for sharing this
Post a Comment
<< Home