Omarsoft For IT Solutions (Java Codes ,C#.NET Codes , ASP.NET Codes ,VB.NET Codes ,Oracle Database Administration, Real Application Cluster , Remote Support, Cloud Services , Networks ,Virtualization....
  • الأنظــمــة المكتبية        Windows App Programming
  • أنظــمـةالويــب        Web based systems programming
  • تطبيقات الهواتف الذكية     smartphones programming
  • إدارة قواعــــــد البيــــــــــــــــانات        Database Administration
  • إدارة الشبكـــــــــــــــــــــــــــــــــات        Networks Administration
  • إدارة الســـيــرفرات (ويب - محلية)  Servers Administration
  • إدارة مخـــــــــــــــــازن البيــــــــــــانات     Storage Administration
  •             N Computing & 2X Application services

    Social Icons


Creating a Disaster Recovery Plan

Creating a Disaster Recovery Plan 

Last week we decided on how often to backup our database; now we must decide where to backup our database. The first option available is to backup directly to tape from SQL Server. On the plus side, a backup to tape allows for off-site storage of backups. On the down side, tape backups are slow and therefore can impact the server for a longer amount of time than a backup to a file. The other common place to backup to is a file. File backups are much faster than a tape backup, for both backup and restore operations; however, backups to files don't allow for quick off-site storage (unless you happen to have a high speed remote link).
A third option is to use a combination of making backups to a file and then using another backup utility, such as NT Backup, to copy the file backups to tape. By making backups to files on another server nearby and then copying the files to tape, you can minimize the time a backup will impact your SQL Server while still allowing for off-site storage of tapes. Also, if you need to make multiple copies of tape backups, using another computer for copying backups to multiple tapes can help even more.
Another thing to think about when you are choosing where to make a backup is the time it takes to restore a backup. For example, a backup that is stored on another computer could be restored much faster over a high speed network than it could be from a tape drive. To take advantage of this faster recovery you may consider saving file backups for the week on another computer (in addition to your tape backups). In the event your SQL Server crashes you have a current backup on hand and available at a faster speed than tape.
File and tape backups do provide for lots of flexibility in designing your disaster recovery plan, but there are still many options available from third party venders. For example, you can find utilities that make the process of making backups of multiple SQL Servers very simple. You may also consider a Storage Area Network for large mission-critical systems. Although I would love to cover every option available, other backup utilities and hardware options are outside the scope of this series.
Before we can move on, there is a second half to deciding where to backup...choosing a tape, or file for that matter, rotation. If you used a new tape for each day's backup you would probably eat up a good part of your budget on nothing but tapes. In order to save money a few popular tape rotation schemes are in use. The rotation we are going to look at is known as the Grandfather-Father-Son rotation. Let's look at our example from last week to see how this rotation works (note: I have rearranged the order of the days from the last article):

12:00 AMFULL
1:00 AM
3:00 AM
In a Grandfather-Father-Son rotation you start out by using a new tape for each day of the week for the first week. For each week following the first week you reuse the same tapes except for the last tape of the week. By using a new tape at the end of each week you can keep an archive of data. In the event you need to restore data that was deleted or lost, the archive from past weeks is available. Once a month has gone by you keep the tape for the last week of that month and then reuse the end-of-week tapes. Here is what a Grandfather-Father-Son rotation would look like for our example over a two month period:
11 Tapes are used: M, T, W, TH, F, S, W1, W2, W3, Month1, Month2...

Week 1
Week 4MTWTHFSMonth1

Week 5
Week 8MTWTHFSMonth2
In our example we must take the monthly backup on Sunday because that is the only day we make a full backup. However, if you make a full backup of your database every day of the week you can use the monthly tape on the last day of the month no matter what day of the week it ends on. To illustrate, this is what a Grandfather-Father-Son rotation would look like if we took a full backup every night for the next two months:
Note that a new tape is substituted for the last day of each month. Also note that once the last day of the month has passed, the end-of-week tapes can then be reused.
May 2002, Wednesday 1st - Friday 31st:
Week 1
Week 5MTWTHMonth1
June 2002, Saturday 1st - Sunday 30th:
Week 1
Week 5MTWTHFSMonth2

Having decided on how often to backup and where to backup, you now must choose a location to store your tapes. Deciding on a location is going to depend greatly on your situation, but there are some general rules you should keep in mind. First of all, the location, either on or off-site, should be secure! If someone has access to your might as well give them access to your server. Second, you need to find a balance between keeping the most recent tapes nearby (in case you need to restore a database) vs. the need to store tapes off-site (in case of a disaster).
One approach that we talked about earlier is storing a file backup on a second computer from your SQL Server. By doing this, not only can you recover from a crash faster, but it also allows you to store tapes off site without having to worry about going to get them to restore a database. You can also accomplish this same effect, minus the faster restore time, by making two sets of tape backups; one off-site for storage and one on-site for quick access. You may even consider making a third copy of your monthly backup for storage in a third off-site location. Also keep in mind that you don't have to keep all your tapes off-site. Depending on your needs, you may find that keeping the weekly backups, or even the monthly backups, off-site is adequate.
Before I move on, there is one last issue with backups that I would like to cover -- choosing someone to swap tapes. Once you have your plan in place you should designate a single person responsible for checking that backups took place and that tapes are swapped out as needed. It is important to have one person do this because when multiple people share the responsibility you end up with: "I thought you swapped the tapes last night?!?" When a single person is responsible for backups it becomes a routine for them. Now, if that one person is unable to swap tapes (ex: they get sick) it is their responsibility to find another person to swap tapes for them. Although another person may do the job of swapping tapes now and then, you still have the accountability of the single person who normally does the tape swapping, not a group of people. If the job is too big for one person, consider giving the responsibility for half the servers to one person and half to another person (or however you would like to split them up). Additionally, if you can't have the same person swapping tapes every day (ex: you take backups on the weekend), make it clear who is responsible for what days and keep the days the same from week to week.
So, having decided how often to backup, where to backup, and where to store our backups...what's left in a disaster recovery plan? Well quite a lot, but most of it is highly dependent on your environment. The first step is to document, document, and document. Get a folder and dedicate it to your disaster recovery plan. Here are some things that you should include in your plan:
- Server Hardware Specifications
- Network Layout
- Server Software Configurations
- Database File Layout (i.e. log files and data files)
- Label your tapes and include a backup and rotation description
The next step is to start thinking about, and write down, what should happen if a failure occurs. Keep in mind when you start to write out the plan, you should assume that you are not on-site and are unable to come to the rescue. You should also assume that the person restoring the server does have technical knowledge about SQL Server, but knows nothing about your particular setup. Think about things like:
- Who should be contacted if something goes wrong?
- Where are the backups stored?
- Where are the software and driver disks stored?
- Are there any tech support numbers available?
- If new hardware is required, what should be done?
- Is there any other information that may be useful?
Once you have completed documenting what should happen if a disaster occurs, there is one final step that you must complete...testing your plan. Having a plan is not enough, you have to test to see if your plan has all the necessary information, if your backups work correctly, and if everyone knows what to do. In order to do this you should setup a fake disaster. Now, don't go lighting your servers on fire (we all know how tempting that can be sometimes!), but use some extra hardware to test your plan. Don't worry about getting exactly the same setup (hardware wise), you will need just enough to run the services and any client applications. When testing, you should follow your disaster recovery plan and see if all the information is available in the plan. If you left anything out, or something was wrong, now is the time to make corrections and additions. By using the test hardware you not only get a feel for what information needs to be in your plan, but you are also able to test your backups by restoring the server from tape.

Oracle GoldenGate Overview

Oracle Corp. has acquired so many companies of late that it's getting to be a job to keep up with things. GoldenGate is one of the products you'll want to stay on top of. It's still kind of under the radar, but it's going to be big. Really big.
Oracle (the corporation) has acquired so many other companies as of late that it’s getting to be job in and of itself to keep up with things. But with GoldenGate, this is one of the products you’ll want to be familiar with. This is one of those products or features where its usage and user base (at least within Oracle) is still kind of under the radar, but it’s going to be big. Really big.
We all know about data within a database, and how to put it in via a database language such as SQL. And we’re familiar with SQL reaching out to another database. But that’s something typically done ad hoc or via a job. How do you “flow” data from one database to another, hands free? That is, an insert on Table A in Database A gets propagated to Table A on Database B? Right now, Oracle Streams (named that I’m sure to reflect the idea of flowing streams of data) fulfills this requirement.
Oracle Streams comes with about, oh, 8,000 data dictionary views and DBMS built-ins, and is certainly not lacking in terms of complexity and moving parts. Additionally, a Streams implementation can include elements of Data Guard (specifically in the Downstream Capture configuration). With respect to Streams and Data Guard, GoldenGate encompasses both and can either augment or replace either tool.
So, what does it take to use GoldenGate?
First off, it takes money, as in more of it, because of how Oracle has chosen to license it. Its cost is tied to the database server licensing metric, so for one processor (perpetual), you’re looking at $17,500 for licensing and $3,850 for the first year’s support. Streams, in comparison, is included in whichever edition you use.
Second, using Linux as the host operating system, it’s a matter of downloading and uncompressing a tar file. Most everything for running GoldenGate is based out of a “ggs” directory. Running on Windows is a bit more involved because of services.
Finally, you have to get used to a new language replete with hundreds of new keywords using a not too complex syntax. The running of GoldenGate can be 100% command line interface. There is an optional add on product (Director) which offers a GUI-based centralized management feature.  do two things for you in terms of replication. Part of replication includes having a downstream or replicated copy (think of a restored backup, however you want to get that in place) of the target. If you choose, GoldenGate can perform the initial load, although it is recommended that you use native RDBMS tools for this step.
The second (and main) task is running and managing the replication process. Replicate how? From just one database to another, or something along the lines of what Streams can do (one-way, bi-directional, N-way)? The topology diagram below should cover just about every possible way you could envision replicating data.
Another neat feature of GoldenGate is that it practically couldn’t care less which database system you’re coming from or going to. It’s almost like a Mac: everything just works. GoldenGate mines transactions from what it refers to as transaction logs (so obviously in Oracle’s case, the redo logs). The extraction process creates “trail” files GoldenGate then sends to the RMTHOST (the remote host, and congratulations if you’re new to GoldenGate: you’ve just seen your first keyword). The configuration workflow diagram shown below highlights this agnostic approach to the database systems involved.
The reference to “Data Pump” in the diagram is not the same Data Pump used in Oracle. The concept is the same though (data being moved at a relatively high speed). Similar to Streams setup, access to the remote host is much easier to configure/perform if the admin account username is the same on all systems.
Under Step 4, you see the word Replicat. That is not a typo: Replicat is the word/term/process used in and by GoldenGate. If using GoldenGate for your replication needs, Replicat will become very familiar.
This leads us to the GoldenGate Software Command Interface, otherwise known as ggsci. GGSCI is to GoldenGate as SQL*Plus is to Oracle. The table below (partial listing) gives you an idea of what GGSCI uses word-wise. Note the INFO word in the left column: plenty of online (well, at least in your session) help is available simply by typing “help ” at the command line.
One of the downsides of Streams processing, where data is typically dealt with on a row-by-row basis for a logical change record (LCR), is that bulk loads can cause performance problems. GoldenGate, and Streams to a degree, has built-in access to SQL*Loader type APIs.
Timing is everything, so how does GoldenGate keep track of transactions? Just like everyone does by using a change number (for example, Oracle’s SCN, MSSQL’s LSN). GoldenGate’s internal bookkeeping “checkpoint” is based on a CSN, or Commit Sequence Number. Knowing the CSN allows you to pick up after a stopped or interrupted process.
For learning how to use GoldenGate, you definitely need to put hands on the keyboard and bang away. Understanding the relationship of parameter and definition files – at an abstract level – is simple; the rub is getting used to GoldenGate’s language and keywords. The sample data in the demo files included with the tool is seriously lacking. For teaching this class, one of the things I incorporate is running a stream of data. I mean, you want to see this work and observe its work in progress. Simply flowing two or three records in the demo files is fine for getting things to work in the first place, but after that, let’s fire this thing up and see what it does.
For the money it costs, especially if you are considering replacing Streams, you’re going to want to see a couple of advantages or benefits over what you’re doing now: a better/easier setup and management, and data being replicated at near real time. No product will ever be exactly real time, but we can get pretty close.

Sana'a Yemen - 50th st.

+967 738166685

للاتصال بنا CONTACT US

الاسم Name

بريد إلكتروني Email *

رسالة Message *

2015-2023 © All Rights Reserved Omarsoft
Back To Top