oracle administration

Wednesday, April 2, 2008ORA-00214: Controlfile Version Inconsistent on Startup or Shutdown Problem Description:ORA-00214: control file {name} version {num} inconsistent with file {name}.

Cause of The Problem:Oracle detects an inconsistency between the mirrored copies of the control file.

All copies of the control file must have the same internal sequence number for oracle to start up the database or shut it down in normal or immediate mode.

If the database is running and the checkpoint in the file header could not be advanced the datafile will be taken offline.

Typical scenarios in which you may receive an ORA-00214 include:

1. You have restored the control file from backup, but forgot to copy it onto all of the mirrored copies of the control file as listed in the "CONTROL_FILES" parameter in the initialization parameter.

2. You have moved one or more copies of the control file to a different location while the database was up and running.

3. You accidentally overwrote one of the copies of the control file with an old copy.

4. The database or the system crashed while the mirrored copies of the control file were being updated, causing them to be out of sync.

5. You are restoring a database backup that was improperly taken with the database up and running ("fuzzy" backup).

Solution of the Problem:To fix the error start your database with single copy of the control file and then shut the database down and then copy the version of good copy of control file onto the other mirror copies.

Step 01) If database is still up do a shutdown abort.

Step 02) If you use pfile then edit the CONTROL_FILES parameter from init.ora and modify it to include just one copy of control file.

If you use spfile then after issuing startup nomount use show control_files to see existing controlfiles inside spfile and then you can use ALTER SYSTEM SET CONTROL_FILES=file_name; in order to point just one copy of control file.

Step 03) Start the database in restricted mode. startup restrict If it is fine go to step 04.

If instead you get ORA-1122, ORA-1110, and ORA-1207, go back to step 2 and try with another control file.

If you have already tried each and every one of the mirrored copies unsuccessfully, you must create a new control file for the database.

If you get ORA-1113 and ORA-1110 pointing to one of the datafiles, it means the copy of the control file you picked is good, but the referenced datafile must be recovered before the database can be opened.Then RECOVER DATBASE, apply the log it prompt and ALTER DATABASE OPEN.

Step 04) Shut the database down.SQL>shutown

Step 05) Copy the good mirrored copy of the control file that you just used to bring the database up onto all other copies, as originally listed in the CONTROL_FILES parameter of your init.ora file.

Step 06) Edit the init.ora file's CONTROL_FILES parameter to include all mirror copy again.

Step 07) Start the database.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

ORA-00214: Controlfile Version InconsistentNovember 20, 2009 sarith Leave a comment Go to comments

ERROR at line 1:ORA-00214: controlfile ‘C:\ORACLE\ORADATA\DB01\CONTROL01.CTL’ version 16703inconsistent with file ‘C:\ORACLE\ORADATA\DB01\CONTROL04.CTL’ version 16648Its because of the inconsistency between the mirrored copies of the control files.All copies of the control file must have the same internal sequence number for oracle to start up the database or shut it down in normal or immediate mode.

Causes of the problem ORA-00214 includes,

1. You have restored the control file from backup, but forgot to copy it onto all of the mirrored copies of the control file as listed in the “CONTROL_FILES” parameter in the initialization parameter.

2. Improper Copy paste of the control file to a different location while the database is up and running.


5. Not proper Shut down of the Oracle Machine. Like power failure, disk failure, Memory Failure

Solution

Startup the database with single copy of the Control File. That should be a good copy.

1. Shut Abort

2. If you are using pfile, Edit init.ora file. Remove all the control file Except the Good one. Try One by one. Most probable highest Version Number will work.

3. If you are using spfile;

startup nomount. Then Set your control_file to the good one.

SQL> alter system set control_files=’c:\oracle\oradata\db01\control02.ctl’ scope=spfile;

System altered

4. Startup restrict [If its working]. Shut down the database. Copy the good control file and Mirror it

Startup.




&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&Hi,If you have no backup of your control file then you should create new control file with current database structure.

STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS ARCHIVELOGMAXLOGFILES 16MAXLOGMEMBERS 3MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 7271LOGFILEGROUP 1 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO01.LOG' SIZE 10M,GROUP 2 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO02.LOG' SIZE 10M,GROUP 3 'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\REDO03.LOG' SIZE 10M-- STANDBY LOGFILEDATAFILE

'C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSTEM01.DBF','C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\UNDOTBS01.DBF','C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\SYSAUX01.DBF','C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\USERS01.DBF','C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\EXAMPLE01.DBF','C:\ORACLE\PRODUCT\10.1.0\ORADATA\ORCL\USERS02.DBF'CHARACTER SET WE8MSWIN1252;

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&Hi

You could update the control_files parameter in init.ora file with the first copy of the control file and delete all other entries and try performing

startup restrict

If the database comes up then it shutdown normal and copy that file to all mirrored copies (take copies of all controlfiles before you try this ) and restore the control_files parameter in the init.ota file and restart

if not try modifying the control_files parameter to the next mirrored copy and retry the steps above .

thanks

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&Tuesday, January 12, 2010ORA-00205: error in identifying control file Problem DescriptionWhenever you try to start your oracle database instance or mount your database it fails with ORA-00205 error message as below.SQL> startupORACLE instance started.

Total System Global Area 535662592 bytesFixed Size 1334380 bytesVariable Size 306185108 bytesDatabase Buffers 222298112 bytesRedo Buffers 5844992 bytesORA-00205: error in identifying control file, check alert log for more info

Error InvestigationAs error message "ORA-00205: error in identifying control file, check alert log for more info" suggests to look for alert log messages so immediately after getting this error message you should look for alert log message.

Based on this error message you might get various types of alert long entries which would really help you to solve your problem. Following is the several versions of error messages.

Error Message Version 01:ORA-00202: control file: '/oracle/controlfile/contro101.ctl'ORA-27037: unable to obtain file statusLinux Error: 2: No such file or directoryAdditional information: 3Fri Jan 8 11:19:42 2010ORA-205 signalled during: ALTER DATABASE MOUNT...Fri Jan 8 11:19:50 2010Shutting down instance (abort)

Error Message Version 02: ORA-00202: controlfile: '/oracle/controlfile/CONTROL01.CTL'ORA-27086: skgfglk: unable to lock file - already in useOSD-04002: unable to open fileO/S-Error: (OS 5) Access is denied.

Error Message Version 03:ORA-00202: control file: 'F:\ORACLE\CONTROL.CTL'ORA-27047: unable to read the header block of fileOSD-04006: ReadFile() failure, unable to read from fileO/S-Error: (OS 38) Reached the end of the file.

Error Message Version 04:Errors in file /oracle/9.2.0/admin/bdump/abc_ckpt_3117.trc:ORA-00206: error in writing (block 3, # blocks 1) of controlfileORA-00202: controlfile: '/oracle/data/ctl03.dbf'ORA-27072: skgfdisp: I/O errorLinux Error: 30: Read-only file systemAdditional information: 2

General Cause And Solution of ORA-00205 Problem:The ORA-00205 problem is reported because the system could not find a control file of the specified name and size. The name of control file is

specified by the CONTROL_FILES initialization parameter within spfile/pfile. While mounting oracle database oracle finds that in the disk all those files are not there or size is unmatched as it is specified within spfile/pfile.

If you see ORA-00205 is reported while starting up/mount the oracle database then check that the proper control filename is referenced in the CONTROL_FILES initialization parameter in the initialization parameter. If not check your correct spfile/pfile or fix location of CONTROL_FILES parameter within spfile/pfile and try again to mount the database.

Whenever you are using mirrored control files, that is, more than one control file is referenced in the initialization parameter file, remove the control filename listed in the message from the initialization parameter file and restart the instance. If the message does not recur, remove the problem control file from the initialization parameter file and create another copy of the control file with a new filename in the initialization parameter file.

Step by step SolutionStep 01: After you see ORA-00205 immediately look for alert log files for further investigation.

Step 02: Check the control_files parameter in your initialization parameter. You can simply check by ,SQL> show parameter control_files

NAME TYPE VALUE------------------------------------ ----------- ------------------------------control_files string D:\APP\ARJU\ORADATA\A\CONTROL01.CTL, D:\APP\ARJU\ORADATA\A\CONTROL02.CTL, D:\APP\ARJU\ORADATA\A\CONTROL03.CTL

Now compare this location with the location of controlfile in your disk system.

From the alert log if you see error message like version 1 i.e you have noticed "ORA-00202: control file: '/oracle/controlfile/contro101.ctl'" then from your CONTROL_FILES initialization parameter remove the entry /oracle/controlfile/contro101.ctl if you have multiple version of controlfiles and start the database. If you fail then again check for alert logs. If it is same error message like points to another controlfile then try to remove that control file too if you have at least three versions of controlfiles. If you fail then

possibly all of your controlfiles are lost. In that case you need to restore controlfile from previous backup or create a new one if you don't have any previous backup of controlfile. In the post Recover database after only lose of all controlfiles it is discussed how you can recover controlfile. In the post Restore the Controlfile from Backup using RMAN it is discussed how you can restore controlfile from previous RMAN backup using RMAN. In the post How to create controlfile it is discussed how to create a controlfile whenever you are lost all controlfile and you don't have any backups.

If you see other version of error versions then take necessary actions as alert log suggests. For example if you see error message like version 2 that is "ORA-00202: controlfile: '/oracle/controlfile/CONTROL01.CTL'ORA-27086: skgfglk: unable to lock file - already in use"then ensure that oracle database is shutdown cleanly and no other process is holding lock of the control file. After you ensure that try starting database again.

If you see error message like version 3 that is "ORA-27047: unable to read the header block of fileOSD-04006: ReadFile() failure, unable to read from file"then possibly your control file got corrupted and follow the same steps as it is demonstrated in step 2 for error version 01.

If you see error message like version 4 that is"ORA-00202: controlfile: '/oracle/data/ctl03.dbf'ORA-27072: skgfdisp: I/O errorLinux Error: 30: Read-only file system"then ensure that your control file has proper permission set from operating system. That means it must have read, write permission to oracle owner user.

Step 03: After you identify and solve the problem ensure that you have multiple copies of your CONTROL_FILES parameter onwards. If you use spfile in your database startup then after your nomount state of database and physically copied controlfiles to all locations as you want, you can point multiple copies of controlfile by issuing "ALTER SYSTEM SET CONTROL_FILES=..., ..." command from database. A similar example is demonstrated in the topic ORA-00214: Controlfile Version Inconsistent on Startup or Shutdown

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

ORA-01665: control file is not a standby control file

Problem DescriptionWhile recovering standby database, using command alter database recover managed standby database disconnect from session it fails with message ORA-01665: control file is not a standby control file like below.SQL> alter database recover managed standby database disconnect from session;alter database recover managed standby database disconnect from session*ERROR at line 1:ORA-01665: control file is not a standby control file

Cause of the ProblemThe error occurred because there was an attempt to mount, recover, or activate a standby database without a standby controlfile. In order to recover standby database you need standby controlfile. If you don't have standby controlfile and use normal controlfile then above error will occurred.

Solution of the ProblemThe solution is to create a standby controlfile before attempting to use the database as a standby database.

1)So if you don't have a standby controlfile for your standby first create a standby controlfile from source database using command,

SQL>alter database create standby controlfile as 'standbyctlfile.ctl';

2)Transfer this standby controlfile into standby database.

3)Edit the standby database pfile control_files parameter in order to effect the changes.

4)Startup the database in nomount stage.SQL> startup nomount pfile='your_pfile_location';

5)Create spfile from the pfile.SQL> create spfile from pfile='your_pfile_location';

6)Shutdown the database.SQL>shutdown immediate;

7)Start the database in mount state.SQL>startup mount;

8)On the standby database, start redo apply by following command.SQL>alter database recover managed standby database disconnect from session;

Note that only step 1) need to be performed in primary database only. All other steps will be done in standby database.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Controlfile in Oracle Database. Every database has a control file which is a binary file that records the physical structure of the database. Control file is called the heart of the database.

The control file includes:

• The database name.

• Names and locations of associated datafiles and redo log files.

• The timestamp of the database creation.

• The current log sequence number.

• Checkpoint information.

• Information of the tablespaces.

• Datafile offline ranges.

• The log history.

• Archived log information.

• Database backup information taken through RMAN.

• The current log sequence number.

• Datafile copy information.

How to see the control file Contents:

--------------------------------------

Control file creation sql command/syntax can be seen by,

alter database backup controlfile to trace as '/oradata/1.txt'

After issuing the command if you open /oradata/1.txt you will see the sql script of creation controlfile.

If you don't use trace suppose you use,alter database backup controlfile as '/oradata/1.txt' then you will get a duplicate binary copy of the current control file.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Backup Database control file -User Managed Backup of controlfile is necessary if you make and modification to your database structure. For example if you add a a new tablespace or add a new datafile to an existing tablespace then backup the control file so that in the backup control file the database structure become up to date which will help you to perform database recovery in case of any problem.

If you configure the configuration parameter CONFIGURE CONTROLFILE AUTOBACKUP ON then control file is automatically backup after each database structural changes.

There are two user managed method to take control file backup.

1)Take control file Backup as a Binary File:-----------------------------------------------A binary backup is preferable to a trace file backup because it contains additional information such as-the archived log history,-offline range for read-only and offline tablespaces,-and backup sets and copies (if you use RMAN).

But binary control file backups do not include tempfile entries.

To take control file backup as a binary file just issue,SQL>ALTER DATABASE BACKUP CONTROLFILE TO '/oradata2/control.bak';

2)Backup control file as a Text file.-------------------------------------------To take backup control file as a text file simply issue,SQL>ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS '/oradata2/control.bak';

If you specify neither the RESETLOGS nor NORESETLOGS option in the SQL statement, then the resulting trace file contains versions of the control file for both RESETLOGS and NORESETLOGS options.

Unlike binary backup of control file backup to trace tempfile entries are included- in the output using "ALTER TABLESPACE... ADD TEMPFILE" statements.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Recover database after only lose of all controlfiles This example is based on,You have lost all your current and backup of controlfile.You have avaiable your current data files.You have available your online redo log files.

In the scenario, I will show the procedure of how to recover database if you lose your all copies of controlfiles and you don't have any backup of your controlfile.

Let's start by deleting controlfile of my running database.

1.In order to know the controlfiles of my database issue,SQL> select name from v$controlfile;

NAME--------------------------------------------------------------------------------/oradata2/arjudba/arjudba/control01.ctl/oradata2/arjudba/arjudba/control02.ctl/oradata2/arjudba/arjudba/control03.ctl

2.Delete all copies of controlfile. Here with one command I have deleted. But before deleting with one such command be conscious that this command will not delete other important files. You can delete files one by one.SQL> !rm /oradata2/arjudba/arjudba/control0*

3.Now let's see whether controlfile is available or not by issuing following command.SQL> shutdown abortORACLE instance shut down.SQL> startupORACLE instance started.

Total System Global Area 314572800 bytesFixed Size 2020416 bytesVariable Size 121637824 bytesDatabase Buffers 184549376 bytesRedo Buffers 6365184 bytesORA-00205: error in identifying control file, check alert log for more info

As it can't read controlfile so ORA-00205 arises.

4.From this state is your situation what you need to do. If you have previously issued ALTER DATABASE BACKUP CONTROLFILE TO TRACE then use that file and modify. If you don't have any backup of controlfile then you have to create a new one as below. Note that you have to remember the name of datafile and online redo log file.-bash-3.00$ vi /oradata2/ctl.ctlSTARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "ARJUDBA" NORESETLOGS ARCHIVELOGMAXLOGFILES 16MAXLOGMEMBERS 3MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 292LOGFILEGROUP 1 '/oradata2/arjudba/arjudba/redo01.log' SIZE 50M,GROUP 2 '/oradata2/arjudba/arjudba/redo02.log' SIZE 50M,GROUP 3 '/oradata2/arjudba/arjudba/redo03.log' SIZE 50MDATAFILE'/oradata2/arjudba/arjudba/system01.dbf','/oradata2/arjudba/arjudba/undotbs01.dbf','/oradata2/arjudba/arjudba/sysaux01.dbf','/oradata2/arjudba/arjudba/users01.dbf'CHARACTER SET WE8ISO8859P1;

5.Save the script and run it inside SQL*plus.SQL> @/oradata2/ctl.ctlORA-01081: cannot start already-running ORACLE - shut it down first

Control file created.

6. At this stage your database is mounted. You need to recover it.SQL> recover database;Media recovery complete.

7.Open the database after recovery completes.SQL> alter database open;Database altered.

8.As Create controlfile statement does not include Temp tablespace you may need to add it.SQL>ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata2/arjudba/arjudba/temp01.dbf'SIZE 20971520 REUSE AUTOEXTEND ON NEXT 655360 MAXSIZE 32767M;

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&When and How to Recreate the Controlfile When to Create ControlfileNo one should not create control file until he is not suppose to do it. You should only need to recreate your control file under very special circumstances:

1)All current copies of the control file have been lost or are corrupted.

2)You need to change a "hard" database parameter such as MAXDATAFILES, MAXLOGFILES, MAXLOGHISTORY, etc. Though after 10.2g it is handled by database.

3)You are restoring a backup in which the control file is corrupted or missing.

4)If you are moving your database to another machine which is running the same operating system but the location of the datafiles, logfiles is not the same.

How I will create a new control file:

In this case I may have to face two scenarios.

Scenario 1:CREATING A NEW CONTROL FILE FROM THE EXISTING CONTROL FILE:--------------

1.Create a control file traceSQL> conn / as sysdbaSQL>startup mount;SQL>alter database backup controlfile to trace as 'file.txt';

2.Modify the trace file 'file.txt' and change the required parameter in it.

3.Shutdown the database. shutdown immediate;

4.Take a full database backup.

5.Rename/move the existing database controlfiles to a backup.

6.Create the new controlfile.

7.Take backup of full database.

CREATING A NEW CONTROL FILE WITHOUT AN EXISTING CONTROL FILE: ----------------------------------------------------------------- 1. Take a full backup of the database, including all datafiles and redo log files.

2.Do a startup nomount.

3.Issue the create controlfile statement.

4. Perform media recovery on the database. recover database.

5.Open the database. Alter database open.

6. At the first opportunity, shut the database down and take a full cold backup.

Here is one script of how you can create a new controlfile.

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE "database_name_here" NORESETLOGS NOARCHIVELOGMAXLOGFILES 32MAXLOGMEMBERS 2MAXDATAFILES 32MAXINSTANCES 1MAXLOGHISTORY 449LOGFILEGROUP 1 'path of redo log member here' SIZE 500K,GROUP 2 'path of redo log member here' SIZE 500KDATAFILE'list of datafile name here','/path/oracle/dbs/data.dbf','/path/oracle/dbs/data02.f','/path/oracle/dbs/arju02.dbf','/path/oracle/dbs/arju.dbfCHARACTER SET WE8DEC;

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&How to Restore the Controlfile from Backup. If you loss or if your all copies of control file is corrupted and if you have backup of your control file then it is required to restore your control file from your backup.

Restore control file to default location:----------------------------------------------The default location is defined by CONTROL_FILES parameter of pfile/spfile. If you don't specify any location while restoring your control file then the control file will be restored to the location set by CONTROL_FILES parameter. TO determine DBID check http://arjudba.blogspot.com/2008/05/how-to-discover-find-dbid.html

RMAN>SET DBID 3386862614RMAN> RUN {RESTORE CONTROLFILE FROM AUTOBACKUP;}Restore of the Control File from Control File Autobackup-------------------------------------------------------------If you are not using a recovery catalog, you must restore your control file from an autobackup. The database must be in a NOMOUNT state. And you

have to set DBID. RMAN uses the autobackup format and DBID to determine where to find for the control file autobackup.

RMAN>SET DBID 3386862614RMAN> RUN {SET CONTROLFILE AUTOBACKUP FORMATFOR DEVICE TYPE DISK TO 'autobackup_format';RESTORE CONTROLFILE FROM AUTOBACKUP;}

Restore of the Control File When Using a Flash Recovery Area---------------------------------------------------------------------Suppose you restored a backup of the control file. Now in that control file the backup information may not updated/full. May be it contains only current backup information of that session while taking backup. If you use flash recovery area then RMAN automatically catalog the backups in the flash recovery area. As a result the restored control file has a complete and accurate record of all backups in your flash recovery area and any other backups that were known to the control file at the time of the backup.

Restoring a Control File When Using a Recovery Catalog------------------------------------------------------------------The recovery catalog contains a complete record of your backups, including backups of the controlfile. Therefore, you do not have to specify your DBID or control file autobackup format.Just use,

$rman TARGET / CATALOG catdb/catdbRMAN> RESTORE CONTROLFILE;

Restore of the Control File From a Known Location-----------------------------------------------------If you know the backuppiece of controlfile or any copy then simply you can use,

RMAN> RESTORE CONTROLFILE from 'filename';

Restore of the Control File to a New Location---------------------------------------------------In prior cases RMAN restore the control file to the location specified by CONTROL_FILES parameter of the spfile or pfile.

If you want to restore the control file to another location use,RMAN>RESTORE CONTROLFILE TO 'give_here_new_location';

You can also change CONTROL_FILES parameter and then perform RESTORE CONTROLFILE to change location.

Limitations When Using a Backup Control File------------------------------------------------After you restore your database using a backup control file, you must run RECOVER DATABASE and perform an OPEN RESETLOGS on the database.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&ORA-00214: Controlfile Version Inconsistent on Startup or Shutdown Problem Description:ORA-00214: control file {name} version {num} inconsistent with file {name}.










&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&ORA-00214: Controlfile Version Inconsistent on Startup or Shutdown Problem Description:ORA-00214: control file {name} version {num} inconsistent with file {name}.






















&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Oracle Concepts - pfile and spfileOracle Tips by Burleson Consulting

Introducing the PFILE and SPFILEOracle provides two different types of mutually exclusive parameter files that you can use, PFILE and SPFILE. Let’s look at the PFILE and the SPFILE in a bit more detail.

The Oracle PFILEAs we said, the parameters are stored in either a PFILE or an SPFILE. The PFILE is a text-based file, and the “init.ora” file has been around for over a decade. Inside the PFILE are a number of database settings called parameters. These parameters help the Oracle programs know how to start. The parameters tell the Oracle programs how much memory to allocate, where to put files related to the database and where certain database files already exist.

As the PFILE is text based, one can edit it in an editor like vi on UNIX or Notepad on Windows. When you have changed it, you need to make sure you save your changes to disk before you exit the editor. Also, make sure you save it as a plain text file, since some editors (like Microsoft Word) can save documents in special formats that Oracle would not be able to read.

Depending on which operating system you are running on, your PFILE is located by default in the ORACLE_HOME\database (usually the case on Windows) or ORACLE_HOME\dbs directory for most other platforms (we talked about where ORACLE_HOME was earlier in this book).

If you are using a PFILE, it takes on the form of initSID.ora, meaning the file will use the ORACLE_SID you defined when you created the database. If your SID is called testdb, the resulting PFILE should be called inittestdb.ora

The Oracle SPFILEThe SPFILE is different from the PFILE in that it can not be directly edited. This is because it has a header and footer that contains binary values. Since you can not change a SPFILE directly, Oracle allows you to manage the SPFILE via the alter system command.

That might sound a bit more complex, but it really is no harder than manually changing a PFILE. For using an SPFILE, you can reap great benefits. It can be backed up by RMAN (Oracle’s backup and recovery software) every time a change is made or when the database is backed up, which means it’s easier to recover (we will talk about RMAN a great deal in a later chapter!). Also, SPFILES allow you to make dynamic changes to parameters that are persistent. For example, remember that we said this database parameter change was not persistent if we were using PFILES:

Alter system set db_recovery_file_dest_size=10g;

If we were using SPFILES the parameter would keep the same value, even after a database restart. This means you only have to change the parameter value in one place, and that you can forget having to change it in the PFILE of the database.

One of the most important benefits of the SPFILE is that Oracle has introduced many automatic tuning features into the core of the database. Without an SPFILE, Oracle can not autotune your database.

An SPFILE uses the same formatting for its file name as the PFILE, except the word spfile replaces init. For instance, if your ORACLE_SID is testdb, the resulting spfile would be called spfiletestdb.ora.

Administering the PFILE and SPFILEAs a DBA the main thing you need to worry about with the SPFILE and PFILES are backing them up. You can use RMAN to backup an SPFILE, or back them up yourself.

Remember that a PFILE is simply a text based file, which means you can copy it to another directory without affecting the Oracle instance. This is the easiest way to backup a PFILE.

To back up an SPFILE, you will first want to convert it to a PFILE. You can do this with the following syntax.

SQL> create pfile from spfile;

This will create a PFILE named initSID.ora in your $ORACLE_HOME/database (Windows) or $ORACLE_HOME/dbs (Linux/Unix) directory.

Note that the SID in initSID.ora will be replaced with the SID of your database as defined during creation.

In addition, you can back up the file directly to the preferred location with the command:

SQL> create pfile=/path/to/backup.ora from spfile;

If the time comes that you must put the SPFILE back into place, you can do so with this command:

SQL> create spfile from pfile=/path/to/backup.ora

If your database is currently running using the SPFILE, be sure to shut down first so Oracle can replace the file. As your SPFILE is in use the entire time your database is running, you should never overwrite it during normal operations

You can use the V$PARAMETER dynamic view to see the current setting of the different database parameters. In this example, we use the DESC SQL*Plus command to describe the V$PARAMETER view, and we then query the V$PARAMETER view to see the value of the control_file parameter setting:

SQL> desc v$parameter Name Null? Type ----------------------------------------- -------- ------------- NUM NUMBER NAME VARCHAR2(80) TYPE NUMBER VALUE VARCHAR2(512) DISPLAY_VALUE VARCHAR2(512) ISDEFAULT VARCHAR2(9) ISSES_MODIFIABLE VARCHAR2(5) ISSYS_MODIFIABLE VARCHAR2(9) ISINSTANCE_MODIFIABLE VARCHAR2(5) ISMODIFIED VARCHAR2(10) ISADJUSTED VARCHAR2(5) ISDEPRECATED VARCHAR2(5) DESCRIPTION VARCHAR2(255) UPDATE_COMMENT VARCHAR2(255) HASH NUMBER SQL> select name, value from v$parameter where name = 'control_files'; NAME VALUE-------------------- -----------------------------------------------control_files C:\ORACLE\ORADATA\BOOKTST\BOOKTST\CONTROL01.CTL, C:\ORACLE

\ORADATA\BOOKTST\BOOKTST\CONTROL02.CTL, C:\ORACLE\ORADATA\ BOOKTST\BOOKTST\CONTROL03.CTLYou may also use the shortcut “show parameter” command. For instance:

SQL> show parameter control_files;

The Parameter File at Startup TimeOracle prefers the use of an SPFILE to a PFILE. When you startup your Oracle database, Oracle will scan the contents of your parameter directory ($ORACLE_HOME/database on Windows or the Linux directory name $ORACLE_HOME/dbs), searching in the following order:

* spfileSID.ora

* spfile.ora

* initSID.ora

* init.ora

If the directory contains none of the above, then the startup will fail.

Alternatively, you can tell Oracle where to find a PFILE if you store it in a different location.

SQL> startup pfile=/path/to/pfile/inittestdb.ora

Furthermore, you can create a PFILE that contains nothing but the following line:

SPFILE=/path/to/spfiletestdb.ora

By doing so, we are able to startup using a PFILE in any location we want, but continue to use an SPFILE that can also be in a different location. This can be very beneficial for those that wish to store their SPFILE in a centralized location, such as a SAN. Now, let’s take a quick look at redo log administration.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Initialization Parameter files: PFILEs vs. SPFILEsSubmitted by admin on Sun, 2003-08-03 19:29 RDBMS ServerWhen an Oracle Instance is started, the characteristics of the Instance are established by

parameters specified within the initialization parameter file. These initialization parameters are either stored in a PFILE or SPFILE. SPFILEs are available in Oracle 9i and above. All prior releases of Oracle are using PFILEs.

SPFILEs provide the following advantages over PFILEs:

◦An SPFILE can be backed-up with RMAN (RMAN cannot backup PFILEs)◦Reduce human errors. The SPFILE is maintained by the server. Parameters are checked before changes are accepted.◦Eliminate configuration problems (no need to have a local PFILE if you want to start Oracle from a remote machine)◦Easy to find - stored in a central locationWhat is the difference between a PFILE and SPFILE:

A PFILE is a static, client-side text file that must be updated with a standard text editor like "notepad" or "vi". This file normally reside on the server, however, you need a local copy if you want to start Oracle from a remote machine. DBA's commonly refer to this file as the INIT.ORA file.

An SPFILE (Server Parameter File), on the other hand, is a persistent server-side binary file that can only be modified with the "ALTER SYSTEM SET" command. This means you no longer need a local copy of the pfile to start the database from a remote machine. Editing an SPFILE will corrupt it, and you will not be able to start your database anymore.

How will I know if my database is using a PFILE or SPFILE:

Execute the following query to see if your database was started with a PFILE or SPFILE:

SQL> SELECT DECODE(value, NULL, 'PFILE', 'SPFILE') "Init File Type" FROM sys.v_$parameter WHERE name = 'spfile';You can also use the V$SPPARAMETER view to check if you are using a PFILE or not: if the "value" column is NULL for all parameters, you are using a PFILE.

Viewing Parameters Settings:

One can view parameter values using one of the following methods (regardless if they were set via PFILE or SPFILE):

◦The "SHOW PARAMETERS" command from SQL*Plus (i.e.: SHOW PARAMETERS timed_statistics)◦V$PARAMETER view - display the currently in effect parameter values◦V$PARAMETER2 view - display the currently in effect parameter values, but "List Values" are shown in multiple rows◦V$SPPARAMETER view - display the current contents of the server parameter file.Starting a database with a PFILE or SPFILE:

Oracle searches for a suitable initialization parameter file in the following order:

◦Try to use the spfile${ORACLE_SID}.ora file in $ORACLE_HOME/dbs (Unix) or ORACLE_HOME/database (Windows)◦Try to use the spfile.ora file in $ORACLE_HOME/dbs (Unix) or ORACLE_HOME/database (Windows)◦Try to use the init${ORACLE_SID}.ora file in $ORACLE_HOME/dbs (Unix) or ORACLE_HOME/database (Windows)One can override the default location by specifying the PFILE parameter at database startup:

SQL> STARTUP PFILE='/oradata/spfileORCL.ora'

Note that there is not an equivalent "STARTUP SPFILE=" command. One can only use the above option with SPFILE's if the PFILE you point to (in the example above), contains a single 'SPFILE=' parameter pointing to the SPFILE that should be used. Example:

SPFILE=/path/to/spfile

Changing SPFILE parameter values:

While a PFILE can be edited with any text editor, the SPFILE is a binary file. The "ALTER SYSTEM SET" and "ALTER SYSTEM RESET" commands can be used to change parameter values in an SPFILE. Look at these examples:

SQL> ALTER SYSTEM SET open_cursors=300 SCOPE=SPFILE;

SQL> ALTER SYSTEM SET timed_statistics=TRUECOMMENT='Changed by Frank on 1 June 2003'SCOPE=BOTH

SID='*';The SCOPE parameter can be set to SPFILE, MEMORY or BOTH:

- MEMORY: Set for the current instance only. This is the default behaviour if a PFILE was used at STARTUP.

- SPFILE: update the SPFILE, the parameter will take effect with next database startup

- BOTH: affect the current instance and persist to the SPFILE. This is the default behaviour if an SPFILE was used at STARTUP.The COMMENT parameter (optional) specifies a user remark.

The SID parameter (optional; only used with RAC) indicates the instance for which the parameter applies (Default is *: all Instances).

Use the following syntax to set parameters that take multiple (a list of) values:

SQL> ALTER SYSTEM SET utl_file_dir='/tmp/','/oradata','/home/' SCOPE=SPFILE;

Use this syntax to set unsupported initialization parameters (obviously only when Oracle Support instructs you to set it):

SQL> ALTER SYSTEM SET "_allow_read_only_corruption"=TRUE SCOPE=SPFILE;

Execute one of the following command to remove a parameter from the SPFILE:

SQL> ALTER SYSTEM RESET timed_statistics SCOPE=SPFILE SID=‘*’;SQL> ALTER SYSTEM SET timed_statistics = '' SCOPE=SPFILE;Converting between PFILES and SPFILES:

One can easily migrate from a PFILE to SPFILE or vice versa. Execute the following commands from a user with SYSDBA or SYSOPER privileges:

SQL> CREATE PFILE FROM SPFILE; SQL> CREATE SPFILE FROM PFILE;One can also specify a non-default location for either (or both) the PFILE and SPFILE parameters. Look at this example:

SQL> CREATE SPFILE='/oradata/spfileORCL.ora' from PFILE='/oradata/initORCL.ora';

Here is an alternative procedure for changing SPFILE parameter values using the above method:

◦Export the SPFILE with: CREATE PFILE=‘pfilename’ FROM SPFILE = ‘spfilename’; ◦Edit the resulting PFILE with a text editor◦Shutdown and startup the database with the PFILE option: STARTUP PFILE=filename◦Recreate the SPFILE with: CREATE SPFILE=‘spfilename’ FROM PFILE=‘pfilename’;◦On the next startup, use STARTUP without the PFILE parameter and the new SPFILE will be used.Parameter File Backups:

RMAN (Oracle's Recovery Manager) will backup the SPFILE with the database control file if setting "CONFIGURE CONTROLFILE AUTOBACKUP" is ON (the default is OFF). PFILEs cannot be backed-up with RMAN. Look at this example:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

Use the following RMAN command to restore an SPFILE:

RMAN> RESTORE CONTROLFILE FROM AUTOBACKUP;

oracle administration

Documents