| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Minimizing backup induced downtime
fitzjarrell_at_cox.net <fitzjarrell_at_cox.net> wrote:
> Comments embedded.
That's the way I like it best ;)
> On Jul 12, 6:33 am, Alexander Skwar <alexan..._at_skwar.name> wrote:
>> 1) Shut down application, which uses Oracle as a backend
>> 2) Shut down Oracle
>> 3) Create filesystem snapshots with ZFS on Solaris 10
>> 4) Start backup to tape of filesystem snapshots. When done, remove
>> snapshots 5) Startup Oracle
>> 6) Startup application
>>
>> The step 4 is run in the background. Because of this, the actual
>> downtime is very small (a matter of seconds. At most, it's 1 minute).
>> I'm currently shutting down everything, so that the files on backup are
>> in a consistent state.
>>
> > Everything? Or everything application-related? I think it's the > latter, but please clarify this.
Yes, it's the latter. I shutdown "everything application related". Ie. I'm doing "/etc/init.d/teamcenter stop ; /etc/init.d/oracle stop". This shuts down "everything".
Sorry. I should have been clearer.
>> I'm now thinking about how to fit RMAN into this picture. I think it
>> might look something like this:
>>
>> 1) Shut down application, which uses Oracle as a backend
>> 2) Have RMAN create backup of database
>> 3) Create filesystem snapshots with ZFS on Solaris 10
>> 4) Start backup to tape of filesystem snapshots. When done, remove
>> snapshots 5) Startup application
>>
>> Here, step 3 is in background. But I cannot start step 3, before step 2
>> is actually finished. Because of this, the downtime of the application
>> will be larger, won't it?
> > Yes, since you are disallowing access to the database during the > backup, which isn't necessary for RMAN to complete its job.
Yes, as far as just the "simple" Oracle side is concerned, I could leave Oracle running while RMAN runs (or isn't it rather, that I actually NEED to leave Oracle running?). That's understood.
> But you > do list valid concerns further down the post. >
> > That depends upon when the update/insert/delete occurs and on which > table/tablespace is affected.
Ja. Nein. :) I'm actually not so much concerned about the Oracle side of things. One thing I forgot to mention is, that I've got two "databases" (or maybe I haven't emphasized this point strong enough):
The vault is managed by the application. It stores files there and also stores "pointers" to these files in some table in Oracle. The vault is essentially just a directory (with some subdirs). BTW: Changing the application is *not* possible. At least it's not realistical.
The problem is, that users could, through the application, delete and maybe even modify files, which are stored on this directory. So, suppose the following timeline:
|-------------------|-----------------|-------|--> 1 2 3 4
At t1, I start RMAN backup. RMAN backup is finished at t3. At t4, I'd create the snapshots (what I called step 3 at my previous list of tasks).
Now at t2, a user comes in and deletes or even worse (IMO) modifies a file. The backup starts essentially at t4. At this point in time, the database "says" that there should be a file xyz.doc with such and such contents, but in reality, the file is either gone (user deleted it) or it has a different content. Granted, the chance of that happening is close to zero at my setup, as the backup is done at a time of night, when "usually" nobody works. But there's just the slim chance of something like this happening.
Anyway. I'd like to get to a point, where it's (close to) impossible for a user to modify files while the backup is running.
Hm.
Maybe my problem is, that the time difference between t1 and t4 is too large. Maybe it would be better for me, to do:
Step 1) takes a split second. So there's of course the odd chance that somebody hops in at point "1.5", but I think that's very unlikely to happen (as I wrote already, I'm doing the backup at a time of night, where the system is not used by users - "normally").
Hm. Maybe that's the way to go. The advantage would then be, that there's no downtime at all for doing the backup. However, recovery will take longer and will be much more complicated than with a simple Shell Script based backup. Hm. With some good documentation on how to rebuild a system in case of a crash, that shouldn't be such big a problem.
>> Even worse - the FS snapshot
>> doesn't "harmonize" with what's in the DB (the application
>> creates/deletes files in a so called "vault", which is some directory on
>> the server).
>>
> Now you have a situation where possibly what you are currently doing
> is a better strategy for your environment than using RMAN would be.
It's at least a more simple approach. IMO. Not as far as taking the backup of Oracle is concerned. But Oracle is just one piece in this puzzle. And as far as business is concerned, it's not even the most important one - the vault is more important.
> Restoring your current snapshots would provide a working database; > restoring snapshots created by your second scenario would require a > restore and recover operation through RMAN, consuming more time.
Yep. And as far as the business is concerned, there'll be no advantage in the RMAN based backup. At least none that's relevant (downtime in the middle of the night is acceptable - especially as it is a downtime of just a few seconds).
>> Because of all of this, I'd like to shutdown the application while RMAN
>> is running.
> > And that's fine, however I have noted some issues with your proposed > backup strategy using RMAN which you won't have with your current > method.
Thanks.
>> In such a scenario/setup, wouldn't RMAN make the downtime larger?
>
> Yes, both on the backup side and on the recovery side.
Oh. Valid point from you. I didn't even consider recovery yet. With my current setup, all I need to do is a full restore in a case of a full disaster (ie. server burned down). That's quite a simple task, as I just need to restore everything and I'm directly back in a working state.
Thanks a lot for taking the time to read and post a helpful response. I appreciate it!
Alexander Skwar Received on Thu Jul 12 2007 - 09:14:19 CDT
 |
 |