Total Pageviews

Sunday 30 September 2012

LGWR : THE LOG WRITER PROCESS

The LGWR process is responsible for flushing to disk the contents of the redo log buffer located in the SGA. It does this when one of the following is true:
  • Every three seconds
  • Whenever a commit is issued by any transaction
  • When the redo log buffer is one-third full or contains 1MB of buffered data
For these reasons, having an enormous (hundred and thousand megabytes) of redo log buffer is not practical; Oracle will never be able to use it all since it pretty much continuously flushes it.

What is the need of redo log files or LGWR?
The logs are written to with sequential writes as compared to the scattered I/O DBWn must perform .Doing large batch writes like this is much more efficient than doing many scattered writes to various parts of a file. This is one of the main reasons for having a LGWR and redo logs in the first place. The efficiency in just writing out the changed bytes using sequential Input-output outweighs the additional input-output incurred. Oracle could just write database blocks directly to disk when you commit, but that would entail a lot of scattered input-output of full blocks, and this would be significant slower than letting LGWR write the changes out sequentially.

PMON : THE PROCESS MONITOR

1.PMON is responsible for cleaning up after abnormally terminated connections.

What  If your dedicated server “fails” or killed for some reason ?? PMON is the process responsible for fixing and releasing your resources.PMON will perform the below steps :
    • Initiate rollback of uncommitted work
    • Release locks
    • Free SGA resources allocated to the failed process
2.PMON is responsible for monitoring other background processes and restarting them if necessary.
    • What if a shared server or a dispatcher fails ?? PMON is the solution it will step in and restart another dispatcher.
    • What if LGWR or DBWR fails ?? In this case PMON will terminate the instance as LGWR and DBWR are very critical background processes.So PMON will terminate the instance and let normal recovery fix the data.
3. PMON registers the instance with the Oracle TNS Listener: When an instance starts up,the PMON process polls for the well known port address 1521,unless directed otherwise,to check whether  or not a listener is up and running.
  • What if listener is running but not on port 1521: In this case mechanism is same , except that listener address needs to be explicitly specified by the LOCAL_LISTENER parameter setting.
  • What if listener is not started: PMON will periodicall attempts to contact it to register itself. 
  • What if listener is started:If the listener is running when database is started ,PMON communicates with the listener and passes to it relevant parameters,such as the service name and load metrics of the instance.

Thursday 13 September 2012

Restore datafiles to a non-default location !!

You have just experienced a serious media failure and won't be able to restore datafiles to their original locations.In other words you need to restore to a non default location.

Use the set newname and switch commands to restore datafiles to nondefault locations.Both these commands will run from within RMAN run {} block.The below example changes the location of datafiles 4 and 5,which are in the data_ts tablespace.

SQL> set line 300
col file_name for a100
set heading off
select 'set newname for datafile ' || file_id || ' to ''/ora01_new_location/db/ora01_new_location/' ||
substr(file_name,instr(file_name,'/',-1)+1) || ''';'

from dba_data_files;SQL> SQL> SQL>   2    3



RMAN>connect target /
RMAN>startup mount
RMAN> run{
  > set newname for datafile 4 to '/ora01/db/data_file_new_name.dbf';
  > set newname for datafile 5 to /ora01_new_location/db/data_file_name.dbf';
  >restore tablespace data_ts;
  >switch datafile all #Updates repository with new datafile location
  >recover tablespace data_ts;
  >alter database open;
 }

If the database is open you can place the datafile offline and then set their new names for restore and recovery:

RMAN>  run{
  >SQL 'Alter database datafile 4,5 offline';
  > set newname for datafile 4 to '/ora01/db/data_file_new_name.dbf';
  > set newname for datafile 5 to /ora01_new_location/db/data_file_name.dbf';
  >restore datafile 4,5;
  >switch datafile all  # Updates repository with new datafile location
  >recover tablespace data_ts;
  > SQL 'Alter database datafile 4,5 online;
 }




You Lost a particular Datafile ..How to recover !! ?


You have one datafile that has experienced media failure and you want to restore and recover it without restoring the entire tablespace or database.

Scenarion 1: Datafile recovery while database is open

RMAN>Connect target /
RMAN>SQL ‘Alter database datafile 3,4 offline’;
RMAN>Restore datafile 3,4 ;
RMAN>Recover datafile 3,4;
RMAN>Alter database datafile 3,4 online;

Scenarion 2: Datafile recovery while database is not open.

RMAN>Connect target /
RMAN>Startup mount
RMAN>Restore datafile 1 ;
RMAN>Recover datafile 1;
RMAN>Alter database open;

All datafiles of a tablespace goes missing !! what to do ?


You are seeing a media error assosiated with several datafiles cotained in one tablespace.You want to perform a tablespace level recovery:


Scenario 1: Database is open and you want to perform tablespace-level recovery:

·         RMAN >connect target /
·         RMAN>SQL ‘alter tablespace data_ts offline immediate’ ;
·         RMAN>restore tablespace data_ts;
·         RMAN>recover tablespace data_ts;
·         RMAN>SQL ‘Alter tablespace data_ts online’;

Scenario 2: Database is down or mounted and you want to perform tablespace-recovery:

·         RMAN >Connect target /
·         RMAN>startup mount
·         RMAN>restore tablespace data_ts;
·         RMAN>recover tablespace data_ts;
·         RMAN>alter database open;

You Lost all datafiles of the database !! But all your online redo log files are safe !! Now what !?


You must first put your database in mount mode to perform a database-wide restore and recovery.This is because the system tablespace datafile(s) must be offline when beign restored and recovered.Oracle won’t allow you to operate your database in open mode with the system datafile offline.

1.       Perform Database-Level complete recovery with current control file:

RMAN>connect target /
RMAN>Startup Mount;
RMAN>Restore database;
RMAN>Recover database;
RMAN>Alter database open;

2.       Perform Database Level Complete recovery with backed by control file:

RMAN> Connect target /
RMAN> Startup mount
RMAN> Restore control file from autpbackup
RMAN> Alter database mount
RMAN> Restore database
RMAN> Recover database
RMAN> Alter database open resetlogs;

You are required to open your database with the open resetlogs command anytime you use a backup control file during a recovery operation.

Wednesday 12 September 2012

Media Recovery is Required or Not ?

When you start your database, Oracle uses the SCN information in the control files and
datafile headers to determine which one of the following will occur:
  • Starting up normally
  • Performing crash recovery
  • Determining that media recovery is required
On start-up, Oracle checks the instance thread status to determine whether crash recovery is required. When the database is open for normal operations, the thread status is OPEN. When Oracle is shut down normally (normal, immediate, or transactional), a checkpoint takes place, and the instance thread status is set to CLOSED.
When your instance abnormally terminates (such as from a shutdown abort command), the thread status remains OPEN because Oracle didn’t get a chance to update the status to CLOSED. On start-up, when Oracle detects that an instance thread was abnormally left open, the system monitor process will automatically perform crash recovery. This query demonstrates how a single instance of Oracle would determine whether crash recovery is required:

SELECT
a.THREAD#, b.open_mode, a.status,
CASE
WHEN ((b.open_mode='MOUNTED') AND (a.status='OPEN')) THEN 'Crash Recovery req.'
WHEN ((b.open_mode='MOUNTED') AND (a.status='CLOSED')) THEN 'No Crash Rec. req.'
WHEN ((b.open_mode='READ WRITE') AND (a.status='OPEN')) THEN 'Inst. already open'
ELSE 'huh?'
END STATUS
FROM v$thread a,
v$database b,
v$instance c
WHERE a.THREAD# = c.THREAD#;

Oracle will start up normally if the SCN information in the control files matches the SCNs in the corresponding datafiles. If the checkpoint SCN in the datafile is less than the corresponding SCN in the control file, Oracle will throw a media recovery error. For example, if you restored a datafile from a backup, Oracle would detect that the SCN in the datafile is less than the corresponding SCN in the control file. Therefore, a recovery is required to apply changes to the datafile to catch it up to the SCN in the control file.

The following SQL query demonstrates the internal checks that Oracle performs to determine
whether media recovery is required:


SELECT a.NAME,a.checkpoint_change#,b.checkpoint_change#,
CASE
WHEN ((a.checkpoint_change# - b.checkpoint_change#) = 0) THEN 'Startup Normal'
WHEN ((a.checkpoint_change# - b.checkpoint_change#) > 0) THEN 'Media Recovery'
WHEN ((a.checkpoint_change# - b.checkpoint_change#) < 0) THEN 'Old Control File'
ELSE 'what the ?'
END STATUS,
CASE
WHEN ((a.checkpoint_change# - b.checkpoint_change#) = 0) THEN 'No action Required'
WHEN ((a.checkpoint_change# - b.checkpoint_change#) > 0) THEN 'Perform Media Recovery'
WHEN ((a.checkpoint_change# - b.checkpoint_change#) < 0) THEN 'Restore a newer control file'
ELSE 'what the ?'
END DBA_ACTION
FROM v$datafile a, -- control file SCN for datafile
v$datafile_header b -- datafile header SCN
WHERE a.FILE# = b.FILE#;

---The V$DATAFILE_HEADER view uses the physical datafile on disk as its source.
The V$DATAFILE view uses the control file as its source.


Tuesday 11 September 2012

ORA-1652: unable to extend temp segment by 128 in tablespace TEMP

1. Identify temporary datafile details :

SQL> select file_name,TABLESPACE_NAME from DBA_TEMP_FILES;

2. Check if there is any space available in temporary tablespace (segment)


SELECT A.tablespace_name tablespace, D.mb_total,
SUM(A.used_blocks * D.block_size)/1024/1024 mb_used
FROM v$sort_segment A,
(
SELECT B.name, C.block_size, SUM(C.bytes)/1024/1024 mb_total
FROM v$tablespace B, v$tempfile C
WHERE B.ts#= C.ts#
GROUP BY B.name, C.block_size
) D
WHERE A.tablespace_name = D.name
GROUP by A.tablespace_name, D.mb_total;

SQL> select
         ((blocks*8192)+8192)/1024/1024 tblks ,
        s.username||' ('|| sid||','|| serial#||')' userinfo,
                t.piece, t.sql_text
    from v$session s, v$sort_usage u, v$sqltext t
    where s.saddr=u.session_addr
    and s.sql_id(+)=t.sql_id
    order by 1,2,3
    ;

select (s.tot_used_blocks/f.total_blocks)*100 as "percent used"
from (select sum(used_blocks) tot_used_blocks from v$sort_segment where tablespace_name='TEMP') s,
(select sum(blocks) total_blocks from dba_temp_files where tablespace_name='TEMP') f;


3.Fix:

a) Resize temporary file as
SQL> ALTER DATABASE TEMPFILE ‘/u01/oradata/mydb/temp01.dbf’ RESIZE 3072M;

or

b) Add temp datafile to temporary tablespace as

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE ‘/u01/oradata/mydb/temp02.dbf’
SIZE 1024M REUSE AUTOEXTEND ON NEXT 50M MAXSIZE 1024M;

Root Cause Analysis

1. Identify temp segment usages:



SELECT sysdate,a.username, a.sid, a.serial#, a.osuser, (b.blocks*d.block_size)/1048576 MB_used, c.sql_text
FROM v$session a, v$tempseg_usage b, v$sqlarea c,
     (select block_size from dba_tablespaces where tablespace_name='TEMP') d
    WHERE b.tablespace = 'TEMP'
    and a.saddr = b.session_addr
    AND c.address= a.sql_address
    AND c.hash_value = a.sql_hash_value
    AND (b.blocks*d.block_size)/1048576 > 1024
    ORDER BY b.tablespace, 6 desc;



Get 10 sessions with largest temp usage

cursor bigtemp_sids is
select * from (
select s.sid,
s.status,
s.sql_hash_value sesshash,
u.SQLHASH sorthash,
s.username,
u.tablespace,
sum(u.blocks*p.value/1024/1024) mbused ,
sum(u.extents) noexts,
nvl(s.module,s.program) proginfo,
floor(last_call_et/3600)||':'||
floor(mod(last_call_et,3600)/60)||':'||
mod(mod(last_call_et,3600),60) lastcallet
from v$sort_usage u,
v$session s,
v$parameter p
where u.session_addr = s.saddr
and p.name = 'db_block_size'
group by s.sid,s.status,s.sql_hash_value,u.sqlhash,s.username,u.tablespace,
nvl(s.module,s.program),
floor(last_call_et/3600)||':'||
floor(mod(last_call_et,3600)/60)||':'||
mod(mod(last_call_et,3600),60)
order by 7 desc,3)
where rownum < 11;

Thursday 6 September 2012

Using tracefile_identifier oracle 11g

[oracle@DBA-RHEL4-11G ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Sep 6 03:33:01 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show parameter dump_dest;

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest string /home/oracle/apps/diag/rdbms/rep03db/rep03db/trace
core_dump_dest string /home/oracle/apps/diag/rdbms/rep03db/rep03db/cdump
user_dump_dest string /home/oracle/apps/diag/rdbms/rep03db/rep03db/trace

SQL> Alter session set tracefile_identifier='Look_For_Me';

Session altered.

[oracle@DBA-RHEL4-11G trace]$pwd
/home/oracle/apps/diag/rdbms/rep03db/rep03db/trace
[oracle@DBA-RHEL4-11G trace]$ls -l
alert_rep03db.log
rep03db_mman_5712.trc
 rep03db_ora_4387_Look_For_Me.trc
rep03db_w000_4238.trc
rep03db_j000_28983.trm rep03db_mman_5712.trm
rep03db_ora_4387_Look_For_Me.trm
rep03db_w000_4238.trm
rep03db_j000_29752.trm

Tuesday 4 September 2012

Moving Datafile ( NOARCHIVELOG mode )

SQL> select name,bytes,status from v$datafile;

NAME BYTES STATUS
---------- -------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSTEM01.DBF 513802240 SYSTEM
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\UNDOTBS01.DBF 41943040 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSAUX01.DBF 419430400 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\USERS01.DBF 5242880 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\EXAMPLE01.DBF 104857600 ONLINE


SQL> Alter tablespace users offline;

Tablespace altered.

SQL> select name,bytes,status from v$datafile;

NAME BYTES STATUS
---------- -------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSTEM01.DBF 513802240 SYSTEM
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\UNDOTBS01.DBF 41943040 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSAUX01.DBF 419430400 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\NEW\USERS01.DBF 0 OFFLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\EXAMPLE01.DBF 104857600 ONLINE

Now copy the datafile to the new location using OS command or manually and follow the below steps:

SQL>ALTER TABLESPACE USERS RENAME DATAFILE 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\USERS01.DBF' TO 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\NEW\USERS01.DBF';

Tablespace altered.

SQL>
SQL> Alter tablespace users online;

Tablespace altered.

SQL> select name,bytes,status from v$datafile;

NAME BYTES STATUS
---------- -------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSTEM01.DBF 513802240 SYSTEM
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\UNDOTBS01.DBF 41943040 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\SYSAUX01.DBF 419430400 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\NEW\USERS01.DBF 5242880 ONLINE
D:\ORACLE\PRODUCT\10.2.0\ORADATA\DB10G\EXAMPLE01.DBF 104857600 ONLINE

SQL> spool off;

Monday 3 September 2012

Dba_Data_Files,Dba_Segments and Dba_Free_Space

Dba_data_files: The dba_data_files means total size of the data file.
SQL>  Select tablespace_name,sum(bytes)/(1024*1024*1024) from dba_data_files group by tablespace_name order by 1;
This example display the total size of the data file:
SQL> Select sum(bytes)/(1024*1024*1024) from dba_data_files;
---------------------------
526.2392578125

DBA_SEGMENTS: The dba_segments means used size of the data file.
SQL> select tablespace_name,sum(bytes)/(1024*1024*1024) from dba_segments group by tablespace_name order by 1;
This example display the total size of the segments:
SQL> select sum(bytes)/(1024*1024*1024) from dba_segments;
SUM(BYTES)/(1024*1024*1024)
---------------------------
279.55779

DBA_FREE_SPACE: The dba_free_space means free size of the data file.
SQL> select tablespace_name,sum(bytes)/(1024*1024*1024)from dba_free_space group by tablespace_name order by 1;
This example display the total size of the free space:
SQL> select sum(bytes)/(1024*1024*1024) from dba_free_space;
SUM(BYTES)/(1024*1024*1024)
---------------------------
246.29922

DBA_DATA_FILES = DBA_SEGMENTS + DBA_FREE_SPACE + Oracle overhead (header, bitmap... in few KBs)


Reducing RMAN Incremental Backup Time (CTWR:Change tracking writer)

Implement RMAN's block change tracking feature to reduce the time it takes to make an RMAN incremental backup.
Use the following commands to create a change tracking file in the specified location .If you leave out the location ,RMAN creates the block change tracking file in the location specified by the db_create_file_dest initialization parameter:
  • Alter system set db_create_file_dest='/u01/app/oracle/dfiles' scope=both;
  • Alter database enable block change tracking;
If you want , you can create the block changing file in a location you specify, as shown below:
  • Alter database enable block change tracking using file '/u01/app/oracle/dfiles/change_track.txt';
View V$BLOCK_CHANGE_TRACKING shows whether change tracking is enabled and other details of the change tracking file.

How block change tracking works:

RMAN uses a binary file refereed as block change tracking file to record the changed blocks in each datafile in the database .When you perform an incremental backup,RMAN refers to this change tracking file instead of scanning all the data blocks in all the data-files in the database,thus making the incremental backup finish faster.

How to move the change tracking file to a different location:
  • Determine the current location of the block change tracking file using: Select filename from  v$block_change_tracking;
  • Shutdown the database  SQL> Shu immediate
  • Move the file to the new location using the operating system command: $ mv /u01/app/oracle/dfiles/change_trac.txt   /u01/app/newdestination/change_track.txt
  • 4.Start up the database in mount  SQL>startup mount;
  • 5.Use the alter database rename command: Alter database rename file ' /u01/app/oracle/dfiles/change_trac.txt'  to  ' /u01/app/newdestination/change_track.txt'
  • 6.Open the database SQL> Alter database open;
If you can't shutdown the database for some reasons,you have to first change tracking and then re-enable it after you rename the change tracking file as shown below:
  • Alter database disable block change tracking
  • Alter database enable block change tracking using file '/u10/app/newdestination/change_track.txt'
As a result of directing output to the new file without shutting down the database,you will lose the contents of the original change tracking file.

Size of the change tracking file:

The size of the change tracking file is not proportional to the number of updates in the database.Instead the size of the file depends on how large the database is,the number of data-files and how many threads of redo are enabled.Initially the file starts with a size of 10MB and grows in 10MB increments.Since RMAN allocates 320KB space in the change tracking file per datafile, a database with very large number of datafiles would require a large allocation of space for the change tracking file than a database with a smaller number of datafiles