wideIT

Posts

Contents of a Control file

Every Oracle Database has a control file, which is a small binary file that records the physical structure 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 The control file must be available for writing by the Oracle Database server whenever the database is open. Without the control file, the database cannot be mounted and recovery is difficult. The control file of an Oracle Database is created at the same time as the database. By default, at least one copy of the control file is created during database creation. On some operating systems the default is to create multiple copies. You should create two or more copies of the control file during database creation. You can also create control files later, if you lose control files or want to change particular settings in the control files.

Temporary Tablespaces in ORACLE

Temporary Tablespaces Temporary tablespaces are used for special operations, particularly for sorting data results on disk and for hash joins in SQL. For SQL with millions of rows returned, the sort operation is too large for the RAM area and must occur on disk. The temporary tablespace is where this takes place. Each database should have one temporary tablespace that is created when the database is created. You create, drop and manage tablespaces with create temporary tablespace, drop temporary tablespace and alter temporary tablespace commands, each of which is like it?s create tablespace counterpart. The only other difference is that a temporary tablespace uses temporary files (also called tempfiles) rather than regular datafiles. Thus, instead of using the datafiles keyword you use the tempfiles keyword when issuing a create, drop or alter tablespace command as you can see in these examples: CREATE TEMPORARY TABLESPACE temp TEMPFILE ?/ora01/oracle/oradata/booktst_temp_01.

Background Process in ORACLE Database

Background Process in ORACLE Database Database Writer Process (DBWn) Log Writer Process (LGWR) Checkpoint Process (CKPT) System Monitor Process (SMON) Process Monitor Process (PMON) Recoverer Process (RECO) Job Queue Processes Archiver Processes (ARCn) Queue Monitor Processes (QMNn) Database Writer Process (DBWn) The database writer process (DBWn) writes the contents of buffers to datafiles. The DBWn processes are responsible for writing modified (dirty) buffers in the database buffer cache to disk. Although one database writer process (DBW0) is adequate for most systems, you can configure additional processes (DBW1 through DBW9 and DBWa through DBWj) to improve write performance if your system modifies data heavily. These additional DBWn processes are not useful on uniprocessor systems. When a buffer in the database buffer cache is modified, it is marked dirty. A cold buffer is a buffer that has not been recently used according to the least recently used (LRU) algorith

UNDO in Oracle Database

What Is Undo? Every Oracle Database must have a method of maintaining information that is used to roll back, or undo, changes to the database. Such information consists of records of the actions of transactions, primarily before they are committed. These records are collectively referred to as undo. Undo records are used to: Roll back transactions when a ROLLBACK statement is issued Recover the database Provide read consistency Analyze data as of an earlier point in time by using Oracle Flashback Query Recover from logical corruptions using Oracle Flashback features When a ROLLBACK statement is issued, undo records are used to undo changes that were made to the database by the uncommitted transaction. During database recovery, undo records are used to undo any uncommitted changes applied from the redo log to the datafiles. Undo records provide read consistency by maintaining the before image of the data for users who are accessing the data at the same time that another use

Oracle Instance Start-up Steps

The Startup (nomount) Stage When you issue the startup command, the first thing the database will do is enter the nomount stage. During the nomount stage, Oracle first opens and reads the initialization parameter file (init.ora) to see how the database is configured. For example, the sizes of all of the memory areas in Oracle are defined within the parameter file. After the parameter file is accessed, the memory areas associated with the database instance are allocated. Also, during the nomount stage, the Oracle background processes are started. Together, we call these processes and the associated allocated memory the Oracle instance. Once the instance has started successfully, the database is considered to be in the nomount stage. If you issue the startup command, then Oracle will automatically move onto the next stage of the startup, the mount stage. Starting the Oracle Instance (Nomount Stage) There are some types of Oracle recovery operations that require the d

Types of Backups in RMAN

RMAN is very flexible and it offers many different types of backups. We need to start with a list of backup types: · Full backup: A full backup backs up all data files in the database, block-by-block, a standalone backup with everything you need to recover to the point in time when the full backup was collected. · Level 1 backup: A level 1 backup includes only those blocks that have been changed since the “parent” backup was taken. Remember a parent backup may be either a level 0 or a level 1 backup. · Level 0 backup: A level 0 incremental backup is physically identical to a full backup and it includes every data block in the file except empty blocks. The only difference is that the level 0 backup is recorded as an incremental backup in the RMAN repository, so it can be used as the parent for a level 1 backup. · Incremental backup: An incremental backup can be either level 0 or level 1. There are two types of incremental back