- 论坛徽章:
- 0
|
legato在备份ORACLE数据库时出现的问题
Backup Fails with Invalid RECID Error: Scenario
In this scenario, you attempt a backup and receive the following error messages:
RMAN-3014: Implicit resync of recovery catalog failed
RMAN-6038: Recovery catalog package detected an error
RMAN-20035: Invalid high RECID error
Backup Fails with Invalid RECID Error: Diagnosis
In one common scenario, you restore a backup control file created through a non-Oracle mechanism, and then open the database without the RESETLOGS option. If you had created the backup control file through the RMAN BACKUP command or the SQL ALTER DATABASE BACKUP CONTROLFILE statement, then Oracle would have required you to reset the online logs.
The control file and the recovery catalog are now not synchronized. The database control file is older than the recovery catalog, because at one time the recovery catalog resynchronized with the old current control file, and now the database is using a backup control file. RMAN detects that the control file currently in use is older than the control file previously used to resynchronize.
Another common scenario occurs when you attempt to copy the target database to a new machine as follows:
On machine 1, you shut down the database and make a copy of the control file with an operating system utility. You do not use CATALOG to add this control file copy to the repository.
You transfer the control file copy to machine 2.
On machine 2, you create a new initialization parameter file and new database instance.
You mount the control file copy on machine 2. Oracle does not recognize the control file as a backup control file: to Oracle it looks like the current control file.
You start RMAN and connect to the new target database and the recovery catalog on machine 2. Because the control file was not created with RMAN and was not cataloged as a control file copy, RMAN sees the database on machine 2 as the database on machine 1.
You restore and recover database the new database on machine 2 and then open it. As a consequence, various records are added to the recovery catalog during the restore and recovery. For example, the highest RECID in the recovery catalog moves from 90 to 100.
On machine 1, you start RMAN and connect to the original target database and recovery catalog. The recovery catalog indicates that the highest RECID is 100, but the control file indicates that the highest RECID is 90. The control file RECID should always be greater than or equal to the recovery catalog RECID, so RMAN issues RMAN-20035.
Backup Fails with Invalid RECID Error: Solution 1
This solution is safest and is strongly recommended:
To reset the database with RMAN:
Connect to the target database with SQL*Plus. For example, enter:
% sqlplus '/ AS SYSDBA'
Mount the database if it is not already mounted. For example, enter:
ALTER DATABASE MOUNT;
Start cancel-based recovery by using the backup control file, then cancel it. The reason for canceling is that the USING BACKUP CONTROLFILE clause stamps the controlfile as a backup, which then permits OPEN RESETLOGS. For example, enter:
ALTER DATABASE RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
ALTER DATABASE RECOVER CANCEL;
Open the database with the RESETLOGS option. For example, enter:
ALTER DATABASE OPEN RESETLOGS;
Use RMAN to connect to the target database and recovery catalog. For example, enter:
% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb
Reset the database. For example, enter:
RESET DATABASE;
Take new backups so that you can recover the database if necessary. For example, enter:
BACKUP DATABASE PLUS ARCHIVELOG;
Backup Fails with Invalid RECID Error: Solution 2
This solution is more difficult than solution 1:
To create the control file with SQL*Plus:
Connect to the target database with SQL*Plus. For example, enter:
% sqlplus 'SYS/oracle@trgt AS SYSDBA'
Mount the database if it is not already mounted:
SQL>; ALTER DATABASE MOUNT;
Back up the control file to a trace file:
SQL>; ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Edit the trace file as necessary. The relevant section of the trace file looks something like the following:
# The following commands will create a new control file and use it
# to open the database.
# Data used by the recovery manager will be lost. Additional logs may
# be required for media recovery of offline data files. Use this
# only if the current version of all online logs are available.
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "TRGT" NORESETLOGS ARCHIVELOG
-- STANDBY DATABASE CLUSTER CONSISTENT AND UNPROTECTED
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 1
MAXLOGHISTORY 226
LOGFILE
GROUP 1 '/oracle/oradata/trgt/redo01.log' SIZE 25M,
GROUP 2 '/oracle/oradata/trgt/redo02.log' SIZE 25M,
GROUP 3 '/oracle/oradata/trgt/redo03.log' SIZE 500K
-- STANDBY LOGFILE
DATAFILE
'/oracle/oradata/trgt/system01.dbf',
'/oracle/oradata/trgt/undotbs01.dbf',
'/oracle/oradata/trgt/cwmlite01.dbf',
'/oracle/oradata/trgt/drsys01.dbf',
'/oracle/oradata/trgt/example01.dbf',
'/oracle/oradata/trgt/indx01.dbf',
'/oracle/oradata/trgt/tools01.dbf',
'/oracle/oradata/trgt/users01.dbf'
CHARACTER SET WE8DEC
;
# Take files offline to match current control file.
ALTER DATABASE DATAFILE '/oracle/oradata/trgt/tools01.dbf' OFFLINE;
ALTER DATABASE DATAFILE '/oracle/oradata/trgt/users01.dbf' OFFLINE;
# Configure RMAN configuration record 1
VARIABLE RECNO NUMBER;
EXECUTE :RECNO := SYS.DBMS_BACKUP_RESTORE.SETCONFIG('CHANNEL','DEVICE TYPE DISK
DEBUG 255');
# Recovery is required if any of the datafiles are restored backups,
# or if the last shutdown was not normal or immediate.
RECOVER DATABASE
# All logs need archiving and a log switch is needed.
ALTER SYSTEM ARCHIVE LOG ALL;
# Database can now be opened normally.
ALTER DATABASE OPEN;
# Commands to add tempfiles to temporary tablespaces.
# Online tempfiles have complete space information.
# Other tempfiles may require adjustment.
ALTER TABLESPACE TEMP ADD TEMPFILE '/oracle/oradata/trgt/temp01.dbf' REUSE;
# End of tempfile additions.
Shut down the database:
SHUTDOWN IMMEDIATE
Execute the script to create the control file, recover (if necessary), archive the logs, and open the database:
STARTUP NOMOUNT
CREATE CONTROLFILE ...;
EXECUTE ...;
RECOVER DATABASE
ALTER SYSTEM ARCHIVE LOG CURRENT;
ALTER DATABASE OPEN ...;
--------------------------------------------------------------------------------
Caution:
If you do not open with the RESETLOGS option, then two copies of an archived redo log for a given log sequence number may exist--even though these two copies have completely different contents. For example, one log may have been created on the original host and the other on the new host. If you accidentally confuse the logs during a media recovery, then the database will be corrupted but Oracle and RMAN cannot detect the problem.
--------------------------------------------------------------------------------
Backup Fails Because of Control File Enqueue: Scenario
In this scenario, a backup job fails because RMAN cannot make a snapshot control file. The message stack is as follows:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup command at 08/30/2001 22:48:44
ORA-00230: operation disallowed: snapshot controlfile enqueue unavailable
Backup Fails Because of Control File Enqueue: Diagnosis
When RMAN needs to back up or resynchronize from the control file, it first creates a snapshot or consistent image of the control file. If one RMAN job is already backing up the control file while another needs to create a new snapshot control file, then you may see the following message:
waiting for snapshot controlfile enqueue
Under normal circumstances, a job that must wait for the control file enqueue waits for a brief interval and then successfully obtains the enqueue. RMAN makes up to five attempts to get the enqueue and then fails the job. The conflict is usually caused when two jobs are both backing up the control file, and the job that first starts backing up the control file waits for service from the media manager.
To determine which job is holding the conflicting enqueue:
After you see the first message stating "RMAN-08512: waiting for snapshot controlfile enqueue", start a new SQL*Plus session on the target database:
% sqlplus 'SYS/oracle@trgt AS SYSDBA'
Execute the following query to determine which job is causing the wait:
SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE,
ACTION, LOGON_TIME "Logon", l.*
FROM V$SESSION s, V$ENQUEUE_LOCK l
WHERE l.SID = s.SID
AND l.TYPE = 'CF'
AND l.ID1 = 0
AND l.ID2 = 2;
You should see output similar to the following (the output in this example has been truncated):
SID User Program Module Action Logon
--- ---- -------------------- ------------------------- ---------------- ---------
9 SYS rman@h13 (TNS V1-V3) backup full datafile: c1 0000210 STARTED 21-JUN-01
Backup Fails Because of Control File Enqueue: Solution
After you have determined which job is creating the enqueue, you can do one of the following:
Wait until the job creating the enqueue completes
Cancel the current job and restart it after the job creating the enqueue completes
Cancel the job creating the enqueue
Commonly, enqueue situations occur when a job is writing to a tape drive, but the tape drive is waiting for a new cassette to be inserted. If you start a new job in this situation, then you will probably receive the enqueue message because the first job cannot complete until the new tape is loaded.
RMAN Fails to Delete All Archived Logs: Scenario
In this scenario, the database archives automatically to two directories: ?/oradata/trgt/arch and ?/oradata/trgt/arch2. You tell RMAN to perform a backup and delete the input archived redo logs afterward in the following script:
BACKUP ARCHIVELOG ALL DELETE INPUT;
You then run a crosscheck to make sure the logs are gone and find the following:
CROSSCHECK ARCHIVELOG ALL;
validation succeeded for archived log
archivelog filename=/oracle/oradata/trgt/arch2/archive1_964.arc recid=19 stamp=368726072
RMAN deleted one set of logs but not the other.
RMAN Fails to Delete All Archived Logs: Diagnosis
This problem is not an error. When you specify DELETE INPUT without the ALL keyword, RMAN deletes only one copy of each input log. Even if you archive to five destinations, RMAN deletes logs from only one directory.
RMAN Fails to Delete All Archived Logs: Solution
To force RMAN to delete all existing archived redo logs, use the DELETE ALL INPUT clause of the BACKUP command. For example, enter:
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
Backup Fails Because RMAN Cannot Locate an Archived Log: Scenario
In this scenario, you schedule regular backups of the archived redo logs. The next time you make a backup, you receive this error:
RMAN-6089: archive log NAME not found or out of sync with catalog
Backup Fails Because RMAN Cannot Locate an Archived Log: Diagnosis
This problem occurs when the archived log that RMAN is looking for cannot be accessed by RMAN, or the recovery catalog needs to be resynchronized. Often, this error occurs when you delete archived logs with an operating system command, which means that RMAN is unaware of the deletion. The RMAN-6089 error occurs because RMAN attempts to back up a log that the repository indicates still exists.
Backup Fails Because RMAN Cannot Locate an Archived Log: Solution
Make sure that the archived logs exists in the specified directory and that the RMAN catalog is synchronized. Check the following:
Make sure the archived log file that is specified by the RMAN-6089 error exists in the correct directory.
Check that the operating system permissions are correct for the archived log (owner = oracle, group = DBA) to make sure that RMAN can access the file.
If the file appears to be correct, then try synchronizing the catalog by running the following command from the RMAN prompt:
RESYNC CATALOG;
If you know that the logs are unavailable because you deleted them by using an operating system utility, then run the following command at the RMAN prompt to update RMAN metadata:
CROSSCHECK ARCHIVELOG ALL;
It is always better to use RMAN to delete logs than to use an operating system utility. The easiest method to remove unwanted logs is to specify the DELETE INPUT option when backing up archived logs. For example, enter:
BACKUP DEVICE TYPE sbt
ARCHIVELOG ALL
DELETE ALL INPUT; |
|
免费注册
发表于 2003-02-12 10:00
