Showing posts with label Archival. Show all posts
Showing posts with label Archival. Show all posts

Sunday, January 24, 2010

LOG_ARCHIVE_FORMAT in Oracle

If you have enabled archive log mode in your database then LOG_ARCHIVE_FORMAT parameter will come into role. If your database is in archivelog mode then redo log files will be archived and the parameter LOG_ARCHIVE_FORMAT determines the name of the archived log files.

LOG_ARCHIVE_FORMAT uses a text string and variables to specify the format of the archived files.

The following variables can be used with the LOG_ARCHIVE_FORMAT

1) %s : log sequence number

2) %S : log sequence number, zero filled

3) %t : thread number

4) %T : thread number, zero filled

5) %a : activation ID

6) %d : database ID

7) %r : resetlogs ID that ensures unique names are constructed for the archived log files across multiple incarnations of the database

Using uppercase letters for the variables (for example, %S) causes the value to be fixed length and padded to the left with zeros.

Following is an example of how we can set LOG_ARCHIVE_FORMAT in a database.

SQL> ALTER SYSTEM SET log_archive_format='VSPRODP_%s_%t_%r.arch' SCOPE=spfile;

System altered.

Note that, neither LOG_ARCHIVE_DEST nor LOG_ARCHIVE_FORMAT have to be complete file or directory specifiers themselves; they only need to form a valid file path after the variables are substituted into LOG_ARCHIVE_FORMAT and the two parameters are concatenated together.

For example, we are setting the following values to log_archive_dest and log_archive_format parameters.
SQL> alter system set log_archive_dest='E:\oracle';

System altered.

SQL> alter system set log_archive_format='arju_%s_%t_%r.arch' scope=spfile;

System altered.

SQL> col name for a30
SQL> col value for a30
SQL> select name, value from v$spparameter where name in ('log_archive_dest','log_archive_format');


NAME VALUE
------------------------------ ------------------------------
log_archive_dest E:\oracle
log_archive_format arju_%s_%t_%r.arch
If we do above settings all our archive log files will go into directory E:\oracle and format will be arju_%s_%t_%r.arch.

Note that, in the LOG_ARCHIVE_FORMAT %s, %t and %r are mandatory variables. If we dont specify anyone of them it while starting up oracle it will throw error http://arjudba.blogspot.com/2008/04/ora-32004-obsolete-andor-deprecated.html.
Related Documents
http://arjudba.blogspot.com/2010/01/ora-16014-ora-00312-ora-16038-ora-19809.html
http://arjudba.blogspot.com/2009/12/enable-archive-log-mode-for-rac.html
http://arjudba.blogspot.com/2009/12/database-archival-exercises.html
http://arjudba.blogspot.com/2008/07/archiving-not-possible-no-primary.html
http://arjudba.blogspot.com/2008/05/recovering-database-in-noarchivelog.html
http://arjudba.blogspot.com/2008/05/user-managed-consistent-backup-in.html
http://arjudba.blogspot.com/2008/05/user-managed-hot-backup-of-oracle.html
http://arjudba.blogspot.com/2008/05/what-will-be-archived-redo-log.html
http://arjudba.blogspot.com/2008/04/ora-16018-and-ora-16019-logarchivedest.html
http://arjudba.blogspot.com/2008/04/ora-00257-archiver-error-connect.html

Saturday, January 16, 2010

ORA-16014 ORA-00312 ORA-16038 ORA-19809: limit exceeded for recovery files

Problem Description:
From alert log, we find the following errors
Sat Jan 16 03:08:36 2010
ARCH: Archival stopped, error occurred. Will continue retrying
Sat Jan 16 03:08:36 2010
ORACLE Instance OMSRPS - Archival Error
Sat Jan 16 03:08:36 2010
ORA-16014: log 6 sequence# 11181 not archived, no available destinations
ORA-00312: online log 6 thread 1: '/SIDS1/oradata/OMSRPS/stdby_redo02.log'
ORA-00312: online log 6 thread 1: '/SIDS2/oradata/OMSRPS/stdby_redo02.log'
Sat Jan 16 03:08:36 2010
Errors in file /SIDS/app/oracle/admin/OMSRPS/bdump/omsrps_arc4_9885.trc:
ORA-16014: log 6 sequence# 11181 not archived, no available destinations
ORA-00312: online log 6 thread 1: '/SIDS1/oradata/OMSRPS/stdby_redo02.log'
ORA-00312: online log 6 thread 1: '/SIDS2/oradata/OMSRPS/stdby_redo02.log'
If we check the content of trace file /SIDS/app/oracle/admin/OMSRPS/bdump/omsrps_arc4_9885.trc we see,
ORA-19815: WARNING: db_recovery_file_dest_size of 99857989632 bytes is 70.10% used, and has 29852624896 remaining bytes available.
*** 2010-01-16 03:23:54.463
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
*** 2010-01-16 03:23:54.464 62692 kcrr.c
ARC4: Error 19809 Creating archive log file to '/backup/flash_recovery_area/OMSRPS/archivelog/2010_01_16/o1_mf_1_11181_%u_.arc'
*** 2010-01-16 03:23:54.464 60970 kcrr.c
kcrrfail: dest:1 err:19809 force:0 blast:1
ARCH: Connecting to console port...
ARCH: Connecting to console port...
*** 2010-01-16 03:23:54.513 21373 kcrr.c
ORA-16038: log 6 sequence# 11181 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 6 thread 1: '/SIDS1/oradata/OMSRPS/stdby_redo02.log'
ORA-00312: online log 6 thread 1: '/SIDS2/oradata/OMSRPS/stdby_redo02.log'
Cause of the Problem
Flash recovery area is used for archival destination. ORA-16014 ORA-00312 ORA-16038 ORA-19809: limit exceeded for recovery files will be raised because there is no space to create additional archive log in the flash recovery area. Note that the error inside trace file "ORA-19815: WARNING: db_recovery_file_dest_size of 99857989632 bytes is 70.10% used, and has 29852624896 remaining bytes available." can be misleading. Though it says 70.10% used but actually it is 100% used. Ensure by issuing following query in the database,
SQL> set lines 120
SQL> col name format a50
SQL> select name
,floor(space_limit / 1024 / 1024) "Size MB"
,ceil(space_used / 1024 / 1024) "Used MB"
from v$recovery_file_dest
order by name
/

NAME Size MB Used MB
------------------------------------------- --------- ------------
/backup/flash_recovery_area 95232 95152
We see in the flash recovery area space limit and space used are almost same and no more space for archival. Hence we get error.

Consequences of the Error
Due to ORA-16014, ORA-00312, ORA-16038 and ORA-19809 there might have following effects to database.
1) Database archive process stops and database hangs.
2) Users are not able to connect to database.
3) If you try to open database you are not able to open database bypass these errors.
4) In the Alert log/Trace file Flash Recovery Area reports ORA-19809: limit exceeded for recovery files.

Solution of the Problem
There may have several solutions to solve above problems.
Solution 00: Ensure that you have enough space in the underlying directory
This step is common and application for all solution methods.
In the underlying mount point of your archival destination ensure that you have enough space. That is ensure that your hard disk is not full. If you don't have sufficient space in your disk space free up the space by deleting unnecessary files.

On Linux/Solaris you can check disk space of all mount points by $df -h
On HP-UX issue $df -k

Solution 01: Increase the size of Flash recovery area
The size of flash recovery area is determine by the parameter db_recovery_file_dest_size. You can check the current size of flash recovery area in Sql*plus by issuing,
SYS@OMSRPS> show parameter db_recovery_file

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /backup/flash_recovery_area
db_recovery_file_dest_size big integer 93G
or by issuing query,
SQL> select value from v$parameter where name='db_recovery_file_dest_size';

VALUE
-----------------------------------------------------------------------------
99857989632

In order to increase the size of the parameter issue following query.
SYS@OMSRPS> alter system set db_recovery_file_dest_size = 95G scope=both;

System altered.
Here, I have increased to 95G. Ensure by issuing,
SYS@OMSRPS> show parameter db_recovery_file

NAME TYPE VALUE
------------------------------------ ----------- --------------------------
db_recovery_file_dest string /backup/flash_recovery_area
db_recovery_file_dest_size big integer 95G
Now check your alert log file and you see Archiver process freed from errors.
Sat Jan 16 03:37:31 2010
ALTER SYSTEM SET db_recovery_file_dest_size='95G' SCOPE=BOTH;
Sat Jan 16 03:38:25 2010
Archiver process freed from errors. No longer stopped
Sat Jan 16 03:38:25 2010
Primary database is in MAXIMUM PERFORMANCE mode
RFS[9]: No standby redo logfiles of size 512000 blocks available
Sat Jan 16 03:38:27 2010
Media Recovery Waiting for thread 1 sequence 11186 (in transit)

Solution 02: Change the database archival location outside FRA
You can solve the problem if you stop using flash recovery area for your archival destination. You can disable using flash recovery area by issuing following query,

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='' SCOPE=BOTH SID='*';

System altered.
After disabling flash recovery area you will see your archival location is changed to database default archival location. If you have enough space in your default archive location (you can check it by issuing "archive log list" after connecting as sysdba) you should no longer get above errors.

Solution 03: Free up space in FRA
If you use RMAN to database backup and store backups to FRA then check space distribution in the FRA by following query,
SQL>select file_type, percent_space_used as used,percent_space_reclaimable as reclaimable,
number_of_files as "number" from v$flash_recovery_area_usage;

After issuing query if you see almost all the space are used by Archivelogs and backup pieces then there is no space to reclaim. So you need to free up some spaces with by of the following methods.

a) Take backup of archivelogs to some other locations and delete the archivelogs from flash recovery area.
You can delete older archivelogs say before 7 days ago by following RMAN command.
RMAN>Delete archivelog all completed before 'SYSDATE-7';

b) If flashback logs are enable then make sure you have enough space for all the flashback logs. If you don't need flashback logs you can disable it by command in mount stage.
SQL>Alter database FLASHBACK OFF;

c) Note that if you have guaranteed restore point then flashback logs will not be reclaimed by flash recovery area. Even due to some bugs Flashback logs are not reclaimed by flash recovery area when using guaranteed restore point (after dropping guaranteed restore point) or when changing db_flashback_retention_target to a lower value. If there is such guaranteed restore point and it is no longer needed you can delete by,

SQL> Drop restore point restore_point_name;

d) From your archival location using any operating system utility like rm or del or delete you can remove the backups/archive log files. After you remove the files the OS knows that you have deleted files but still you need to inform the database to be aware of the resulting free space.

To inform database about free space connect as RMAN and then issue following commands.
RMAN>CROSSCHECK BACKUP;
RMAN>CROSSCHECK ARCHIVELOG ALL;

RMAN>Delete expired backup;
RMAN>Delete expired archivelog all;
RMAN>Delete force obsolete;

Solution 4: Scenarios based on Database Backup Strategy
Follow the scenarios as demonstrated in topic Database Startup fails with error ORA-16038,ORA-19809, ORA-00312. In the post it is demonstrated what we will do if we don't (in Solution C:) have any backup and also the secnarios if we (Solution D:) have recent backup and only need archivelogs.

Related Documents
Set up Flash Recovery Area for RMAN
Database Startup fails with error ORA-16038,ORA-19809, ORA-00312

Interact with RMAN Client.

Thursday, December 17, 2009

Enable Archive log Mode for RAC database

Whether it is single instance database or multiple instance database, all changes made to the database are written into online redo log files. In an Oracle RAC environment, each instance have its own set of online redolog files that is known as thread. Each Oracle instance will use its set of online redologs in a circular fashion. If there is log switch occur then it will write to next online redo log file. If the database is in "Archive Log Mode", Oracle will make a copy of the online redo log before it gets reused. A thread must contain at least two online redologs so that it can archive it properly before it is used.

In a RAC environment each instance have exclusive right access to its own set of redo log files. That means suppose I have a database named arju and arju database has two nodes, arju1 instance and arju2 instance. arju1 instance can't write to online redo log files of arju2 instance. However each instance can read another instance's current online redolog file to perform instance recovery if that instance was terminated abnormally. So one instance must have read access of another online redo log files. It is therefore a requirement that online redo log files to be located on a shared storage device.

Whenever you create your database manually then by default database is in noarchive log mode. If you create your database with database configuration assistant (dbca) then there is a checkbox and check the box will enable your database archival mode. But if your database is in noarchivelog mode and you want to enable the archivelog mode then you must shutdown the database. So while enabling archivelog mode in RAC database you must shutdown your all instances. The following is the procedure to enable a database from noarchivelog mode to archivelog mode in RAC environment.

Step 01: Login to any instance and check the archival settings and location.
SQL> conn / as sysdba
SQL> archive log list

Step 02: If you need to change archival location then you can change it by
ALTER SYSTEM SET archival_parameter=new_value scope=both;

Step 03: Shutdown all RAC instances. The following command will shutdown all instances of orcl cluster database.
$ srvctl stop database -d orcl

Step 04: Connect to any of the local instance and MOUNT the database:

$ sqlplus "/ as sysdba"
SQL> startup mount

Step 05: Enable archive log mode.

SQL> alter database archivelog;

Step 06: Shutdown the local instance:
SQL> shutdown immediate

Step 07: Startup all the instances using srvctl.

$ srvctl start database -d orcl

Optionally, bring any services (i.e. TAF) back up using srvctl:

$ srvctl start service -d orcl

Step 08: Login to the local instance and verify Archive Log Mode is enabled:

$ sqlplus "/ as sysdba"
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 81
Next log sequence to archive 82
Current log sequence 82
After enabling Archive Log Mode, each instance in the RAC configuration can automatically archive redologs.

Related Documents

Saturday, December 5, 2009

Database Archival Exercises


Successful database recovery relies on the database being in ARCHIVELOG mode. This is what enables the database to recover data that was lost due to a media failure, loss of power or any other type of disaster. Each time the online line redo logs fill up in a log group the DBMS issues a log switch that will move the log writer process from the current redo log group to the next one in line. If the database is in ARCHIVELOG mode then the archive background process then begins archiving the data in the full online log group files to the archive log files. This is done simultaneously for each log file in the group. If media recovery is needed at the time that the database needs recovery then the DBMS will search through the archived log files to find the ones that need to be used.
In this exercise you will go through the process of putting your database instance in ARCHIVELOG mode. The destination for the archived log files has already been determined; you simply need to enable the process to begin.
IMPORTANT: Be sure that you complete this exercise BEFORE doing the lab for this week.
Now let's get started.
I N D I V I D U A L     E X E R C I S E S
HANDS-ON #1: Putting the database in ARCHIVELOG mode

The first thing that must be done before dong any type of database backup is to ensure that the database is in Archive Log mode. To do this you will need to make some changes the init.ora file for you database instance as well as issue some commands with the database in mount mode put archiving in motion. Your OFA structure already has a folder named backup in it and this will be the destination for all of your backup files. Go through the following steps to set up archiving.
a. You must first shutdown the database by issuing a SHUTDOWN IMMEDIATE command.
b. Now go into Windows Explorer and open up your initdb###.ora file in the pfile directory of your OFA structure. You need to uncomment each of the five lines found in the section of the parameter listing titled Redo Log and Recovery. When finished then save the changes you have made.
c. Next start up your database in MOUNT mode using your initDB###.ora file. Once the database is opened in MOUNT mode then issue the following command:
ALTER DATABASE ARCHIVELOG;
d. Now issue and ALTER statement to open the database. Once the database is open then issue an ARCHIVE LOG LIST command to see the parameter settings that are associated with the Archive process. You output should look similar to the following:
Database log mode Archive Mode
Automatic archival Enabled
Archive destination F:\DBM\SPRINGB\DB1000\oracle\
admin\backup
Oldest online log sequence 1252
Next log sequence to archive 1253
Current log sequence 1253

Monday, July 21, 2008

Archiving not possible: No primary destinations

Error Description:
Today I got a very interesting problem. The developer told me that they can't connect to database. It says ORA-00257: archiver error. Then I log on to the database and it was ok. I asked developer it is fine. After some time developers again asked me they are having the same problem. I then look for alert log and saw the following stack of message.

ARC0: Failed to archive thread 1 sequence 1192 (4)
Mon Jul 21 05:51:08 2008
ARC1: Archiving not possible: No primary destinations
ARC1: Failed to archive thread 1 sequence 1192 (4)
Mon Jul 21 05:51:08 2008
ARC0: Archiving not possible: No primary destinations
ARC0: Failed to archive thread 1 sequence 1192 (4)
Mon Jul 21 05:51:08 2008
ARC1: Archiving not possible: No primary destinations
ARC1: Failed to archive thread 1 sequence 1192 (4)

Cause of The Problem:

Unknown yet. Possibly hit oracle bug.

Solution of The Problem:

At first seems I guessed there is space issue and look for following thing as in described,
ORA-00257: archiver error. Connect internal only, until freed.

Step1: Look for archival destination.
SQL> archive log list

Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1203
Next log sequence to archive 1205
Current log sequence 1205
SQL> show parameter db_recovery_file_dest

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /oradata1
db_recovery_file_dest_size big integer 50G

I also checked for settings whether LOG_ARCHIVE_DEST_10 is implicitly set or not. Yet it was set.
SQL> select DEST_NAME,DESTINATION from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_10';

DEST_NAME
--------------------------------------------------------------------------------
DESTINATION
--------------------------------------------------------------------------------
LOG_ARCHIVE_DEST_10
USE_DB_RECOVERY_FILE_DEST

Step2: Let's check space in flash recovery area.

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

NAME
--------------------------------------------------------------------------------
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
/oradata1
5.3687E+10 32381952 0 2

So it was fine. I suddenly look for alert log and it was changed to

ORA-16038: log 2 sequence# 1160 cannot be archived
ORA-00354: corrupt redo log block header
ORA-00312: online log 2 thread 1: '/oradata1/arju/ARJU/redo02.log'

I immediately try to clear the logfile as it is described in ORA-16038,ORA-00354,ORA-00312 corrupt redo log block header
SQL> alter database clear unarchived logfile group 2;
Database altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;
^C alter system switch logfile
*
ERROR at line 1:
ORA-01013: user requested cancel of current operation

But no hope. It stopped and in alert log again it shows error message Archiving not possible: No primary destinations.

Step3: I set LOG_ARCHIVE_DEST_9 explicitly to DB_RECOVERY_FILE_DEST

With the following statement whenever I explicitly set LOG_ARCHIVE_DEST_9 to use DB_RECOVERY_FILE_DEST then the error gone.
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST';
System altered.

In the alert log I put tail -f and wanted to see that status. Immediately status becomes as follows,

Cleared LOG_ARCHIVE_DEST_10 parameter default value
Mon Jul 21 05:52:04 2008
ALTER SYSTEM SET log_archive_dest_9='LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH;
Mon Jul 21 05:52:04 2008
Archiver process freed from errors. No longer stopped

And error gone. I tested with alter system switch logfile and it went normal.

SQL> alter system switch logfile;
System altered.

SQL> alter system switch logfile;

System altered.

I don't know what happened. Possibly this is oracle bug. Later I explicitly set log_archive_dest_9 to use LOCATION USE_DB_RECOVERY_FILE_DEST and unset log_archive_dest_9 and it went normal.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_10='LOCATION=USE_DB_RECOVERY_FILE_DEST';
System altered.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_9='';

System altered.

Related Documents

ORA-16038,ORA-00354,ORA-00312 corrupt redo log block header
ORA-00257: archiver error. Connect internal only, until freed.

Tuesday, May 20, 2008

Recovering a Database in NOARCHIVELOG Mode

If a media failure damages datafiles in a NOARCHIVELOG database, then the only option for recovery is usually to restore a consistent whole database backup. As you are in noarchivelog mode so you have to understand that changes after taken backup is lost.

If you logical backup that is export file you can import that also.

In order to recover database in noarchivelog mode you have to follow the following procedure.

1)If the database is open shutdown it.
SQL>SHUTDOWN IMMEDIATE;

2)If possible, correct the media problem so that the backup database files can be restored to their original locations.

3)Copy all of the backup control files, datafiles to the default location if you corrected media failure. However you can restore to another location. Remember that all of the files not only the damaged files.

4)Because online redo logs are not backed up, you cannot restore them with the datafiles and control files. In order to allow the database to reset the online redo logs, you must have to do incomplete recovery:

RECOVER DATABASE UNTIL CANCEL
CANCEL


5)Open the database in RESETLOGS mode:
ALTER DATABASE OPEN RESETLOGS;

In order to rename your control files or in case of media damage you can copy it to another location and then by setting (if spfile)
STARTUP NOMOUNT
ALTER SYSTEM SET CONTROL_FILES='/new/1.ctl','/new/2.ctl' scope=spfile;
STARTUP FORCE MOUNT;


In order to rename data files or online redo log files first copy it to new location and then point control file to new location by,

ALTER DATABASE RENAME FILE '/old/system01.dbf' TO '/new_disk/system01.dbf';


Related Documents:
---------------------------

User Managed Restore Operation
What you will do if spfile lost Look at Solution of The problem Section
How to solve problem of inconsistent control file.

How to re-create Control file

Wednesday, May 14, 2008

User Managed, Consistent Backup in Noarchivelog Mode

-You must have to take consistent backup if your database is in noarchivelog mode.

-Remember that database backup taken while the database is open or after an instance failure or SHUTDOWN ABORT is inconsistent.

-So in noarchivelog mode you can't take your backup while the database is open.

-In case of noarchivelog mode you can take your backup after the database has been shut down with the NORMAL, IMMEDIATE, or TRANSACTIONAL options. Backup taken in this way is called consistent backup.

-Consistent backup can be taken whether you are in archive or noarchivelog mode.

-Consistent backup can also called cold backup.

In the following sections I will see an example of how we can taken consistent used Managed Backup.

1)Determine the files that you need to take backup.

Whenever you decide to take your database user managed consistent backup then take backup of data files, control files spfiles and network files.

In order to decide which files you need to backup issue the following query while the database is in open state.

SQL>SELECT NAME "File Need Backup" FROM V$DATAFILE
UNION ALL
SELECT NAME FROM V$CONTROLFILE
UNION ALL
SELECT VALUE FROM V$PARAMETER WHERE NAME='spfile';

File Need Backup
---------------------------------------------------------------------------------
/oradata2/data1/dbase/system01.dbf
/oradata2/data1/dbase/undotbs01.dbf
/oradata2/data1/dbase/sysaux01.dbf
/oradata2/data1/dbase/users01.dbf
/oradata2/data.dbf
/oradata2/data1/data02.dbf
/oradata2/6.dbf
/oradata2/DBASE/datafile/o1_mf_permanen_42l31vg0_.dbf
/oradata2/data_test.dbf
/oracle/app/oracle/product/10.2.0/db_1/dbs/cntrldupbase.dbf
/oracle/app/oracle/product/10.2.0/db_1/dbs/spfiledupbase.ora

11 rows selected.

2)Make clean shutdown of the database.
That is anyone of the following,

SQL>SHUTDOWN
SQL>SHUTDOWN IMMEDIATE
SQL>SHUTDOWN TRANSACTIONAL


3)Use an operating system utility to make backups of all datafiles as well as all control files as shown in section 1. Like,

$scp /oradata2/data1/dbase/system01.dbf /backup
.
.

scp /oracle/app/oracle/product/10.2.0/db_1/dbs/spfiledupbase.ora /backup


Also backup network files. Do a recursive search for *.ora starting in your Oracle home directory and under it.

4)Startup the database.

$sqlplus / as sysdba
SQL>STARTUP

Tuesday, May 13, 2008

User Managed hot backup of oracle database

Used managed backup means you take backup without any oracle feature. Suppose if you take backup by Operating system then it is called user managed backup. And the term hot backup means taking your backup whenever your database is at open state.

To take full database backup follow the following steps.

1)Before proceed remember you can take online/hot backup whenever your database is in Archivelog mode. If your database run on noarchivelog mode then you must take consistent backup that is after cleanly shutdown. In order to determine the archival mode, issue the query,

SQL> SELECT LOG_MODE FROM V$DATABASE;

LOG_MODE
------------
ARCHIVELOG

If you see ARCHIVELOG then you can proceed further. In order to take backup while you are in noarhivelog mode follow other post on my blog.

2)Determine the files that you need to take backup.

Whenever you decide to take your database backup then take backup of data files , online redo log files ,control files, spfile.

In order to decide which files you need to backup issue the following query.

SQL>SELECT NAME "File Need Backup" FROM V$DATAFILE
UNION ALL
SELECT MEMBER FROM V$LOGFILE
UNION ALL
SELECT NAME FROM V$CONTROLFILE
UNION ALL
SELECT VALUE FROM V$PARAMETER WHERE NAME='spfile';


File Need Backup
--------------------------------------------------------------------------------
/oradata2/data1/dbase/system01.dbf
/oradata2/data1/dbase/undotbs01.dbf
/oradata2/data1/dbase/sysaux01.dbf
/oradata2/data1/dbase/users01.dbf
/oradata2/data.dbf
/oradata2/data1/data02.dbf
/oradata2/6.dbf
/oradata2/DBASE/datafile/o1_mf_permanen_42l31vg0_.dbf
/oradata2/data_test.dbf
/oradata2/data1/dbase/redo03.log
/oradata2/data1/dbase/redo02.log
/oradata2/data1/dbase/redo01.log
/oracle/app/oracle/product/10.2.0/db_1/dbs/cntrldupbase.dbf
/oracle/app/oracle/product/10.2.0/db_1/dbs/spfiledupbase.ora
13 rows selected.

So after running the above query I can say I need to backup 13 files.

3)Take the tablespace in backup mode rather than offline and read-only tablespace. In case of offline and read only tablespace you do not have to place the tablespace in backup mode because the database is not permitting changes to the datafiles.

You can check the status, tablespace_name and it's associated data file name with the following query,

SELECT t.STATUS,t.TABLESPACE_NAME "Tablespace", f.FILE_NAME "Datafile"
FROM DBA_TABLESPACES t, DBA_DATA_FILES f
WHERE t.TABLESPACE_NAME = f.TABLESPACE_NAME;
ORDER BY t.NAME;


Take the tablespace in backup mode rather than offline and read-only tablespace.

You can easily make a script of taking the online tablespace in backup mode by following query.

SQL>SELECT 'ALTER TABLESPACE ' ||TABLESPACE_NAME ||' BEGIN BACKUP;' "Script" FROM DBA_TABLESPACES WHERE STATUS NOT IN ('READ ONLY','OFFLINE');

Script
-------------------------------------------------------------
ALTER TABLESPACE SYSTEM BEGIN BACKUP;
ALTER TABLESPACE UNDOTBS1 BEGIN BACKUP;
ALTER TABLESPACE SYSAUX BEGIN BACKUP;
ALTER TABLESPACE TEMP BEGIN BACKUP;
ALTER TABLESPACE USERS BEGIN BACKUP;
ALTER TABLESPACE TEMP_T BEGIN BACKUP;

6 rows selected.

Alternatively, you can issue

SQL>ALTER DATABASE BEGIN BACKUP;


4)Copy the datafile to backup location.

After making a tablespace in backup mode take backup/copy of the associated datafiles. Here you can also make a script in order to copy datafiles to another location.

For online tablespace you must at first take it backup mode. You can check whether backup mode now active or not by issuing following query,

SQL>SELECT t.name AS "TB_NAME", d.file# as "DF#", d.name AS "DF_NAME", b.status
FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
WHERE d.TS#=t.TS#
AND b.FILE#=d.FILE#
AND b.STATUS='ACTIVE';

SQL> SELECT 'host scp '|| FILE_NAME || ' &backup_location ' "Backup Command" FROM DBA_DATA_FILES;
Enter value for backup_location: /backup

old 1: SELECT 'host scp '|| FILE_NAME || ' &backup_location ' "Backup Command" FROM DBA_DATA_FILES
new 1: SELECT 'host scp '|| FILE_NAME || ' /backup ' "Backup Command" FROM DBA_DATA_FILES

Backup Command
------------------------------------------------------------------------------------------
host scp /oradata2/data1/dbase/system01.dbf /backup
host scp /oradata2/data1/dbase/undotbs01.dbf /backup
host scp /oradata2/data1/dbase/sysaux01.dbf /backup
host scp /oradata2/data1/dbase/users01.dbf /backup
host scp /oradata2/data.dbf /backup
host scp /oradata2/data1/data02.dbf /backup
host scp /oradata2/6.dbf /backup
host scp /oradata2/DBASE/datafile/o1_mf_permanen_42l31vg0_.dbf /backup
host scp /oradata2/data_test.dbf /backup

9 rows selected.

Also you can backup network files. Do a recursive search for *.ora starting in your Oracle home directory and under it.

In order to make script for to copy data files for those tablespace which are only in backup mode then issue,

SQL>SELECT 'host scp '|| d.name ||' &backup_location' FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
WHERE d.TS#=t.TS#
AND b.FILE#=d.FILE#
AND b.STATUS='ACTIVE';


Run the script that you genereted.

On windows or other operating system you can use graphical browser to copy or other associated copy command.

5)Whenever you copy is finished make the tablespace out of backup mode. You can issue BEGIN BACKUP .. SCP serially (Take one tablespace in begin backup mode and then copy the associated datafiles and make the tablespace out of backup mode) or you can do it parallely(Take all tablespaces in begin backup mode and then copy the associated datafiles of all tabelspaces and then make the tablespace out of backup mode).

You here also make a script like,

SQL>SELECT 'ALTER TABLESPACE ' ||t.name ||' END BACKUP;' "End Backup Script"
FROM V$DATAFILE d, V$TABLESPACE t, V$BACKUP b
WHERE d.TS#=t.TS#
AND b.FILE#=d.FILE#
AND b.STATUS='ACTIVE';

End Backup Script
----------------------------------------------------------
ALTER TABLESPACE SYSTEM END BACKUP;

You if you have taken Database in backup mode then issue

SQL>ALTER DATABASE END BACKUP;


Related Documents:
-----------------------

Types and Methods of Taking database backup

Saturday, May 3, 2008

What will be the Archived Redo Log Destination in Oracle

•As a sysdba privilege issue "archive log list" to see your present archival destination settings.

SQL> ARCHIVE LOG LIST

Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1
Next log sequence to archive 2
Current log sequence 2

•Based on the destination you can see the physical destination of your archived redo log file in the v$parameter. You can use,

SQL> SHOW PARAMETER DB_RECOVERY_FILE_DEST

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /oradata2/flash_recovery_area
db_recovery_file_dest_size big integer 2G


Now a question is for which parameter settings my archived destination affects. In the following I will try to clear the idea.

•If you set LOG_ARCHIVE_DEST parameter then this parameter is used to locate the archived redo log destination.

•If you set DB_RECOVERY_FILE_DEST and and no LOG_ARCHIVE_DEST_n is specified, then LOG_ARCHIVE_DEST_10 is implicitly set to archival destination. However if you set LOG_ARCHIVE_DEST_10 explicitly empty then this behavior changed. Like,

SQL> select DEST_NAME,DESTINATION from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_10';


DEST_NAME DESTINATION
------------------------------ ------------------------------
LOG_ARCHIVE_DEST_10 USE_DB_RECOVERY_FILE_DEST

Though you can implicitly change DB_RECOVERY_FILE_DEST to another destination like LOG_ARCHIVE_DEST_9.

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_9='LOCATION=USE_DB_RECOVERY_FILE_DEST';

System altered.

SQL> select DEST_NAME,DESTINATION from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_10';

DEST_NAME DESTINATION
------------------------------ ------------------------------
LOG_ARCHIVE_DEST_10

SQL> select DEST_NAME,DESTINATION from v$archive_dest where dest_name='LOG_ARCHIVE_DEST_9';

DEST_NAME DESTINATION
------------------------------ ------------------------------
LOG_ARCHIVE_DEST_9 USE_DB_RECOVERY_FILE_DEST


•If you set any local destinations for LOG_ARCHIVE_DEST_n, then archived redo logs are stored only in the destinations you specify using those parameters. In this case, redo log files are not archived in the flash recovery area by default. Though if you want to archive redo log to flash recover area then use LOCATION=USE_DB_RECOVERY_FILE_DEST as in previous example.

•If you do not set any value for LOG_ARCHIVE_DEST, LOG_ARCHIVE_DEST_n, or DB_RECOVERY_FILE_DEST, then the redo logs are archived to a default location that is platform-specific. On Solaris, for example, the default is ?/dbs/arch.

SQL> alter system set log_archive_dest_9='';
System altered.

SQL> archive log list

Database log mode Archive Mode
Automatic archival Enabled
Archive destination ?/dbs/arch
Oldest online log sequence 1
Next log sequence to archive 2
Current log sequence 2

Wednesday, April 16, 2008

ORA-16018 And ORA-16019 LOG_ARCHIVE_DEST with LOG_ARCHIVE_DEST_n

These two errors come whenever LOG_ARCHIVE_DEST is set as archival location and you want to set DB_RECOVERY_FILE_DEST (ORA-16019) or whenever DB_RECOVERY_FILE_DEST is set as archival location and you want to set log_archive_dest (ORA-16018).

With an example I will discuss the whole matter.

1)Before proceed issue ARCHIVE LOG LIST to see destination.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 215
Next log sequence to archive 217
Current log sequence 217

2)You can check your current archival location by issuing, show parameter DB_RECOVERY_FILE_DEST

SQL> show parameter DB_RECOVERY_FILE_DEST

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /oradata2
db_recovery_file_dest_size big integer 30G

3)Now you want to set log_archive_dest.

SQL> alter system set log_archive_dest='/oradata1';
alter system set log_archive_dest='/oradata1'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16018: cannot use LOG_ARCHIVE_DEST with LOG_ARCHIVE_DEST_n or
DB_RECOVERY_FILE_DEST

4)If you want to set log_archive_dest first reset DB_RECOVERY_FILE_DEST and then set
.

SQL> alter system set DB_RECOVERY_FILE_DEST='';

System altered.

SQL> alter system set log_archive_dest='/oradata1';

System altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradata1
Oldest online log sequence 215
Next log sequence to archive 217
Current log sequence 217

5)Also if you now want to set DB_RECOVERY_FILE_DEST ORA-16019: will occur.
SQL> alter system set DB_RECOVERY_FILE_DEST='/oradata2';
alter system set DB_RECOVERY_FILE_DEST='/oradata2'
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-16019: cannot use db_recovery_file_dest with LOG_ARCHIVE_DEST or
LOG_ARCHIVE_DUPLEX_DEST

6)To set DB_RECOVERY_FILE_DEST first reset LOG_ARCHIVE_DEST.

SQL> alter system set log_archive_dest='';

System altered.

SQL> alter system set DB_RECOVERY_FILE_DEST='/oradata2';

System altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 215
Next log sequence to archive 217
Current log sequence 217

To set multiple location of archival destination set another log_archive_dest_n parameter like,
SQL> alter system set log_archive_dest_3='LOCATION=/oradata2';
System altered.


Related Documents
Change Database Archival Mode
Managing Archive Destination

Wednesday, April 2, 2008

ORA-00257: archiver error. Connect internal only, until freed.

Cause of the Problem:
The archiver process received an error while trying to archive a redo log. If the problem is not resolved soon, the database will stop executing transactions. The most likely cause of this message is the destination device is out of space to store the redo log file.

Solution of the Problem:

I try to demonstrate two types of Solution to this problem.

A)Without increasing DB_RECOVERY_FILE_DEST_SIZE.
B)By increasing DB_RECOVERY_FILE_DEST_SIZE.

A)Without increasing DB_RECOVERY_FILE_DEST_SIZE.

1. Check whether the database is in archive log mode and automatic archiving is enabled.
SQL> archive log list;

2. If archive destination is defined by USE_DB_RECOVERY_FILE_DEST, find the archive destination by :

SQL> show parameter db_recovery_file_dest;


Check what the value for db_recovery_file_dest_size.

3. Find the space used in flash recovery area by :

SQL> SELECT * FROM V$RECOVERY_FILE_DEST;

4. If SPACE_USED is equal to SPACE_LIMIT of db_recovery_file_dest, move the archive logs to different destination.

5. Archive all the log files
SQL> alter system archive log all;

6. Just switch the logs to verify:

SQL> alter system switch logfile;

Another approach of solving this type of problem without increasing DB_RECOVERY_FILE_DEST_SIZE is to delete (archive log) files from DB_RECOVERY_FILE_DEST if you are sure you have backups and the archived logs are no longer necessary.

Like,
$rman target /
RMAN>delete archivelog until time 'SYSDATE-1';

or,
RMAN>delete archivelog all;

B)By increasing DB_RECOVERY_FILE_DEST_SIZE.

1. See the path of flash recovery area.

SQL> show parameter db_recovery_file_dest;


2. Disable the Flash Recovery Area

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='';

3. Increase the Flash Recovery Area

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10g;


4. Enable the Flash Recovery Area

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '/oradata1';

Related Documents
Archiving not possible: No primary destinations
ORA-00313: open failed for members of log group