If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back  dBforums > Database Server Software > Oracle > FRA Needed For Consistent Backup?

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old
Registered User
 
Join Date: Oct 2010
Location: Orlando, FL
Posts: 261
FRA Needed For Consistent Backup?

I'm going to backup this un-maintained Oracle 11g server in my office. I'm being told it's never been backed up and extremely critical to our success so tomorrow I'll be performing my 1st backup of the database using RMAN. My question is if I connect to the Oracle 11g database and run the:

Code:
[oracle@db1 ~]$ rman target=/

Recovery Manager: Release 11.2.0.1.0 - Production on Mon Feb 13 13:18:05 2012

connected to target database: CQDB (DBID=1854033249)

RMAN> shutdown immediate

using target database control file instead of recovery catalog
database closed
database dismounted
Oracle instance shut down

BACKUP DATABASET FORMAT /oracle/u01/app/oracle/backup/%d-%T-%s-%P;
My question is this sufficient for a safe full backup? We only have the one single target database called 'cqdb' which houses several schemas. Can you tell me if this is correct? I've shut the database down so it's in a cold state or what Oracle calls consistent, correct?

What about the 'archivelog' files? Do I back those up? Do I need them in case a recovery? Also what about the 'controlfile'? Do I need to back those up as well as the mentioned above?
Reply With Quote
  #2 (permalink)  
Old
Registered User
 
Join Date: Aug 2003
Location: Where the Surf Meets the Turf @Del Mar, CA
Posts: 7,495
>What about the 'archivelog' files?
I give up.
does this DB have ARCHIVE MODE enabled for REDO log files?
__________________
You can lead some folks to knowledge, but you can not make them think.
The average person thinks he's above average!
For most folks, they don't know, what they don't know.
Don't say, show. Don't promise, prove.
Reply With Quote
  #3 (permalink)  
Old
Registered User
 
Join Date: Oct 2010
Location: Orlando, FL
Posts: 261
Quote:
Originally Posted by anacedent View Post
>What about the 'archivelog' files?
I give up.
does this DB have ARCHIVE MODE enabled for REDO log files?
Give up on what? I'm sorry I'm new to Oracle so please be patient if I don't fully understand what you've been doing for a lot longer than myself. As for ARCHIVE MODE, it appears to be disabled.

Code:
SQL> archive log list;
Database log mode	       No Archive Mode
Automatic archival	       Disabled
Archive destination	       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     1579
Current log sequence	       1581
I have not enabled ARCHIVE MODE since I'm planning on performing a backup once the database has been shutdown.

So since the database is 'shutdown immediate', do I need:

1. Enabled ARCHIVE MODE?
2. Configure Flash / Fast Recovery Area?
3. Backup controlfile?
Reply With Quote
  #4 (permalink)  
Old
Registered User
 
Join Date: Mar 2010
Location: Vienna, Austria
Posts: 149
I understand you've inhereted this DB and want to backup it.
Follow the procedure below and you'll have a consistent backup, but DO familiarize yourself with the architecture of Oracle immediately after that.

First of all:
"extremely critical to our success" and "NOARCHIVELOG" doesn't go together well usually (NOARCHIVELOG mode is only meant for development and training DBs)

And:
NO, the procedure you suggested in you original post will NOT work (In NOARCHIVELOG mode the DB must be mounted to do a RMAN cold backup)

And:
flashback does not work in NOARCHIVELOG mode

And:
You don't have to care about archivelogs in NOARCHIVELOG mode (mainly because no archivelogs are written in this mode)

To to a "cold" backup follow this:

Code:
rman target /
RMAN> shutdown immediate;
  <skipped RMAN output>
RMAN> startup mount;
  <skipped RMAN output>
RMAN backup database include current controlfile format '<path_to_your_backup_dir>/CQDB_%U.bkp';
  <skipped RMAN output>
alter database open;
  <skipped RMAN output>
exit
This will provide you with a complete and consistant backup that allows you restore the DB to the point in time (and ONLY to that) you took the backup (that's why it's not usable for a "real" backup: imagine you take the backup at 1am and lose a datafile at 5pm: you would lose all transactions of the day).

After that, you should switch the DB into ARCHIVLOG mode (after making sure, you have enough disk space in the archival directory) and take regular backups.

I strongly recommend to take a look (at least) into the concepts guide, the administrator's guide and the backup and recovery user's guide to read about archiving and its implications (and my advise would be: forget about flashback, until you understand the rest)
__________________
"There is always an easy solution to every problem - neat, plausible, and wrong."
-- H.L. Mencken

Last edited by magicwand; 02-13-12 at 16:09.
Reply With Quote
  #5 (permalink)  
Old
Registered User
 
Join Date: Oct 2010
Location: Orlando, FL
Posts: 261
Quote:
Originally Posted by magicwand View Post
First of all:
"extremely critical to our success" and "NOARCHIVELOG" doesn't go together well usually (NOARCHIVELOG mode is only meant for development and training DBs)
OK so I've done the following:

1. Enable ARCHIVELOG mode on my database:

Code:
SQL> archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     1582
Next log sequence to archive   1584
Current log sequence	       1584
I've configured the 'Fast Recovery Area and also allocated what I feel to be sufficient disk space to the quota:

Code:
SQL> show parameter recovery_file_dest;

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest		     string	 /oracle/u01/app/oracle/backup
db_recovery_file_dest_size	     big integer 100G
Quote:
This will provide you with a complete and consistant backup that allows you restore the DB to the point in time (and ONLY to that) you took the backup (that's why it's not usable for a "real" backup: imagine you take the backup at 1am and lose a datafile at 5pm: you would lose all transactions of the day).
Is this what ARCHIVELOG mode allows me to do? "Real" backups so if I need to restore a file from 5pm and my backup was done at 1pm, I wont lose all the data assuming archivelog mode is enabled, correct? I'm in the process of reading the documentation and here's what I understand to be correct and please correct me if I'm wrong:

1. Database should always be in ARCHIVELOG mode.
2. FRA (Fast Recovery Area) is just a disk path / and size quota on where my backups are managed, correct?
3. ARCHIVELOG mode enabled just means to me that I can now do a "Point-in-time recovery" & not lose the data that was written between 1:01 pm - 4:59 pm wont be lost, correct?

So now since my database is in ARCHIVELOG mode and I've configured the (FRA), all I should do now to get a "real" backup is:
Code:
RMAN> backup database plus archivelog delete input;
So as I continue reading your suggestions, can you please tell me if I'm on the right track with my assumptions of the guides and what I've learned so far?

Thanks for your time and references. I've got a lot to read...
Reply With Quote
  #6 (permalink)  
Old
Registered User
 
Join Date: Mar 2010
Location: Vienna, Austria
Posts: 149
Quote:
[...] can you please tell me if I'm on the right track with my assumptions [...]
Yes you are, if you don't lose all of your control files (I've seen this happen on a SAN with a collapsing RAID controller)

(BTW: You are aware, that you don't have to shutdown the DB for backup when it is in ARCHIVLOG mode, aren't you?)

You can include the controlfile in 2 possible ways:

1.) Make it part of the backup command (each time you do the backup)
Code:
RMAN> backup database include current controlfile plus archivelog delete input;
or

2.) Configure it in the RMAN repository (You only have to do this once per database):
Code:
$ rman target /

Recovery Manager: Release 11.2.0.3.0 - Production on Tue Feb 14 22:17:33 2012

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: WRE11 (DBID=3681478001)

RMAN> show CONTROLFILE AUTOBACKUP;

using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name WRE11 are:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;

RMAN> configure controlfile autobackup on;

old RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
new RMAN configuration parameters:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
new RMAN configuration parameters are successfully stored

RMAN> exit

Recovery Manager complete.
And - of course - the backup pieces produced by RMAN should be copied to a save place (meaning not the same physical disk or SAN).

If this DB is really as critical as you mentioned in your original posting, you should consider placing a copy at an external place like a bank safe (might sound exaggerated, but as DBA that has seen a lot you tend to get paranoid)

Next read about rman RETENTION POLICIES the "CROSSCHECK", "DELETE EXPIRED BACKUP", and "DELETE OBSOLETE DEVICE TYPE DISK" commands.

You will need this to administer your backups (you should not delete old backup pieces manually on OS level, because RMAN keeps information about the backups in the controlfiles)
__________________
"There is always an easy solution to every problem - neat, plausible, and wrong."
-- H.L. Mencken

Last edited by magicwand; 02-14-12 at 17:38. Reason: typos fixed
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On