26. How to check RMAN Configuration ?
RMAN>Show all;
27. How to Reset to default
Configuration ?
To reset the default configuration setting
use
SQL> connect <sys/passwd as
sysdba>@target_database;
SQL> execute
dbms_backup_restore.resetConfig;
28. What is Catalog database and How to
Configure it ?
This is a separate database which contains
catalog schema. You can use the same target database as the catalog database
but its not at all recommended.
29. How Many catalog database I can
have ?
You can have multiple catalog database for
the same target database . But at a time you can connect to only 1 catalog
database via RMAN. Its not recommended to have multiple catalog database.
30. Is this mandatory to use catalog
database ?
No ! its a optional one.
31. What is the advantage of catalog database ?
Catalog database is a secondary storage of
backup metadata. Its very useful in case you lost the current controlfile, as
all the backup information are there in the catalog schema. Secondly from
contolfile the older backup information are aged out depending upon the
control_file_record_keep_time. RMAN catalog database mainten the history of
data.
32. What is the difference between
catalog database & catalog schema ?
Catalog database is like any other
database which contains the RMAN catalog user's schema.
33. What happen if catalog database
lost ?
Since catalog database is a option one
there is no direct effect of loss of catalog database. Create a new catalog
database and register the target database with the newly created catalog one.
All the backup information from the target database current controlfile will be
updated to the catalog schema. If any backup information which is aged out from
the target database then you need to manually catalog those backup pieces.
34. What are the database file's that
RMAN can backup ?
RMAN can backup Controlfile ,Datafiles ,
Archive logs , standby database controfile, Spfile
35. What are the database file's that
RMAN can not backup ?
RMAN can not take backup of the pfile, Redo
logs , network configuration files, password files, external tables and the
contents of the Oracle home files
36. Can I have archivelogs and datafile
backup in a single backupset ?
No .we can not put datafiles and archive
logs in the same backupset.
37. Can I have datafiles and contolfile
backup in a single backup set ?
Yes .
If the controlfile autobackup is not ON then RMAN takes backup of controlfile
along with the datafile 1,whenever you take backup of the database or
System tablespace.
38. Can I regulate the size of backup
piece and backupset ?
Yes ! You can set max size of the
backupset as well as the backup piece. By default one RMAN channel creates a
single backupset with one backup piece in it. You can use the MAXPIECESIZE
channel parameter to set limits on the size of backup pieces. You can also use
the MAXSETSIZE parameter on the BACKUP and CONFIGURE commands to set a limit
for the size of backup sets.
39. What is the difference between
backup set backup and Image copy backup ?
A backup set is an RMAN-specific
proprietary format, whereas an image copy is a bit-for-bit copy of a file. Bydefault,RMAN creates backup sets
40. What is RMAN consistent backup and
inconsistent backup ?
A consistent backup occurs when the
database is in a consistent state. That means backup of the database taken after
a shutdown immediate , shutdown normal or shutdown transactional. If the
database is shutdown with abort option then its not a consistent backup.
A backup when the database is Up and
running is called an inconsistent backup. When a database is restored from an
inconsistent backup, Oracle must perform media recovery before the database can
be opened, applying any pending changes from the redo logs. You can not take
inconsistent backup when the database is in NoArchivelog mode
41. Can I take RMAN backup when the database is Down ?
No ! You can take RMAN backup only when
the target database is Open or in Mount stage. Its because RMAN keep the backup
metadata in controfile . Only in open or mount mode controlfile is accessible.
42. Do I need to place the database in
begin backup mode while taking RMAN inconsistent backup?
RMAN does not require extra logging or
backup mode because it knows the format of data blocks. RMAN is guaranteed not
to back up fractured blocks.No extra redo is generated during RMAN backup.
43. Can I compress RMAN backups ?
RMAN supports binary compression of backup
sets. The supported algorithms are BZIP2
(default) and ZLIB. Its not recommend to compress the RMAN backup using any
other OS or third party utility.
Note : RMAN compressed backup with BZIP2
provides great compression but is CPU intensive. Using ZLIB compression requires
the Oracle Database 11g Advanced Compression Option and is only supported with
an 11g database. The feature is not backward compatible with 10g databases.
45. Can I encrypt RMAN backup ?
RMAN supports backup encryption for backup
sets. You can use wallet-based transparent encryption, password based encryption,
or both. You can use the CONFIGURE ENCRYPTION command to configure persistent
transparent encryption. Use the SET ENCRYPTION, command at the RMAN session
level to specify password-based encryption.
46. Can RMAN take backup to Tape ?
Yes !you can use RMAN for the tape backup.
But RMAN can not able to write directly
to tape. You need to have thirdparty Media Management Software installed.
Oracle has published an API specification which Media ManagementVendor's who
are members of Oracle's Backup Solutions Partner program have access to. Media
Management Vendors(MMVs) then write an interface library which the Oracle
server uses to write and read toand from tape.
47.How RMAN Interact with Media manager
?
Before performing backup or restore to a
media manager, you must allocate one or more channels or configure default
channels for use with the media manager to handle the communication with the
media manager. RMAN does not issue specific commands to load, label, or unload
tapes. When backing up, RMAN gives the media manager a stream of bytes and associates
a unique name with this stream. When RMAN needs to restore the backup, it asks
the media manager to retrieve the byte stream. All details of how and where
that stream is stored are handled entirely by the media manager.
48. What is Proxy copy backup to tape ?
Proxy copy is functionality, supported by
few media manager in which they handle the entire data movement between
datafiles and the backup devices. Such products may use technologies such as
high-speed connections between storage and media subsystems to reduce load on
the primary database server. RMAN provides a list of files requiringbackup or
restore to the media manager, which in turn makes all decisions regarding how
and when to move the data.
49. What is Oracle Secure backup ?
Oracle Secure Backup is a media manager
provided by oracle that provides reliable and secure data protection through
file system backup to tape. All major tape drives and tape libraries in SAN,
Gigabit Ethernet, and SCSI environments are supported.
50.Can I restore or duplicate my
previous version database using a later version of Oracle?
RMAN can restore a backup taken on an
older database release into a newer release. The older backups must be taken on
9.2 or later release.
This method can be used as part of an
out-of-place database upgrade, in which the older backups are restored to the
newer release database and then the upgrade scripts are run as normal. Since
the older database can remain online during the upgrade, this may be preferable
to an in-place upgrade, where the database must remain offline.
For example, I want to upgrade a 10.2
database to 11.2, using backups taken on the 10.2 database. The 11.2 database
will reside on a new host.
The steps are:
1. Install 11.2 binaries and latest patch
sets on new host and prepare the 11.2 Oracle home per this doc.
2. Allow disk and/or tape backups to be
accessible from the new host.
3. Restore backups to the 11.2 database
and recover the database to a consistent point-in-time per this doc. Do not
open the database at this time.
4. Manually upgrade the 10.2 database to
11.2 per the instructions in this doc, starting from the point immediately
after the 11.2software has been installed.
Note: the above procedure is for restoring
a 10.2 database that had never been upgraded to 11.2. If the database has
already been upgraded, and you need to restore a backup that was created while
the database was running as 10.2, you just need to restore and recover it, and
media recovery will replay everything done by the upgrade.
RMAN "duplicate" is not
supported as it will fail attempting to automatically open the database after
recovery (step #3).
51. Can I restore or duplicate between
two different patchset levels?
As you can restore between different
Oracle version, you can also do so between two different patchset levels. Note,
you must follow the instructions in the appropriate readme file. If resetlogs
is required, you can execute:
SQL>
alter database open resetlogs upgrade;
OR
SQL>
alter database open resetlogs downgrade;
As needed before executing the required
scripts to either upgrade or downgrade to a patch level.
Because RMAN "duplicate"
attempts to automatically open the database you may not use RMAN duplicate for
this case, only RMAN restore.
52. Can I restore or duplicate between two
different versions of the same operating system?
For example, can I restore my 9.2.0.1.0 RMAN backup
taken against a host running Solaris 9 to a different machine where 9.2.0.1.0
is installed but where that host is running Solaris 10?
If the same Oracle Server installation CDs (media
pack) can be used to install 9.2.0.1.0 on Solaris 9 and Solaris 10, this type
of restore is supportable.
53. Is it possible to restore or duplicate when the
bit level (32 bit or 64 bit) of Oracle does not match?
OR
is it possible to restore or duplicate my 9.2. 64-bit
database to a 9.2.32-bit installation?
It is preferable to keep the same bit version when
performing a restore/recovery. However, excluding the use of duplicate command,
the use of the same operating system platform should allow for a
restore/recovery between bit levels (32 bit or 64bit) of Oracle. Note, this may
be specific to the particular operating system and any problems with this
should be reported to Oracle Support.
If you will be running the 64-bit database against the
32-bit binary files or vice versa, after the recovery has ended the database bit
version must be converted using utlirp.sql.
54. Is it possible to restore a later version backup
to an earlier version of Oracle?
Say for example you are preparing to upgrade to 11.2
from 10.2. After a successful upgrade and running on 11.2 for a few days you
take a new backup of the 11.2 database. You want to know if run into a problem
with 11.2 if you could restore the 11.2backup to 10.2 on another host (or
reinstall 10.2 on the same host then restore the 11.2 backup).
Such a restore is possible if the COMPATIBLE parameter had
never been increased after the upgrade. In this example, if the 11.2database
had always been run with COMPATIBLE=10.2 then it is possible to restore a
backup of the 11.2 database into a 10.2instance, then perform the downgrade
procedures.
If the 11.2 database has ever been opened with
COMPATIBLE = 11.2, then this is not possible. Another good way for maintaining HA
and the old version database (if you need to fall back) is to use the Data
Guard rolling upgrade method which involves a transient logical standby
database (a primary that temporarily becomes a logical standby just during the
upgrade period). After upgrading the standby to new version (and primary still
running on old version), you can switchover and verify that upgraded database
is working well. If it is not, you can switchback to primary old version.
55. Benefits and Usage of RMAN with
Standby Databases
Standby backups of datafiles and archived
redo logs are fully interchangeable with primary database backups. In other
words, you can run the RESTORE command to restore a backup of a standby
datafile to the primary database, and you can restore a backup of a primary datafile
to the standby database. The standby control file and primary control
file, however, are not interchangeable.
56.Can I restore or duplicate my RMAN backup between
two different platforms such as Solaris to Linux?
In general, you
cannot restore or duplicate between two different platforms. In versions
previous to 10g the only option to migrate from one platform to another was
using export / import. With 10g, using the RMAN convert commands, you can cross
between platforms using the 10g Cross-Platform Transportable Tablespaces
option.In version 10.2 and later if the source and target OS are the same
endian you may issue a "CONVERT DATABASE" so that datafiles are
converted and ready for transport to the destination machine.
57. What are the
symtoms of a physical corruption?
Most of the physical corruption issues can
be observed by corrupt messages in alert.log (or) by ORA-01578 errors.
58.What are the common corruption
errors?
(a) ORA-01578 - This error explains
physical structural damage with a particular block.
(b) ORA-08103 - This error is a logical
corruption error for a particular data block.
(c) ORA-00600 [2662] - This error is
related to block corruption , and occurs due to a higher SCN than of database SCN.
59. How
to check a physical corruption?
There are various methods to check /
understand the physical corruption:
(a) To check the corruption we shall run DBV on
the datafiles, which will explain the corruption.
DBV utility will scan through the files at
OS level. While reading the blocks it checks for any fractured blocks ,
checksum failure & other checking failures. It will report corrupted blocks
and also classifies them in what type of object were they (table/index/etc).
The following script shall be used to run
DBV on all datafiles in UNIX platforms.
Note:352907.1 Script to Run DBV on all
Datafiles on Unix Platforms
NOTE:35512.1 DBVERIFY - Database file
Verification Utility (7.3.2 - 8.1)
LIMITATIONS
WITH DBV:
o DBV cannot understand any table / index
row count mismatch.
o DBV cannot understand any complex
corruptions, especially corruptions below cache layer of a datablock.
o Some blocks that may not be part of
Oracle, they would have been dropped. But DBV will still report that block as corrupted.
When you check with the query against dba_extents (given below) there wont be
any rows returned. And this corrupt block will not affect normal database
operations as Oracle is not going to read this block. But while performing RMAN
backups we still report this block as corrupted.
o Logical corruptions with undo / redo
records cannot be identified.
o Some types of corruptions that cannot be
explored while we do an OS level read.
(b) We shall also use RMAN to validate the
database files.
The following command will validate all
the datafiles in the database.
RMAN>
BACKUP VALIDATE DATABASE;
- If you want to validate a particular
datafile you shall use the following command, this will vaildate the file# 1
RMAN>
BACKUP VALIDATE DATAFILE 1;
Refer to following metalink article to
understand the above usage of RMAN.
Note:472231.1 How to identify all the
Corrupted Objects in the Database reported by RMAN
LIMITATIONS WITH RMAN:
o All the limitations that apply to DBV
are applicable to RMAN VALIDATE also.
(c) Export Utility / SELECT:
To check the corruption, we shall export
the affected segment / schema / tablespace / full.
If we doubt a particular table, we shall
either perform a full table scan (or) CTAS.
If there is any corruptions with the
exporting object, export will fail with corruption error.
In case there no space in filesystem to
perform an export, we shall do it to /dev/null.
LIMITATIONS
WITH EXPORT:
o It fails immediately after encountering
the first corruption., so complete picture will be missed-out.
o export performs full table scan, so we
will not be checking the indexes. Any corruption in index (or) table/index rowcount/rowid
mismatch will not be checked by export.
o A full database export reads data
dictionary, but it doesn't mean that there is no corruption with data
dictionary when this export completes successfully.
(d) ANALYZE command:
ANALYZE has been referred as the best
utility that performs maximum checks.
This is the easy utility to check the
corruptions associated with index on any means.
To check the corruption with a table do
the following:
ANALYZE
TABLE <OWNER.TABLE_NAME> VALIDATE STRUCTURE;
To check the corruption with an index do
the following:
ANALYZE
INDEX <OWNER.INDEX_NAME> VALIDATE STRUCTURE;
To check the corruption with the table and
its index(s) to perform the cross reference checkings do the following:
ANALYZE
TABLE <OWNER.TABLE_NAME> VALIDATE STRUCTURE CASCADE;
For partition tables, we need to use
ANALYZE command with INTO INVALID_ROWS option, similar to the following:
ANALYZE
TABLE <OWNER.TABLE_NAME> VALIDATE STRUCTURE CASCADE INTO INVALID_ROWS;
Refer to following metalink article for
more information.
NOTE:111990.1 ORA-14508: ANALYZE PARTITON
TABLE VALIDATE STRUCTURE CASCADE
LIMITATIONS WITH ANALYZE:
o It is not a limitation, rather the
common problem. It would be difficult to perform an analyze with huge segments
as it needs to scan all the blocks with that segment. We shall use ONLINE
option there. But still the performance problem may not be acceptable for busy
segments.
o Again this fails when it encounters the
first corruption, it will not proceed after that.
60. How
to identify the segment for the given corrupt block?
Normally with the corrupt block messages will give the
relative file number. (rfile#).
Relative file
number is unique to a particular tablespace, not to the database.
To find the segment associated with this corrupt block
we need to pass the absolute file number (file#).
And the absolute
file number will be unique for the given database.
SELECT NAME,
FILE#, TS# FROM V$DATAFILE WHERE RFILE#=&FILE_ID;
- If the above query returns only a single row, then
there is no need to do any further verification.
- If we get multiple rows returned then, check the
list of datafiles with DBV. This would help to identify the name of corrupted
datafile.
- We need to associate the file# with the given other
data, like ts#, name. etc.
In the following query pass the absolute file number
and block_id to get the details of the object.
SELECT TABLESPACE_NAME,
SEGMENT_NAME, PARTITION_NAME, SEGMENT_TYPE
FROM
DBA_EXTENTS WHERE FILE_ID=&FILE_ID
AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
Incase if we use bigfiles, there will be only one
bigfile for the given tablespace.
We shall check the file# for the given ts#. by
querying v$tablespace / v$datafile.
61. How to understand if this is an Oracle problem?
There were few issues with Oracle; with a constant
corruption pattern and we shall narrow down to an Oracle bug;
If database version is less than 9204, it is possible
to get a false corruption messages due to Oracle bug 2870048
Note:250968.1 Block Corruption Error Messages in Alert
Log File
Any adhoc corruptions where we don’t see any patterns
would normally be an OS issue (or) hardware issue. To understand if the cause
of a physical corruption is an Oracle issue, we shall do a restore and recover
that particular datafile. If a restore (from a good backup) introduces a
corruption on recovery then it could be an Oracle issue.
We need to understand the redos that introduces the
corruption.
Better enable the parameters that were suggested below
before you perform the recovery.
Please note,
corruption introduced on a NOLOGGING segment on recovery, is an expected
behavior.
Refer to following note for more information on this.
Note:28814.1 Handling Oracle Block Corruptions in
Oracle7/8/8i/9i/10g
62. How restore / recover is going explain the cause?
Oracle uses a physiological logging method, by which
we ensure that we perform the same activites that we do in normal operation
time.
In the redo, we maintain the physical image of the
modified block as well the logical changes (opcodes), hence while performing
the recovery we do the same actions that happens in the realtime.
If this corruption is due to some OS/Hardware problem,
the restore / recover will not introduce the corruption.Rather if this
corruption is due to Oracle issue, then we will see the same corruption pattern
upon recovery.
63. What to do if restore/recover introduces the
corruption?
We basically need the redo dumps for analysis.
We normally require change vectors for the problem
block for the past 3(or) 4 changes.
It would be better if we can get the problem datafile
(without corruption) and the archivelogs that introduces the corruption. We can
reproduce the problem in house and engage the development team to analyze the
cause.
Note:232963.1 How to Build a Testcase for Oracle Data
Server Support to Reproduce ORA-600 and ORA-7445 Errors
64. What to do if the restore/recover does not
introduce the corruption?
It is unlikely to be an Oracle problem if the restore
and recover does not introduce the physical corruption.Ask system administrator
to check the OS logs, Hardware logs for any failures / errors around the time
of corruption. If no errors, then engage the hardware vendor to run diagnostics
on the hardware (memory, storage and controllers.etc)
65. What all the parameters that we shall enable to
have checkings in oracle side?
We have few parameters that will help to perform
additional checkings on oracle blocks.
(a)
DB_BLOCK_CHECKING=TRUE
DB_BLOCK_CHECKING controls whether Oracle performs
block checking for data blocks. When this parameter is set to true, Oracle
performs block checking for all data blocks. When it is set to false, Oracle
does not perform block checking for blocks in the user tablespaces. However,
block checking for the SYSTEM tablespace is always turned on.
Oracle checks a block by going through the data on the
block, making sure it is self-consistent. Block checking can often prevent
memory and data corruption. Block checking typically causes 1% to 10% overhead,
depending on workload.
The more updates or inserts in a workload, the more
expensive it is to turn on block checking. You should set DB_BLOCK_CHECKING to
true if the performance overhead is acceptable.
Note:68483.1 Init.ora Parameter
"DB_BLOCK_CHECKING" Reference Note
(b)
DB_BLOCK_CHECKSUM=TRUE
DB_BLOCK_CHECKSUM determines whether DBWn and the
direct loader will calculate a checksum (a number calculated from all the bytes
stored in the block) and store it in the cache header of every data block when
writing it to disk. Checksums are verified when a block is read only if this
parameter is true and the last write of the block stored a checksum. In
addition, Oracle gives every log block a checksum before writing it to the
current log.
If this parameter is set to false, DBWn calculates
checksums only for the SYSTEM tablespace, but not for user tablespaces. Checksums
allow Oracle to detect corruption caused by underlying disks, storage systems,
or I/O systems. Turning on this feature typically causes only an additional 1%
to 2% overhead. Therefore, Oracle Corporation recommends that you set DB_BLOCK_CHECKSUM to true.
Note:30706.1 Init.ora Parameter
"DB_BLOCK_CHECKSUM" Reference Note
( c)
_DB_BLOCK_CACHE_PROTECT=TRUE
This parameter is not available in all platforms /
versions. In those platforms setting it to TRUE may not do anything.
No comments:
Post a Comment