Tuesday, April 5, 2011

Clonning Through DBCA


Cloning is just about creating a copy of production system in to a test or development environment. i.e. Having an exact image of production database in testing environment . Here is one of the easiest way to clone a database . We can clone a database in many different ways .

1.) Clonning using backup of Controlfile
2.) Clonning through DBCA 
3.) Clonning using  OEM 
4.) Clonning using  RMAN Backup

Clonning through DBCA  is one of the least used way to clone or duplicate an Oracle DB but it is the best one. To promote it I write this post. Let's have a look on the steps .

1.) Open the command prompt and type "DBCA" . On the "Welcome" screen click the "Next" button.

2.) On the "Operations" screen select the "Manage Templates" option and click the "Next" button.

3.) On the "Template Management" screen select the "Create a database template" option and select the "From and existing database (structure as well as data)" sub-option then click the "Next" button.

4.) On the "Source database" screen select the relevant database instance and click the "Next" button.

5.) On the "Template properties" screen enter a suitable name and description for the template, confirm the location for the template files and click the "Next" button.

6.) On the "Location of database related files" screen choose either to maintain the file locations or to convert to OFA structure (recommended) and click the "Finish" button.

7.) On the "Confirmation" screen click the "OK" button.

8.) Wait while the Database Configuration Assistant progress screen gathers information about the source database, backs up the database and creates the template.

9.) Depending upon the size of the database it will take some time. For my 8 Gig database, it took like 8 mins. Now we have a template created and we will use to create our new database.

10.) Click on "Next Operation".

11.) Select "Create a Database" option and click "Next".

12.) In "Select a template from the following list to create a database" - select the template name which you provided in Step 6 and click "Next".

13.) Provide the new Service Name for the new database. The SID will automatically be set to the service name entered above. Click "Next".

14.) Let the "Configure the Database with Enterprise Manager" remain checked and "Use Database Control for Database Management" remain checked. Click "Next".

15.) Provide the sys password and click "Next".

16.) Let the "File System" option remain checked unless you want to use ASM or raw for your new database.

17.) Let the "Use Database File Locations from Template remain checked. This is important. Click "Next".

18.) Let the default values for Flash Recover Area remain as they are and click "Next".

19.) Let the "No Scripts to run" remain checked an click "Next".

20.) You can keep the default values for Memory and Sizing over here or change it as per your need and Click "Next".

21.) You are now at the final screen wherein you can all your configurations and verify that they are correct. Clicking next, DBCA will do all your job and your DB should be up and running in next 15-20 mins.

22.) Finally before logging in to the new DB using EM, check the tnsnames.ora and see an entry is created for the new database else add one. You can add a new listenere too in you listener.ora if you want and the do a "lsnrctl reload" to reload the listeners.

23.) Finally do a tnsping on your new database to check all's fine.

24.) Log in using EM and you should have you DB ready in Open mode.

25.) Note all user accounts besides the system account are locked and expired so you need to unlock them to allow users to connect to the new DB.

26.) The whole process took some 30-35 mins and it was all GUI  and no scripts or errors. Seem to be the best way out to duplicate an Oracle 10g database.   


ENJOY   :-)


What is Alert Log File ?

The alert log file is a chronological log of messages and errors written out by an Oracle Database. Typical messages found in this file is: database startup, shutdown, log switches, space errors, etc. This file should constantly be monitored to detect unexpected messages and corruptions.Oracle will automatically create a new alert log file whenever the old one is deleted.

When an internal error is detected by a process, it dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, while other information is for Oracle Worldwide Support. Trace file information is also used to tune applications and instances.

The alert log of a database includes the following information : 
1. ) All internal errors (ORA-00600), block corruption errors (ORA-01578), and deadlock errors (ORA-00060) that occur.
2.) Administrative operations, such as CREATE, ALTER, and DROP statements and STARTUP, SHUTDOWN, and ARCHIVELOG statements.
3.) Messages and errors relating to the functions of shared server and dispatcher processes.
4.) Errors occurring during the automatic refresh of a materialized view.
5.) The values of all initialization parameters that had non-default values at the time the database and instance startup .

which process writes to alert log file?
Not "one" but all the background processes can/do write to it. The archiver writes to it. LogWriter can write (if we have log_checkpoints_to_alert). When a background process detects that another has died, the former writes to the alert log before panicking the instance and killing it.  Similarly an ALTER SYSTEM command issued by the server process for our database session will also write to the alert.log .

To find the location of alert log file we can find by below command 
SQL > select value from v$parameter where name = 'background_dump_dest' ;   OR 
SQL> show parameter background

If the background_dump_dest parameter is not specified, Oracle will write the alert.log into the $ORACLE_HOME/RDBMS/trace directory.


Enjoy    :-)



Friday, April 1, 2011

Moving Audit Table Out Of SYSTEM Tablespace


Database auditing is the process of recording, monitoring and reporting of the actions performed on a database. AUD$ is the underlying table that holds all of the system auditing information which resides in SYSTEM tablespace. We keep on deleting and truncating the Aud$ table so that it doesnot grow large. This deleting and truncating of the SYS.AUD$ table will fragment the SYSTEM tablespace. 


Until 11g, the way to move out SYS.AUD$ is not supported. If  we want to do it then we to do it manually . In 11g we can do it by the DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION  provided with the DBMS_MGMT package .So below are the steps .

1.) Connect to database as SYS user.
C:\> sqlplus sys/xxxx@noida  as sysdba

2.) Create a tablespace for audit file as
SQL>create tablespace aud_tbs datafile 'C:\app\Neerajs\oradata\noida/audit.dbf'  size 10M autoextend on ;

3.) Create a table inside aud_tbs tablespace as
SQL> create table aud_tab tablespace aud_tbs  as select * from sys.aud$ where 1=2 ;

4.) Rename the Original Audit table as 
SQL> rename aud$ to aud$_org ;

5.) Rename table  aud_tab  to AUD$
SQL> rename aud_tab  to aud$ ;

Hence, auditing record will be stored in the aud_tbs tablespace .Further, we can create an index on the aud_tbs table for quick access .


Enjoy     :-)