Change Flash Recovery Area Location

Due to insufficient space on some drives/mount point, you need to change the location of fast/flash recovery area.

Old Location: D:\flash_recovery_area

New Location: E:\flash_recovery_area

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='E:\flash_recovery_area' SCOPE=BOTH SID='*';

After change this parametr, all new archive log will create on the new location and then database going to remove old archive log files once aged out.

In the case that you need to your old files (archive log, backupset, datafile image copy) do the following:

for archivelog transmission:

RMAN> BACKUP AS COPY ARCHIVELOG ALL DELETE INPUT;

 for backupset transmission:

RMAN> BACKUP DEVICE TYPE DISK BACKUPSET ALL DELETE INPUT;

for datafile image copy transmission:

RMAN> BACKUP AS COPY DATAFILECOPY ALL DELETE INPUT;

Physical Standby vs Logical Standby

Physical Standby	Logical Standby
Complete (Block-based) copy of the primary database.	Can be a complete or partial copy of primary DB.
Use Redo Apply method to apply changes.	Redo data is first converted into SQL statements and then applied to the standby database.
Redo Apply uses Managed Recovery Process (MRP) in order to manage application of the change in information on redo.	The Logical Standby Process (LSP) process manages the application of changes to a logical standby database.
In 11g, a physical standby database can be accessible in read-only mode while Redo Apply is working (Active Data Guard).	This method makes it possible to access the standby database permanently and allows read/write while the replication of data is active.
Unable to change anything on DB structure.	Read-Write mode enables you to create as many object as you need.
Supports all the data types.	One discouraging aspect of the logical standby database is the unsupported data types, objects, and DDLs.
Active Data Guard comes with extra cost.	Free of cost
Easy to configure, manage and less or no performance issues.	More steps to configure, complex to manage and more performance issues.

OCR Backups Filling Up CRS_HOME Space

While checking my OCR backup I wondered why Oracle keep creating OCR backup without deleting the old ones. Should I delete them by my own?.. it sounds unkind!!.

I start searching on Google and metaling.. Guess what??? It’s a BUG.

That simply means, if you have dozens of OCR backups you may facing the same bug. Since the OCR backups should consist of 7 files as follow:

#ls -ltr u02/app/11.2.0/grid/cdata/feco-cluster/day* week* backup0*

-rw-------    1 root     system      7028736 May 22 2011  backup02.ocr

-rw-------    1 root     system      7028736 May 22 2011  backup01.ocr

-rw-------    1 root     system      7028736 May 22 2011  backup00.ocr

-rw-------    1 root     system      6979584 May 22 2011  week.ocr

-rw-------    1 root     system      7028736 May 22 2011  day_.ocr

-rw-------    1 root     system      7028736 May 22 2011  day.ocr

presenting the result of :

# ./ocrconfig -showbackup auto

feco04     2014/05/24 12:31:09     /u02/app/11.2.0/grid/cdata/feco-cluster/backup00.ocr

feco04     2014/05/24 08:31:07     /u02/app/11.2.0/grid/cdata/feco-cluster/backup01.ocr

feco04     2014/05/24 04:31:06     /u02/app/11.2.0/grid/cdata/feco-cluster/backup02.ocr

feco04     2014/05/23 04:31:00     /u02/app/11.2.0/grid/cdata/feco-cluster/day.ocr

feco04     2014/05/14 04:29:51     /u02/app/11.2.0/grid/cdata/feco-cluster/week.ocr

My current ocr backup look like:

-rw-------    1 root     system      7221248 Jun 24 2013  13458777.ocr

-rw-------    1 root     system      7221248 Jun 24 2013  14872007.ocr

-rw-------    1 root     system      7221248 Jun 24 2013  28713517.ocr

-rw-------    1 root     system      7221248 Jun 25 2013  39937824.ocr

-rw-------    1 root     system      7221248 Jun 25 2013  56169871.ocr

-rw-------    1 root     system      7221248 Jun 25 2013  58569011.ocr

:

:

-rw-------    1 root     system      7221248 Jun 27 2013  21069301.ocr

-rw-------    1 root     system      7221248 Jun 27 2013  11741111.ocr

-rw-------    1 root     system      7221248 Jun 27 2013  29616835.ocr

-rw-------    1 root     system      7221248 Jun 27 2013  19887106.ocr

-rw-------    1 root     system      7221248 Jun 28 2013  27246017.ocr

And crsd.log showing this error:

OCRSRV][9521]Failure in renaming file [/u02/app/11.2.0/grid/cdata/feco-cluster/25677603.ocr] to [/u02/app/11.2.0/grid/cdata/feco-cluster/backup00.ocr]

How to solve that???

According to (Doc ID 1191067.1) "change all 7 automatic backup files to be owned  by root:root with permission "-rw-------""

The current privilege of the 7 files are:

-rw-r--r--    1 grid     oinstall      7028736 May 22 2011  backup02.ocr

-rw-r--r--    1 grid     oinstall      7028736 May 22 2011  backup01.ocr

-rw-r--r--    1 grid     oinstall      7028736 May 22 2011  backup00.ocr

-rw-r--r--    1 grid     oinstall      6979584 May 22 2011  week.ocr

-rw-r--r--    1 grid     oinstall      7028736 May 22 2011  day_.ocr

-rw-r--r--    1 grid     oinstall      7028736 May 22 2011  day.ocr 

Just change them to:

chown root:system week*

chown root:system day*

chown root:system backup0*

chmod 600 week*

chmod 600 day*

chmod 600 backup0*

:-)

Note:

My database version is : 11.2.0.2.0

Reference:

Automatic OCR Backup Filling Up <CRS_HOME>/cdata/<clustername> Directory (Doc ID 1191067.1)