Jul042013.doc

Jul042013What is Oracle RAC Node EvictionWhat is Oracle RAC Node Eviction

One of the most common and complex issue is node eviction issue. A node is evicted from the cluster after it kills itself because it is not able to

service the applications.

This generally happens during the communication failure between the instances, when the instance is not able to send heartbeat information to the

control file and various other reasons.

Oracle Clusterware is designed to perform a node eviction by removing one or more nodes from the cluster if some critical problem is detected. A

critical problem could be a node not responding via a network heartbeat, a node not responding via a disk heartbeat, a hung or severely degraded machine, or

a hung ocssd.bin process. The purpose of this node eviction is to maintain the overall health of the cluster by removing bad members.

During failures, to avoid data corruption, the failing instance evicts itself from the cluster group. The node eviction process is reported as

Oracle error ORA-29740 in the alert log and LMON trace files.

Consolidated AWR report for RAC11gR2 consolidated AWR report for RAC

awrgrpt.sqlThis is a cluster wide awr report, so you can see a lot of the information from all the nodes in the same section, and you can also see aggregated statistics from all the instances at the same time (You can see totals, averages and standard deviations).

awrgdrpt.sqlThis is a cluster wide stats diff report (like you had awrddrpt.sql in 11gr1), comparing the stats differences between two different snapshot intervals, across all nodes in the cluster.

ar282013basic rman commands1. All Backup Sets, Backup Pieces, and Proxy Copies

To list all backup sets, backup pieces, and proxy copies:

RMAN> list backup;

2. Expired Backup List

We can also specify the EXPIRED keyword to identify those backups that were not found during a crosscheck:

RMAN> list expired backup;

3. List Backup by File

You can list copies of datafiles, control files, and archived logs. Specify the desired objects with the listObjList or recordSpec clause. If you do not specify an object, then RMAN displays copies of all database files and archived redo logs. By default, RMAN lists backups in verbose mode, which means that it provides extensive, multiline information.

RMAN> list backup by file;

4. List all Archived Log Files

You can list all archived log files as follows

RMAN> list archivelog all;

5. Summary ListsBy default the LIST output is highly detailed, but you can also specify that RMAN display the output in summarized form. Specify the desired objects with the listObjectList or recordSpec clause. If you do not specify an object, then LIST BACKUP displays all backups. By default, RMAN lists backups in verbose mode.

RMAN> list backup summary;

Dec092012Difference between Raw Device and Block DeviceDifference between Raw Device and Block Device

A RAW Device read/write 0 or more bytes, in a stream and can be opened using Direct I/O. RAW devices can be faster for certain applications like databases because they does not contain a file system, and they dont use cache for the same reason. You dont mount a RAW device.

A BLOCK device would read/write bytes in fixed size blocks, as in disk sectors. The block device is cached. I/O to the device is read into memory, referred to as buffer cache, in large blocks.The block devices are used to mount filesystems. Each disk has a block device interface where the system makes the device byte addressable and you can write a single byte in the middle of the disk.

262012ORA-00354: corrupt redo log block headerORA-00354: corrupt redo log block header

Issue :Normal users could not connect to database.It messaged ORA-00257 :Connect Internal Only until freed.Whenever you try to archive the redo log it returns the message.

ORA-16038: log %s sequence# %s cannot be archivedORA-00354: corrupt redo log block headerORA-00312: online log %s thread %s: %s

Cause:

At alert log you will see the ORA-16038,ORA-00354,ORA-00312 error serial.The error produced as because it failed to archive online redolog due to a corruption in the online redo file.

Solution of The problem:

Making your database running by clear the unarchived redo log.SQL>select * from v$log;This will show you some log is not Archived. It may be the corrupted redo log. We should clear it by unarchive it.

SQL>alter database clear unarchived logfile logilename;

This makes the corruption disappear which causes the contents of the cleared online redo file.

Try to switch the log and confirm it is working fine.

If not then you may have to recreate a redo log for that group only.

Make a complete backup of the database.

252012How to stop and start cluster including ASM and DBLet us say we have two Node

Node 1: operation to stop the CRS

# crsctl stop crs

# crsctl status resources -t

Node 2: Operation to stop the CRS

# crsctl stop crs

# crsctl status resources -t

Confirm the following logs that both nodes related all services are stopped without any problem.

1. $GRID_HOME/log//gipcd/gipcd.log

2. $GRID_HOME/log//agent/ohasd/orarootagent_root/orarootagent_root.log

3. $GRID_HOME/log//hostnamealert.log

4. $GRID_HOME/log//ohasd/ohasd.log

While start the services please make sure you start the CRS of Node 1 first when you run on 11g Rel2 11.2.0.2. If you do start the Second node you may get error and not able to start the ASM with LMON failed status which leads few more error.

When you do deep analysis you may find the private IP assigned to these get assigned with 169.x.x.x which leads

- Snip from ASM Log

Private Interface eth1:1 configured from GPnP for use as a private interconnect.

[name=eth1:1, type=1, ip=169.254.85.248

looks like it is a bug (Oracle Note id 1374360.1 and Bug# 12425730)

Create SR with Oracle and apply the patch accordingly.

We have work around for this is make sure you stop and start the Nodes in the sequence of you stopped.

032012detecting whos causing excessive redo generationSolution I AWR Report:

The first solution that comes in our mind is to go through AWR report for DBA_HIST_SESSMETRIC_HISTORY view. Oracle DBA_HIST_SESSMETRIC_HISTORY displays the history of several important session metrics and we hope to get clue to our problem by analyzing the metrics of past sessions. Unfortunately sometimes we find no rows after querying the view.

Solution II Enabling Oracle Session History Metrics in DBCONSOLE:

This solution suggests you to enable Oracle Session History Metrics in DBCONSOLE. You can set a small value of Redo Writes per second.

Solution III Calculating Metric for Redo Generated:

If you are not using Enterprise Manager then you will have to calculate the metric information manually. You can calculate the metric for Redo Generated per second with the formula DeltaRedoSize / Seconds where DeltaRedoSize is the difference in select value from v$sysstat where name=redo size between end and start of sample period and Seconds is the number of seconds in sample period.

Solution IV Querying Oracle V$SESS_IO View:

When undo is generated in any transaction then it will automatically generate redo as well. This solution examines the amount of undo generated in order to find the sessions that are generating lots of redo.

Oracle V$SESS_IO view lists I/O statistics for each user session. The column BLOCK_CHANGES shows the number of blocks changed by the session. High value for this column means your session is generating lots of redo. You will have to run below query multiple times and examine the delta between each occurrence of BLOCK_CHANGES. If you get large deltas then it shows high redo generation by the session. You use this solution to check for programs that are generating lots of redo when these programs activate more than one transaction.

SQL> SELECT S1.SID, S1.SERIAL_NUM, S1.USER_NAME, S1.PROGRAM, I1.BLOCK_CHANGESFROM V$SESSION S1, V$SESS_IO I1 WHERE S1.SID = I1.SID ORDER BY 5 DESC, 1, 2, 3, 4;

Solution V Querying Oracle V$TRANSACTION View:

Oracle V$TRANSACTION is a Data Dictionary view that lists the active transactions in the system. This view can be used to track undo by session. The USED_UBLK column of this view shows the number of undo blocks used and the USED_UREC column shows the number of undo records used by the transaction.

Below query can help you find out the particular transactions that are generating redo. Running the query multiple times and analyzing the delta between each occurrence of USED_UBLK and SED_UREC will help you infer that large deltas indicate high redo generation by the session.

SQL> SELECT S1.SID, S1.SERIAL_NUM, S1.USER_NAME, S1.PROGRAM, T1.USED_UBLK, T1.USED_URECFROM V$SESSION S1, V$TRANSACTION T1 WHERE S1.TADDR = T1.ADDR ORDER BY 5 DESC, 6 DESC, 1, 2, 3, 4;

Solution VI Tracking Undo Generated By All Sessions:The following statement displays a record for all sessions that have generated undo. It shows both how many undo blocks and undo records a session made.

SELECT S1.SID, S1.USER_NAME, R1.NAME, T1.START_TIME, T1.USED_UBLK , T1.USED_URECFROM V$SESSION S1, V$TRANSACTION T1, V$ROLLNAME R1 WHERE T1.ADDR = S1.TADDR AND R1.USN = T1.XIDUSN;

Solution VII Collecting Statistics from V$SESSTAT to AWR:

Oracle V$SESSTAT view records the statistical data about the session that accesses it. You will have query the V$STATNAME view in order to find the name of the statistic associated with each statistic number. In this solution we will collects statistics from V$SESSTAT view into our private AWR views.

032012Which Sessions Generating more Redo logs in oracle

SELECT s.sid, s.serial#, s.username, s.program,i.block_changesFROM v$session s, v$sess_io iWHERE s.sid = i.sidORDER BY 5 desc;

SELECT s.sid, s.serial#, s.username, s.program,t.used_ublk, t.used_urecFROM v$session s, v$transaction tWHERE s.taddr = t.addrORDER BY 5,6 desc;

Recover Database from ORA-00333: redo log read error

In development environment, it is very common scenario that we have multiple databases in a single machine by using VMware (i.e, each VMware contains one database). Again those machines doesn't have consistant power backup. Therefore we have to face power failure or VMware hang-up. So, we are forced to restart the machine while databases are still up & running. After restarting the machine, we have mostly got he following error:

ORA-00333: redo log read error blockcount.Here are the steps to overcome the error

SQL> startup

ORACLE instance started.

Total System Global Area ***** bytes

Fixed Size ***** bytes

Variable Size ***** bytes

Database Buffers ***** bytes

Redo Buffers ***** bytes

Database mounted.

ORA-00333: redo log read error block *Number* count *Number*Step 1:As the Db is in mount mode, We can query v$log & v$logfile to identify the status of log file group and their member. SQL> select l.status, member from v$logfile inner join v$log l using (group#); STATUS MEMBER

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

CURRENT /oracle/fast_recovery_area/redo01.log

INACTIVE /oracle/fast_recovery_area/redo02.log

INACTIVE /oracle/fast_recovery_area/redo03.logStep 2: Recover the database using ackup controlfile. SQL> recover database using backup controlfile;ORA-00279: change generated at needed for thread 1

ORA-00289: suggestion : /oracle/fast_recovery_area/archivelog/o1_mf_1_634_%u_.arc

ORA-00280: change for thread 1 is in sequence #

Specify log: {=suggested | filename | AUTO | CANCEL}Step3: Give 'CURRENT' log file member along with location as input. If it does not work give other log file members along with location in input prompt. In our casewe give /oracle/fast_recovery_area/redo01.logLog applied.

Media recovery complete.Step 4: Open the database with reset logfileSQL> alter database open resetlogs;Database altered.282011RMAN Show CommandsTheSHOWcommand is used to display the values of current RMAN configuration settings.

RMAN>showall;Shows all parameters.

RMAN>showarchivelog backup copies;Shows the number of archivelog backup copies.

RMAN>showarchivelog deletion policy;Shows the archivelog deletion policy.

RMAN>showauxname;Shows the auxiliary database information.

RMAN>showbackup optimization;Shows whether optimization is on or off.

RMAN>showauxiliary channel;Shows how the normal channel and auxiliary hannel are configured.

RMAN>showcontrolfile autobackup;Shows whether autobackup is on or off.

RMAN>showcontrolfile autobackup format;Shows the format of the autobackup control file.

RMAN>showdatafile backup copies;Shows the number of datafile backup copies being ept.

RMAN>showdefault device type;Shows the default type disk or tape.

RMAN>showencryption algorithm;Shows the encryption algorithm currently in use.

RMAN>showencryption for database;Shows the encryption for the database.

RMAN>showencryption for tablespace;Shows the encryption for the tablespace.

RMAN>showexclude;Shows the tablespaces excluded from the backup.

RMAN>showmaxsetsize;Shows the maximum size for backup sets. The default value is unlimited.

RMAN>showretention policy;Shows the policy for datafile and control file backups and copies that RMAN marks as obsolete.

RMAN>showsnapshot controlfile name;Shows the snapshot control filename.

Note:You can see anynondefault RMAN configured settingsin theV$RMAN_CONFIGURATIONdatabase view.

222011How to find out the Master Node of a RACHowto find out the Master Node of a RACOption1:#ocrconfig-showbackupThe node that store OCR backups is the master node.Option2:$cssd>grep-imaster nodeocssd.log|tail-1[CSSD]CLSS-3001:local node number1,master node number1Abovegrep shows the master node in the cluster is node number1.Option3:$grep master rac3_diag_4217.trcIm the master nodeOption4:Query V$GES_RESOURCE to identified master node.How do I identify the OCR file locationDo simple search for ocr.loc

/var/opt/oracle/ocr.locor/etc/ocr.locor# ocrcheck

How to delete all archive logs in ASMBest option is using RMAN with nocatalog and remove the old archive logs if not required

$ rman nocatalog /

RMAN>delete archivelog all completed before sysdate -3;

How to recover from a DROP or TRUNCATE table by using RMAN.There are three options available:

1. Restore and recover the primary database to a point in time before the drop. This is an extreme measure for one table as the entire database goes back in time.

2. Restore and recover the tablespace to a point in time before the drop. This is a better option, but again, it takes the entire tablespace back in time.

3. Restore and recover a subset of the database as a DUMMY database to export the table data and import it into the primary database. This is the best option as only the dropped table goes back in time to before the drop.

So option 3 is best.

Steps for Option 31. To recover from a dropped or truncated table, a dummy database (copy of primary) will be restored and recovered to point in time so the table can be exported.

2. Once the table export is complete, the table can be imported into the primary database. This dummy database can be a subset of the primary database. However,the dummy database must include the SYSTEM, UNDO (or ROLLBACK), and the tablespace(s) where the dropped/truncated table resides.

The simpliest method to create this dummy database is to use theRMAN duplicate command.

RMAN Duplicate CommandCONNECT TARGET SYS/oracle@trgtCONNECT AUXILIARY SYS/oracle@dupdb

DUPLICATE TARGET DATABASE TO dupdbNOFILENAMECHECK UNTIL TIME SYSDATE-7;

Assuming the following

The target database trgt and duplicate database dupdb are on different hosts but have exactly the same directory structure.

You want to name the duplicate database files the same as the target files.

You are not using a recovery catalog.

You are using automatic channels for disk and sbt, which are already configured.

You want to recover the duplicate database to one week ago in order to view the data in prod1 as it appeared at that time (and you have the required backups and logs to recover the duplicate to that poin tin time).

Difference between locks and latchesLocks are used to protect the data or resourses from the simulteneous use of them by multiple sessions which might set them in inconsistant state Locks are external mechanism, means user can also set locks on objects by using various oracle statements.

Latches are for the same purpose but works at internal level. Latches are used to Protect and control access to internal data structres like various SGA buffers.They are handled and maintained by oracle and we cant access or set it.. this is the main difference

Flashback Database disabled automaticallyIssue 1:Intially Flashback Database was enabled but noticed Flashback was disabled automatically long time ago.

Reason:It could be because the flashback area 100%

Once Flashback Area become 100% full then oracle will log in Alert that Flashback will be disabled and it will automatically turn off Flash Back without user intervention.

ASM LimitationASM Limitation

ASM has the following size limits: 63 disk groups in a storage system 10,000 ASM disks in a storage system 1 million files for each disk group

How can I check if there is anything rolling back?It depends on how you killed the process.

If you did and alter system kill session you should be able to look at the used_ublk block in v$transaciton to get an estimate for the rollback being done.

If you killed to server process in the OS and pmon is recovering the transaction you can look at V$FAST_START_TRANSACTIONS view to get the estimate

RMAN Restore PreviewThe PREVIEW option of the RESTORE command allows you to identify the backups required to complete a specific restore operation. The output generated by the command is in the same format as the LIST command. In addition the PREVIEW SUMMARY command can be used to produce a summary report with the same format as the LIST SUMMARY command. The following examples show how these commands are used:

# Spool output to a log fileSPOOL LOG TO c:oraclermancmdrestorepreview.lst;

# Show what files will be used to restore the SYSTEM tablespaces datafileRESTORE DATAFILE 2 PREVIEW;

# Show what files will be used to restore a specific tablespaceRESTORE TABLESPACE users PREVIEW;

# Show a summary for a full database restoreRESTORE DATABASE PREVIEW SUMMARY;

# Close the log fileSPOOL LOG OFF;

How to Create AWR Report ManuallyStep 1 Create snapshot manuallyexec DBMS_WORKLOAD_REPOSITORY.create_snapshot();Step 2 Create AWR Report$cd $ORACLE_HOME$cd rdbms$cd admin$sqlplus /nologSQL>connect / as sysdbaSQL>@awrrpt.sql..Enter value for begin_snap: 1405..Enter value for end_snap: 1406..Enter value for report_name:awrrpt_1_10405_10406.html

http://www.bestremotedba.com/topics/database-administration/page/7/ADDM(Automatic Database Diagnostic Monitor) in Oracle Database 10gThe Automatic Database Diagnostic Monitor (ADDM) analyzes data in the Automatic Workload Repository (AWR) to identify potential performance bottlenecks. For each of the identified issues it locates the root cause and provides recommendations for correcting the problem.

An ADDM analysis is performed every time an AWR snapshot is taken and the results are saved in the database provided the STATISTICS_LEVEL parameter is set to TYPICAL or ALL.

The ADDM analysis includes:

CPU bottlenecksUndersized Memory StructuresI/O capacity issuesHigh load SQL statementsHigh load PL/SQL execution and compilation, as well as high load Java usageRAC specific issuesSub-optimal use of Oracle by the applicationDatabase configuration issuesConcurrency issuesHot objects and top SQL for various problem areas

ADDM analysis results are represented as a set of FINDINGs

Example ADDM ReportFINDING 1: 31% impact (7798 seconds)SQL statements were not shared due to the usage of literals. This resulted in additional hard parses which were consuming significant database time.

RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)

ACTION: Investigate application logic for possible use of bind variablesinstead of literals. Alternatively, you may set the parameter cursor_sharing to force.

RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found to be using literals. Look in V$SQL for examples of such SQL statements.

In this example, the finding points to a particular root cause, the usage of literals in SQL statements, which is estimated to have an impact of about 31% of total DB time in the analysis period.

In addition to problem diagnostics, ADDM recommends possible solutions. When appropriate, ADDM recommends multiple solutions for the DBA to choose from. ADDM considers a variety of changes to a system while generating its recommendations.

Recommendations include:

Hardware changesDatabase configurationSchema changesApplication changesUsing other advisors

ADDM SettingsAutomatic database diagnostic monitoring is enabled by default and is controlled by the STATISTICS_LEVEL initialization parameter.The STATISTICS_LEVEL parameter should be set to the TYPICAL or ALL to enable the automatic database diagnostic monitoring.The default setting is TYPICAL.Setting STATISTICS_LEVEL to BASIC disables many Oracle features, including ADDM, and is strongly discouraged.

ADDM analysis of I/O performance partially depends on a single argument, DBIO_EXPECTED

The value of DBIO_EXPECTED is the average time it takes to read a single database block in microseconds. Oracle uses the default value of 10 milliseconds

Set the value usingEXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER(ADDM, DBIO_EXPECTED, 8000);

Diagnosing Database Performance Issues with ADDMTo diagnose database performance issues, ADDM analysis can be performed across any two AWR snapshots as long as the following requirements are met:

Both the snapshots did not encounter any errors during creation and both have not yet been purged.

There were no shutdown and startup actions between the two snapshots.

Using Enterprise ManagerThe obvious place to start viewing ADDM reports is Enterprise Manager. The Performance Analysis section on the Home page is a list of the top five findings from the last ADDM analysis task.

Specific reports can be produced by clicking on the Advisor Central link, then the ADDM link. The resulting page allows you to select a start and end snapshot, create an ADDM task and display the resulting report by clicking on a few links.

Executing addmrpt.sql ScriptThe addmrpt.sql script can be used to create an ADDM report from SQL*Plus. The script is called as follows:

@/u01/app/oracle/product/10.1.0/db_1/rdbms/admin/addmrpt.sql

It then lists all available snapshots and prompts you to enter the start and end snapshot along with the report name.

Using DBMS_ADVISOR PackageThe DBMS_ADVISOR package can be used to create and execute any advisor tasks, including ADDM tasks. The following example shows how it is used to create, execute and display a typical ADDM report:

BEGIN Create an ADDM task.DBMS_ADVISOR.create_task (advisor_name => ADDM,task_name => 970_1032_AWR_SNAPSHOT,task_desc => Advisor for snapshots 970 to 1032.);

Set the start and end snapshots.DBMS_ADVISOR.set_task_parameter (task_name => 970_1032_AWR_SNAPSHOT,parameter => START_SNAPSHOT,value => 970);

DBMS_ADVISOR.set_task_parameter (task_name => 970_1032_AWR_SNAPSHOT,parameter => END_SNAPSHOT,value => 1032);

Execute the task.DBMS_ADVISOR.execute_task(task_name => 970_1032_AWR_SNAPSHOT);END;/

Display the report.SET LONG 100000SET PAGESIZE 50000SELECT DBMS_ADVISOR.get_task_report(970_1032_AWR_SNAPSHOT) AS reportFROM dual;SET PAGESIZE 24The value for the SET LONG command should be adjusted to allow the whole report to be displayed.

The relevant AWR snapshots can be identified using the DBA_HIST_SNAPSHOT view.

ADDM ViewsDBA_ADVISOR_TASKS

This view provides basic information about existing tasks, such as the task Id, task name, and when created.

DBA_ADVISOR_LOG

This view contains the current task information, such as status, progress, error messages, and execution times.

DBA_ADVISOR_RECOMMENDATIONS

This view displays the results of completed diagnostic tasks with recommendations for the problems identified in each run. The recommendations should be looked at in the order of the RANK column, as this relays the magnitude of the problem for the recommendation. The BENEFIT column gives the benefit to the system you can expect after the recommendation is carried out.

DBA_ADVISOR_FINDINGS

This view displays all the findings and symptoms that the diagnostic monitor encountered along with the specific recommendation

Bigfile Tablespaces in Oracle 10gBigfile tablespacesare tablespaces with a single large datafile.

In contrastnormal (smallfile) tablespacescan have several datafiles, but each is limited in size.

The system default is to create a smallfile tablespace.The SYSTEM and SYSAUX tablespace types are always created using the system default type.

Bigfile tablespaces must belocally managed

with automatic segment-space management

Exceptions to this rule includetemporary tablespaces and

locally managed undo tablespaces which are all allowed to have manual segment-space management.

Advantages of using Bigfile Tablespaces:By allowing tablespaces to have a single large datafile the total capacity of the database is increased. An Oracle database can have a maximum of 64,000 datafiles which limits its total capacity.It allows you to create a bigfile tablespace of up to eight exabytes (eight million terabytes) in size, and significantly increase the storage capacity of an Oracle database

Using fewer larger datafiles allows the DB_FILES and MAXDATAFILES parameters to be reduced, saving SGA and controlfile space.

It simplifies large database tablespace management by reducing the number of datafiles needed.

The ALTER TABLESPACE syntax has been updated to allow operations at the tablespace level, rather than datafile level.

Considerations:Bigfile Tablespace can be used with:

ASM (Automatic Storage Management)a logical volume manager supporting striping/RAID

Avoid creating bigfile tablespaces on a system that does not support striping because of negative implications for parallel execution and RMAN backup parallelization.

Avoid using bigfile tablespaces if there could possibly be no free space available on a disk group, and the only way to extend a tablespace is to add a new datafile on a different disk group.

Syntax to create Bigfile TablespaceSQL > CREATE BIGFILE TABLESPACEDATAFILE /u01/oradata/datafilename.dbf SIZE 50G

Views:The following views contain a BIGFILE column that identifies a tablespace as a bigfile tablespace:

DBA_TABLESPACESUSER_TABLESPACESV$TABLESPACE

Major RAC Wait EventsIn a RAC environment the buffer cache is global across all instances in the cluster and hence the processingdiffers.The most common wait events related to this are gc cr request and gc buffer busy

GC CR request: the time it takes to retrieve the data from the remote cache

Reason: RAC Traffic Using Slow Connection or Inefficient queries (poorly tuned queries will increase the amount of data blocksrequested by an Oracle session. The more blocks requested typically means the more often a block will need to be read from a remote instance via the interconnect.)

GC BUFFER BUSY: It is the time the remote instance locally spends accessing the requested data block.

SRVCTLsrvctl start instance -d db_name -i inst_name_list [-o start_options]srvctl stop instance -d name -i inst_name_list [-o stop_options]srvctl stop instance -d orcl -i orcl3,orcl4 -o immediatesrvctl start database -d name [-o start_options]srvctl stop database -d name [-o stop_options]srvctl start database -d orcl -o mount

RAC|Aarthi Mudhalvan|Comments (0)rac,SRVCTLApr092010Oracle clusterware toolsOIFCFG allocating and deallocating network interfacesOCRCONFIG Command-line tool for managing Oracle Cluster RegistryOCRDUMP Identify the interconnect being usedCVU Cluster verification utility to get status of CRS resources

RAC|Aarthi Mudhalvan|Comments (0)Oracle clusterware tools,racApr072010OCROracle clusterware manages CRS resources based on the configuration information of CRS resources stored in OCR(Oracle Cluster Registry).

RAC|Aarthi Mudhalvan|Comments (0)OCR,Oracle Cluster Registry,racApr072010CRS ResourceOracle clusterware is used to manage high-availability operations in a cluster.Anything that Oracle Clusterware manages is known as a CRS resource.Some examples of CRS resources are database,an instance,a service,a listener,a VIP address,an application process etc.

FANFast application Notification as it abbreviates to FAN relates to the events related to instances,services and nodes.This is a notification mechanism that Oracle RAc uses to notify other processes about the configuration and service level information that includes service status changes such as,UP or DOWN events.Applications can respond to FAN events and take immediate action.

FAN UP and DOWN events:FAN UP and FAN DOWN events can be applied to instances,services and nodes.

Use of FAN events in case of a cluster configuration change:During times of cluster configuration changes,Oracle RAC high availability framework publishes a FAN event immediately when a state change occurs in the cluster.So applications can receive FAN events and react immediately.This prevents applications from polling database and detecting a problem after such a state change.

How do we verify that RAC instances are running?Issue the following query from any one node connecting through SQL*PLUS.$connect sys/sys as sysdba

SQL>select * from V$ACTIVE_INSTANCES;The query gives the instance number under INST_NUMBER column,host_:instancename under INST_NAME column.

RAC|Aarthi Mudhalvan|Comments (0)verify the RAC instances are running,verify whether RAC instances are runningMar262010VIPVIP Virtual IP address in RAC

VIP is mainly used for fast connection in failover.

Until 9i RAC faileover we used physical IP address of another server. When the connection request come from a client to server, then failure of first server listener then RAC redirect the connection request to second available server using physical IP address. Hence it is physical IP address rediretion to second physical IP address is possible only after we get timeout error from First Physical IP address. So connection should wait a while for getting TCP connection timeout.

From RAC 10g we can use the VIP to save connection timeout wait, Because ONS (Oracle Notification Service) maintains communication between each nodes and listeners. Once ONS found any listener down or node down, it will notify another nodes and listeners. While new connection is trying to establish connection to failure node or listener, virtual IP of failure node automatically divert to surviving node. This Process will not wait for TCP/IP timeout event. So new connection will be faster even one listener/node failed.

A virtual IP address or VIP is an alternate IP address that the client connections use instead of the standard public IP address. To configure VIP address, we need to reserve a spare IP address for each node, and the IP addresses must use the same subnet as the public network.

If a node fails, then the nodes VIP address fails over to another node on which the VIP address can accept TCP connections but it cannot accept Oracle connections.

Situations under which VIP address failover happens:-

VIP addresses failover happens when the node on which the VIP address runs fails, all interfaces for the VIP address fails, all interfaces for the VIP address are disconnected from the network.

Significance of VIP address failover:-

When a VIP address failover happens, Clients that attempt to connect to the VIP address receive a rapid connection refused error .They dont have to wait for TCP connection timeout messages.

RAC|Aarthi Mudhalvan|Comments (0)RAC VIP,RAC virtual IP address,vip,virtual IP addressMar242010ORA-13516: AWR Operation failed: INTERVAL Setting is ZERO===== ORA-13516: AWR Operation failed: INTERVAL Setting is ZERO

The above error message is because of the INTERVAL of snapshot setting is Zero. You can change the snapshot setting by using the following command. The below command set the interval to 60 mins

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( INTERVAL=>60 );

Performance|mudhalvan|Comments (0)ORA-13516: AWR Operation failed: INTERVAL Setting is ZEROMar242010How to create AWR Snapshot Manuallyexec DBMS_WORKLOAD_REPOSITORY.create_snapshot();

Performance|mudhalvan|Comments (0)How to create AWR Snapshot ManuallyMar242010Views and Usage Related to AWR and ASH* V$ACTIVE_SESSION_HISTORY Displays the active session history (ASH) sampled every second.* V$METRIC Displays metric information.* V$METRICNAME Displays the metrics associated with each metric group.* V$METRIC_HISTORY Displays historical metrics.* V$METRICGROUP Displays all metrics groups.* DBA_HIST_ACTIVE_SESS_HISTORY Displays the history contents of the active session history.* DBA_HIST_BASELINE Displays baseline information.* DBA_HIST_DATABASE_INSTANCE Displays database environment information.* DBA_HIST_SNAPSHOT Displays snapshot information.* DBA_HIST_SQL_PLAN Displays SQL execution plans.* DBA_HIST_WR_CONTROL Displays AWR settings.

How to Change the Session and Process ValueHow to Change the Session and Process Value

1. backup the spfile$cp -p spfile.ora spfile.ora.

2. check the session and parameter value$ sqlplus /nologSQL> connect / as sysdbaSQL>select NAME, VALUE from v$parameter where NAME = sessions;SQL>select NAME, VALUE from v$parameter where NAME = processes;

3. Change the Process and Session ValuesSQL> alter system set processes=100 scope=spfile;SQL> alter system set sessions=100 scope=spfile;

4. Restart the DatabaseSQL> shutdown immediate;SQL> startup;

5. check the session and parameter valueSQL>select NAME, VALUE from v$parameter where NAME = sessions;SQL>select NAME, VALUE from v$parameter where NAME = processes;

How do I change archive log to noarchive log in cluster environment?Changing the Archiving Mode in Real Application Clusters

After configuring your Real Application Clusters environment for RMAN, you can alter the archiving mode if needed. For example, if your Real Application Clusters database uses NOARCHIVELOG mode, then follow these steps to change the archiving mode to ARCHIVELOG mode:

1. Shut down all instances.2. Reset the CLUSTER_DATABASE parameter to false on one instance. If you are using the server parameter file, then make a sid-specific entry for this.3. Add settings in the parameter file for the LOG_ARCHIVE_DEST_n, LOG_ARCHIVE_FORMAT, and LOG_ARCHIVE_START parameters. You can multiplex the destination to use up to ten locations. The LOG_ARCHIVE_FORMAT parameter should contain the %t parameter to include the thread number in the archived log file name. You must configure an archiving scheme before setting these parameter values.4. Start the instance on which you have set CLUSTER_DATABASE to false.5. Run the following statement in SQL*Plus:

SQL>ALTER DATABASE ARCHIVELOG;

6. Shut down the instance.7. Change the value of the CLUSTER_DATABASE parameter to true.8. Restart your instances.

You can also change the archiving mode from ARCHIVELOG to NOARCHIVELOG. To disable archiving, follow the preceding steps with the following changes:

1. Delete the archiving settings that you created in step 3.2. Specify the NOARCHIVELOG keyword in step 5:

ALTER DATABASE NOARCHIVELOG;

RMAN Notes1.1. Where should the catalog be created?The recovery catalog to be used by rman should be created in a seperate database other than the target database. The reason been that the target database will be shutdown while datafiles are restored.

1.2. How do I create a catalog for rman?First create the user rman.

CREATE USER rman IDENTIFIED BY rmanTEMPORARY TABLESPACE tempDEFAULT TABLESPACE toolsQUOTA UNLIMITED ON tools;

GRANT connect, resource, recovery_catalog_owner TO rman;exit

Then create the recovery catalog:-

rman catalog=rman/rmancreate catalog tablespace tools;exit

Then register the database

oracle@debian:~$ rman target=/ catalog=rman/rman@newdb

Recovery Manager: Release 10.1.0.2.0 Production

Copyright (c) 1995, 2004, Oracle. All rights reserved.

connected to target database: TEST (DBID=1843143191)connected to recovery catalog database

RMAN> register database;

database registered in recovery catalogstarting full resync of recovery catalogfull resync complete

NoteIf you try rman catalog=rman/rman and try to register the database it will not work.

NoteWe have 2 Databases here 1 is newdb which is solely for catalog and the other is TEST which is our database on which we want to perform all rman operations.

1.3. How many times does oracle ask before dropping a catalog?The default is two times one for the actual command, the other for confirmation.

1.4. How to view the current defaults for the database.rman> show all;

RMAN> show all2> ;

RMAN configuration parameters are:CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;CONFIGURE BACKUP OPTIMIZATION OFF; # defaultCONFIGURE DEFAULT DEVICE TYPE TO DISK; # defaultCONFIGURE CONTROLFILE AUTOBACKUP OFF; # defaultCONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO %F; # defaultCONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # defaultCONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # defaultCONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # defaultCONFIGURE MAXSETSIZE TO UNLIMITED; # defaultCONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # defaultCONFIGURE SNAPSHOT CONTROLFILE NAME TO /u02/app/oracle/product/10.1.0/db_1/dbs/snapcf_test.f; # default

1.5. Backup the database.RMAN> run{configure retention policy to recovery window of 2 days;backup database plus archivelog;delete noprompt obsolete;}tarting backup at 04-JUL-05current log archivedallocated channel: ORA_DISK_1channel ORA_DISK_1: sid=256 devtype=DISKchannel ORA_DISK_1: starting archive log backupset

1.6. How to resolve the ora-19804 errorBasically this error is because of flash recovery area been full. One way to solve is to increase the space available for flashback database.

sql>ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G; It can be set to K,M or G.rman>backup database;.channel ORA_DISK_1: specifying datafile(s) in backupsetincluding current controlfile in backupsetincluding current SPFILE in backupsetchannel ORA_DISK_1: starting piece 1 at 04-JUL-05channel ORA_DISK_1: finished piece 1 at 04-JUL-05piece handle=/u02/app/oracle/flash_recovery_area/TEST/backupset/2005_07_04/o1_mf_ncsnf_TAG20050704T205840_1dmy15cr_.bkp comment=NONEchannel ORA_DISK_1: backup set complete, elapsed time: 00:00:03Finished backup at 04-JUL-05

Oracle Flashback

After taking a back up resync the database.

Restoring the whole database.

run {shutdown immediate;startup mount;restore database;recover database;alter database open;}

1.7. What are the various reports available with RMANrman>list backup; rman> list archive;

1.8. What does backup incremental level=0 database do?Backup database level=0 is a full backup of the database. rman>>backup incremental level=0 database;

You can also use backup full database; which means the same thing as level=0;

1.9. What is the difference between DELETE INPUT and DELETE ALL command in backup?Generally speaking LOG_ARCHIVE_DEST_n points to two disk drive locations where we archive the files, when a command is issued through rman to backup archivelogs it uses one of the location to backup the data. When we specify delete input the location which was backedup will get deleted, if we specify delete all all log_archive_dest_n will get deleted.

DELETE all applies only to archived logs. delete expired archivelog all;

Chapter 2. RecoveryRecovery involves placing the datafiles in the appropriate state for the type of recovery you are performing. If recovering all datafiles, then mount the database, if recovering a single tablespace or datafile then you can keep the database open and take the tablespace or datafile offline. Perform the required recovery and put them back online.

Put the commands in a rman script .rcv file such as myrman.rcv

run{# shutdown immediate; # use abort if this failsstartup mount;#SET UNTIL TIME Nov 15 2001 09:00:00;# SET UNTIL SCN 1000; # alternatively, you can specify SCNSET UNTIL SEQUENCE 9923; # alternatively, you can specify log sequence numberrestore database;recover database;alter database open;}

Run the myrman.rcv file as :- rman target / @myrman.rcv

After successful restore & recovery immediately backup your database, because the database is in a new incarnation.

ALTER DATABASE open resetlogs; command creates a new incarnation of the database database with a new stream of sequence numbers starting with sequence 1.

Before running RESETLOGS it is a good practice to open the database in read only mode and examining the data contents.

2.1. Simulating media failure.2.1.1. How to simulate media failure and recover a tablespace in the database ?2.1.2. What is the difference between alter database recover and sql*plus recover command?

2.1.1. How to simulate media failure and recover a tablespace in the database ?Firstly create the table in the required tablespace.

CREATE TABLE mytest ( id number(10));

Then insert into the table mytest values(100); execute the insert statement a couple of times but do not commit the results.

Take the tablespace offline, this is possible only if the database is in archivelog mode.

now commit the transaction. by issuing commit.

Now try to bring the tablespace online, at this point you will get the error that datafile 4 needs media recovery.

issue the following command to recover the tablespace, please note that the database itself can remain open.

SQL>recover tablespace users;media recovery completed.

now bring the tablespace online.

SQL>alter tablespace users online;

2.1.2. What is the difference between alter database recover and sql*plus recover command?ALTER DATABASE recover is useful when you as a user want to control the recovery. SQL*PLUS recover command is useful when we prefer automated recovery.

Chapter 3. Duplicate database with control fileWhat are the steps required to duplicate a database with control file?Copy initSID.ora to the new initXXX.ora file. i.e.,

cp $ORACLE_HOME/dbs/inittest.ora $ORACLE_HOME/dbs/initDUP.ora

Edit the parameters that are specific to location and instance:-

db_name = dupinstance_name = dupcontrol_files = change the location to point to dupbackground_dump_dest = change the location to point to dup/bdumpcore_dump_dest = change the location to point to dup/cdumpuser_dump_dest = change the location to point to dup/udumplog_archive_dest_1 = dup/archivedb_file_name_convert = (test, dup)log_file_name_convert = (test, dup)remote_login_passwordfile = exclusive

Actual settings :-

*.background_dump_dest=/u02/app/oracle/admin/DUP/bdump*.compatible=10.1.0.2.0*.control_files=/u02/app/oracle/oradata/DUP/control01.ctl,'/u02/app/oracle/oradata/DUP/control02.ctl,'/u02/app/oracle/oradata/DUP/control03.ctl*.core_dump_dest=/u02/app/oracle/admin/DUP/cdump*.db_block_size=8192*.db_cache_size=25165824*.db_domain=*.db_file_multiblock_read_count=16*.db_name=DUP*.db_recovery_file_dest=/u02/app/oracle/flash_recovery_area*.db_recovery_file_dest_size=2147483648*.dispatchers=(PROTOCOL=TCP) (SERVICE=DUPXDB)*.java_pool_size=50331648*.job_queue_processes=10*.large_pool_size=8388608*.log_archive_dest_1=LOCATION=/u02/app/oracle/oradata/payroll MANDATORY*.open_cursors=300*.pga_aggregate_target=25165824*.processes=250*.shared_pool_size=99614720*.sort_area_size=65536*.undo_management=AUTO*.undo_tablespace=UNDOTBS1*.user_dump_dest=/u02/app/oracle/admin/DUP/udump*.remote_login_passwordfile=exclusive*.db_file_name_convert = (test, dup)*.log_file_name_convert =(test,dup)

Make the directories for the dump destination:-

oracle@debian:/u02/app/oracle/admin/DUP$ mkdir bdumporacle@debian:/u02/app/oracle/admin/DUP$ mkdir cdumporacle@debian:/u02/app/oracle/admin/DUP$ mkdir udump

Make a directory to hold control files, datafiles and such:-

oracle@debian:/u02/app/oracle/oradata/PRD$ cd ..oracle@debian:/u02/app/oracle/oradata$ mkdir DUP

Ensure that the oracle sid is pointing to the right Database. Make an ora password file so that other users can connect too.

export ORACLE_SID=DUP$orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=easypasssqlplus / as sysdbasql>startup nomount;

oracle@debian:/u02/app/oracle/product/10.1.0/db_1/dbs$ sqlplus / as sysdba;

SQL*Plus: Release 10.1.0.2.0 Production on Wed Aug 24 21:05:26 2005


Connected to an idle instance.

SQL> startup nomount;ORACLE instance started.

Total System Global Area 188743680 bytesFixed Size 778036 bytesVariable Size 162537676 bytesDatabase Buffers 25165824 bytesRedo Buffers 262144 bytesSQL>

Check net8 connectivity sqlplus sys/easypass@dup if that goes through successfully then exit. The idea is to check for sql*net connectivity.

if you get ORA-12154: TNS:could not resolve the connect identifier specified then more work needs to be done.DUP =(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = debian)(PORT = 1521))(CONNECT_DATA =(SERVICE_NAME = dup))

$tnsping dupUsed TNSNAMES adapter to resolve the aliasAttempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = debian)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = dup)))OK (0 msec)

Even with this if you are getting ORA-12528: TNS:listener: all appropriate instances are blocking new connections then we have to connect to the auxiliary (the database to be duplicated as / ) and the target database ( source ) with user/pass@teststart duplicating the database. export ORACLE_SID=DUP

rman target sys/easypass@test auxiliary /run{allocate auxiliary channel ch1 type disk;duplicate target database to dup;}

oracle@debian:/u02/app/oracle/product/10.1.0/db_1/network/admin$ rman target sys/kernel@test auxiliary /



RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-00554: initialization of internal recovery manager package failedRMAN-04005: error from target database:ORA-01017: invalid username/password; logon denied

The work around to this is to create a user with dba privileges and connect through that users id .

$export ORACLE_SID=testSQL>grant sysdba to mhg;

oracle@debian:/u02/app/oracle/product/10.1.0/db_1/network/admin$ rman target mhg/mhg@test auxiliary /



connected to target database: TEST (DBID=1843143191)connected to auxiliary database: DUP (not mounted)

oracle@debian:~$ rman target mhg/mhg@test auxiliary / @run.rcv




RMAN> run{2> allocate auxiliary channel c1 type disk;3> duplicate target database to dup;4> }5>using target database controlfile instead of recovery catalogallocated channel: c1channel c1: sid=270 devtype=DISK

Starting Duplicate Db at 24-AUG-05released channel: c1RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of Duplicate Db command at 08/24/2005 21:13:09RMAN-05501: aborting duplication of target databaseRMAN-05001: auxiliary filename /u02/app/oracle/oradata/test/users01.dbf conflicts with a file used by the target database

This error is primarily because the files of the test database are already present, this is a bad thing we have to use db_file_name_convert and long_file_name_convert to overcome these errors.

This is the final run output:-

oracle@debian:~$ rman target mhg/mhg@test auxiliary /




RMAN> @run.rcv

RMAN> run{2> allocate auxiliary channel c1 type disk;3> duplicate target database to dup;4> }using target database controlfile instead of recovery catalogallocated channel: c1channel c1: sid=270 devtype=DISK

Starting Duplicate Db at 24-AUG-05

contents of Memory Script:{set until scn 2150046;set newname for datafile 1 to/u02/app/oracle/oradata/DUP/system2.dbf;set newname for datafile 2 to/u02/app/oracle/oradata/DUP/undotbs01.dbf;set newname for datafile 3 to/u02/app/oracle/oradata/DUP/sysaux01.dbf;set newname for datafile 4 to/u02/app/oracle/oradata/DUP/users01.dbf;restorecheck readonlyclone database;}executing Memory Script

executing command: SET until clause

executing command: SET NEWNAME




Starting restore at 24-AUG-05

channel c1: starting datafile backupset restorechannel c1: specifying datafile(s) to restore from backup setrestoring datafile 00001 to /u02/app/oracle/oradata/DUP/system2.dbfrestoring datafile 00002 to /u02/app/oracle/oradata/DUP/undotbs01.dbf..datafile copy filename=/u02/app/oracle/oradata/DUP/sysaux01.dbf recid=2 stamp=567206656

cataloged datafile copydatafile copy filename=/u02/app/oracle/oradata/DUP/users01.dbf recid=3 stamp=567206656

datafile 2 switched to datafile copyinput datafilecopy recid=1 stamp=567206656 filename=/u02/app/oracle/oradata/DUP/undotbs01.dbfdatafile 3 switched to datafile copyinput datafilecopy recid=2 stamp=567206656 filename=/u02/app/oracle/oradata/DUP/sysaux01.dbfdatafile 4 switched to datafile copyinput datafilecopy recid=3 stamp=567206656 filename=/u02/app/oracle/oradata/DUP/users01.dbf

contents of Memory Script:{Alter clone database open resetlogs;}executing Memory Script

database openedFinished Duplicate Db at 24-AUG-05

RMAN> **end-of-file**

This ends a successful duplication of a database without control file.

Chapter 4. Using rman tocheck logical and physical block corruptionTo generate block corruption you can use the dd unix utilitycaution, it will corrupt your block(s):-$dd if=/dev/null of=/u02/oradata/myrac/anyfile.dbf bs=8192 conv=notrunc seek=10 count=1seek=10 write at block 10, count=1 write to only that blocknow you can run dbv to verify that the blocks are actually corruptand then recover the datafile by using oracles blockrecover command.

export ORACLE_HOME=testrman target /run {allocate channel d1 type disk;backup check logical validate database;release channel d1;}To validatea datafile(s) :-run {allocate channel d1 type disk;backup check logical validate datafile 1,2;release channel d1;}

During this command every block is written to memory and then subsequently rewriten to another portion of the memory, duringthis memory to memory write every block is checked for corruption.RMANs backup command with validate and check logical clause allow to quickly validate for both physical and logical corruption.

Chapter 5. Checking for datafile corruptionA corrupted block requires dropping an object. The message identifies the block in error by file number and block number. The cure has always been to run a query such as: SELECT owner, segment_name, segment_type FROM dba_extents WHERE file_id =ANDBETWEEN block_id AND block_id + blocks 1; whereandwere the numbers from the error message. This query indicates which object contains the corrupted block. Then, depending on the object type, recovery is either straightforward (for indexes and temporary segments), messy (for tables), or very messy (for active rollback segments and parts of the data dictionary). In Oracle 9i Enterprise Edition, however, a new Recovery Manager (RMAN) command, BLOCKRECOVER, can repair the block in place without dropping and recreating the object involved. After logging into RMAN and connecting to the target database, type: BLOCKRECOVER DATAFILE filenumber BLOCK blocknumber; A new view, V$DATABASE_BLOCK_CORRUPTION, gets updated during RMAN backups, and a block must be listed as corrupt for a BLOCKRECOVER to be performed. To recover all blocks that have been marked corrupt, the following RMAN sequence can be used: BACKUP VALIDATE DATABASE; BLOCKRECOVER CORRUPTION LIST; This approach is efficient if only a few blocks need recovery. For large-scale corruption, its more efficient to restore a prior image of the datafile and recover the entire datafile, as before. As with any new feature, test it carefully before using it on a production database.

run {allocate channel ch1 type;blockrecover datafileblock;}

1. What are the steps to start the database from a text control file?1.1. What are the steps required to start a database from text based control file?1.2. Give a complete scenario of backup, delete and restore.1.3. How do I backup archive log?1.4. How do I do a incremental backup after a base backup?1.5. What is ORA-002004 error?1.6. What Information is Required for RMAN TAR?1.7. How To turn Debug Feature on in rman?1. What are the steps to start the database from a text control file?1.1. What are the steps required to start a database from text based control file?1.2. Give a complete scenario of backup, delete and restore.1.3. How do I backup archive log?1.4. How do I do a incremental backup after a base backup?1.5. What is ORA-002004 error?1.6. What Information is Required for RMAN TAR?1.7. How To turn Debug Feature on in rman?

1.1. What are the steps required to start a database from text based control file?ALTER DATABASE BACKUP CONTROLFILE TO /oracle/backup/cf.bak REUSE; or to a file name on the OS. With this command you will get a text based version of your control file. REUSE clause specifies Oracle to overwrite the control files. If we ignore this option Oracle will not overwrite the control file if it is already present in the directory specified by the initSID.ora file.

Start the database in nomount mode. If you have 3 control file entries in pfile / spfile you will get 3 new control files.

Now run the control file script to create your control files.

recover database using backup controlfile until cancel

1.2. Give a complete scenario of backup, delete and restore.Given that you want to take a base level backup, simulate complete failure by removing controlfile, datafile, redo log, archive log, these are the steps to be followed.

First take a base level backup of the database.

backup incremental level=0 database;

Simulate media failure by removing the control file and data file. sqlplus / as sysdba; shutdown immediate; exit; rm control* system*

When we dont have a control file the problem becomes quite complex the reason been that the rman backup information is stored in the control file. So when we dont have the control file we wont have the information about backups. First step should be towards restoring the control file. Fortunately we can do a listing in our flash recovery area and guess which backup piece has the information about our control file. In my box following is the listing on the flash recovery area:-

/u02/app/oracle/flash_recovery_area/TEST/backupset/2005_07_30/o1_mf_ncnn0_TAG20050730T130722_1gqn4jy2_.bkpo1_mf_nnnd0_TAG20050730T130722_1gqmzdjz_.bkpnow I am assuming xxcnn0xxx has the control file information in it.

We have to use a nifty pl/sql program to recover our control file, once it is done successfully then we can go on our merry way using rman to recover the rest of the database.

DECLAREv_devtype VARCHAR2(100);v_done BOOLEAN;v_maxPieces NUMBER;TYPE t_pieceName IS TABLE OF varchar2(255) INDEX BY binary_integer;v_pieceName t_pieceName;BEGIN Define the backup pieces (names from the RMAN Log file)v_pieceName(1) :=/u02/app/oracle/flash_recovery_area/TEST/backupset/2005_07_30/o1_mf_ncnn0_TAG20050730T130722_1gqn4jy2_.bkp;v_maxPieces := 1; Allocate a channel (Use type=>null for DISK, type=>sbt_tape for TAPE)v_devtype := DBMS_BACKUP_RESTORE.deviceAllocate(type=>NULL, ident=>d1); Restore the first Control FileDBMS_BACKUP_RESTORE.restoreSetDataFile; CFNAME mist be the exact path and filename of a controlfile taht was backed-upDBMS_BACKUP_RESTORE.restoreControlFileTo(cfname=>/u02/app/oracle/oradata/test/control01.ctl);dbms_output.put_line(Start restoring ||v_maxPieces|| pieces.);FOR i IN 1..v_maxPieces LOOPdbms_output.put_line(Restoring from piece ||v_pieceName(i));DBMS_BACKUP_RESTORE.restoreBackupPiece(handle=>v_pieceName(i), done=>v_done, params=>null);exit when v_done;END LOOP; Deallocate the channelDBMS_BACKUP_RESTORE.deviceDeAllocate(d1) ;EXCEPTIONWHEN OTHERS THENDBMS_BACKUP_RESTORE.deviceDeAllocate;RAISE;END;/

Pl/SQL completed successfully. I had 3 control files, the above command will restore only one control file so I will do a operating system copy to restore the rest of the control files. cp control01.ctl control02.ctl cp control01.ctl control03.ctl

After control file is restored launch rman and list all the backup information.,

rman target /rman>sql alter database mount;rman>list backup;BS Key Type LV Size Device Type Elapsed Time Completion Time- - - 21 Incr 0 2G DISK 00:02:39 30-JUL-05BP Key: 21 Status: AVAILABLE Compressed: NO Tag: TAG20050730T130722Piece Name: /u02/app/oracle/flash_recovery_area/TEST/backupset/2005_07_30/o1_mf_nnnd0_TAG20050730T130722_1gqmzdjz_.bkp List of Datafiles in backup set 21File LV Type Ckp SCN Ckp Time Name- - - -1 0 Incr 1723296 30-JUL-05 /u02/app/oracle/oradata/test/system2.dbf2 0 Incr 1723296 30-JUL-05 /u02/app/oracle/oradata/test/undotbs01.dbf3 0 Incr 1723296 30-JUL-05 /u02/app/oracle/oradata/test/sysaux01.dbf4 0 Incr 1723296 30-JUL-05 /u02/app/oracle/oradata/test/users01.dbf

The above command indicates that the backup set key is 21 and tag is blah and time is blah.

Connect to rman target / restore database; recover database; exit;

sqlplus / as sysdba; startup; Now the database should have been recovered to your current SCN at which time we encountered a complete media failure.

1.3. How do I backup archive log?In order to backup archivelog we have to do the following:-

run {backup(archivelog all delete input);}

If you want to delete archive logs ignoring those that were inaccesible after backup you have to use (archivelog all skip inaccessible delete input);

1.4. How do I do a incremental backup after a base backup?RMAN> backup incremental level=1 database plus archivelog delete all input;

This will take a incremental backup of the database and make a copy of archivelog and delete all input.

1.5. What is ORA-002004 error?A disk I/O failure was detected on reading the controlfile.

Basically check whether the control file is available, permissionsare right on the control file,spfile/init.ora right to the right location, if all checks weredone still you are getting the error, then from the multiplexedcontrol file overlay on the corrupted one, let us say you havethree control files control01.ctl, control02.ctl and control03.ctland now you are getting errors on control03.ctl then just cp control01.ctlover to control03.ctl and you should be all set.In order to issueALTER DATABASE BACKUP CONTROLFILE TO TRACE;database should be mounted and in our case it is not mounted then the onlyother option available is to restore control file from backup or cp themultiplexed control file over to the bad one.

1.6. What Information is Required for RMAN TAR?Hardware Configuration* The name of the node that hosts the database* The make and model of the production machine* The version and patch of the operating system* The disk capacity of the host* The number of disks and disk controllers* The disk capacity and free space* The media management vendor (if you use a third-party media manager)* The type and number of media management devicesSoftware Configuration* The name of the database instance (SID)* The database identifier (DBID)* The version and patch release of the Oracle database server* The version and patch release of the networking software* The method (RMAN or user-managed) and frequency of database backups* The method of restore and recovery (RMAN or user-managed)* The datafile mount points

You should keep this information both in electronic and hardcopy form. For example, if you save this information in a text file on the network or in an email message, then if the entire system goes down, you may not have this data available.

1.7. How To turn Debug Feature on in rman?run {allocate channel c1 type disk;debug on;}rman>list backup of database;

You will see a output similar toDBGMISC: ENTERED krmkdftr [18:35:11.291]

DBGSQL: EXEC SQL AT TARGET begin dbms_rcvman . translateDataFile (:fno ) ; end ; [18:35:11.291]DBGSQL: sqlcode=0 [18:35:11.300]DBGSQL: :b1 = 1DBGMISC: ENTERED krmkgdf [18:35:11.301]DBGMISC: ENTERED krmkgbh [18:35:11.315]DBGMISC: EXITED krmkgbh with status Not required no flags[18:35:11.315] elapsed time [00:00:00:00.000]DBGMISC: EXITED krmkgdf [18:35:11.315] elapsed time [00:00:00:00.014]DBGMISC: EXITED krmkdftr [18:35:11.315] elapsed time [00:00:00:00.024]DBGMISC: EXITED krmknmtr with status DF [18:35:11.315] elapsed time[00:00:00:00.024]DBGMISC: EXITED krmknmtr with status DFILE [18:35:11.315] elapsed time[00:00:00:00.024]DBGMISC: EXITED krmknmtr with status backup [18:35:11.315] elapsed time[00:00:00:00.024]DBGMISC: krmknmtr: the parse tree after name translation is:[18:35:11.315]DBGMISC: EXITED krmknmtr with status list [18:35:11.316] elapsed time[00:00:00:00.078]DBGMISC: krmkdps: this_reset_scn=1573357 [18:35:11.316]DBGMISC: krmkdps: this_reset_time=19-AUG-06 [18:35:11.316]DBGMISC: krmkdps: untilSCN= [18:35:11.317]

You can always turn debug off by issuing

rman>debug off;To check if flashback is enabled or notselect flashback_on from v$database;

How to rename/move data file in oracleMethod 1 (Easy Method)1) shutdown2) COPY the dbf files where you want them3) startup mount4) alter database rename file orig location to target loc; for each file including system.5) This stated method of moving the redo will work fine6) alter database open7) once everything has been verifed, you can delete the dbf files from their original location

Method 2Moving datafiles of a database: The datafiles reside under /home/oracle/OraHome1/databases/ora9 and have go to /home/oracle/databases/ora9.

SQL> select tablespace_name, substr(file_name,1,70) from dba_data_files;

TABLESPACE_NAME SUBSTR(FILE_NAME,1,70) -SYSTEM /home/oracle/OraHome1/databases/ora9/system.dbfUNDO /home/oracle/OraHome1/databases/ora9/undo.dbfDATA /home/oracle/OraHome1/databases/ora9/data.dbfSQL> select member from v$logfile;

MEMBER/home/oracle/OraHome1/databases/ora9/redo1.ora/home/oracle/OraHome1/databases/ora9/redo2.ora/home/oracle/OraHome1/databases/ora9/redo3.ora

SQL> select name from v$controlfile;

NAME/home/oracle/OraHome1/databases/ora9/ctl_1.ora/home/oracle/OraHome1/databases/ora9/ctl_2.ora/home/oracle/OraHome1/databases/ora9/ctl_3.oraNow, the files to be moved are known, the database can be shut down:

SQL> shutdown

The files can be copied to their destination:$cp /home/oracle/OraHome1/databases/ora9/system.dbf /home/oracle/databases/ora9/system.dbf$cp /home/oracle/OraHome1/databases/ora9/undo.dbf /home/oracle/databases/ora9/undo.dbf$cp /home/oracle/OraHome1/databases/ora9/data.dbf /home/oracle/databases/ora9/data.dbf$cp /home/oracle/OraHome1/databases/ora9/redo1.ora /home/oracle/databases/ora9/redo1.ora$cp /home/oracle/OraHome1/databases/ora9/redo2.ora /home/oracle/databases/ora9/redo2.ora$cp /home/oracle/OraHome1/databases/ora9/redo3.ora /home/oracle/databases/ora9/redo3.ora$cp /home/oracle/OraHome1/databases/ora9/ctl_1.ora /home/oracle/databases/ora9/ctl_1.ora$cp /home/oracle/OraHome1/databases/ora9/ctl_2.ora /home/oracle/databases/ora9/ctl_2.ora$cp /home/oracle/OraHome1/databases/ora9/ctl_3.ora /home/oracle/databases/ora9/ctl_3.ora

The ##A(init.ora,/ora/admin/init_ora.html) file is also copied because it references the control files. I name the copied file just init.ora because it is not in a standard place anymore and it will have to be named explicitely anyway when the database is started up.

$cp /home/oracle/OraHome1/dbs/initORA9.ora /home/oracle/databases/ora9/init.ora

The new location for the control files must be written into the (copied) init.ora file:/home/oracle/databases/ora9/init.oracontrol_files = (/home/oracle/databases/ora9/ctl_1.ora,/home/oracle/databases/ora9/ctl_2.ora,/home/oracle/databases/ora9/ctl_3.ora)$ sqlplus / as sysdba

SQL> startup exclusive mount pfile=/home/oracle/databases/ora9/init.ora

SQL> alter database rename file /home/oracle/OraHome1/databases/ora9/system.dbf to /home/oracle/databases/ora9/system.dbf;

SQL> alter database rename file /home/oracle/OraHome1/databases/ora9/undo.dbf to /home/oracle/databases/ora9/undo.dbf;

SQL> alter database rename file /home/oracle/OraHome1/databases/ora9/data.dbf to /home/oracle/databases/ora9/data.dbf;

SQL> alter database rename file /home/oracle/OraHome1/databases/ora9/redo1.ora to /home/oracle/databases/ora9/redo1.ora;



SQL> shutdown

SQL> startup pfile=/home/oracle/databases/ora9/init.ora

How to Increase Size of Redo Log1. Add new log files (groups) with new size

ALTER DATABASE ADD LOGFILE GROUP

2. Switch with alter system switch log file until a new log file group is in state current

3. Now you can delete the old log fileALTER DATABASE DROP LOGFILE MEMBER

Row chaining and Row MigrationConcepts:There are two circumstances when this can occur, the data for a row in a table may be too large to fit into a single data block. This can be caused by either row chaining or row migration.

Chaining:Occurs when the row is too large to fit into one data block when it is first inserted. In this case, Oracle stores the data for the row in a chain of data blocks (one or more) reserved for that segment. Row chaining most often occurs with large rows, such as rows that contain a column of datatype LONG, LONG RAW, LOB, etc. Row chaining in these cases is unavoidable.

Migration:Occurs when a row that originally fitted into one data block is updated so that the overall row length increases, and the blocks free space is already completely filled. In this case, Oracle migrates the data for the entire row to a new data block, assuming the entire row can fit in a new block. Oracle preserves the original row piece of a migrated row to point to the new block containing the migrated row: the rowid of a migrated row does not change.When a row is chained or migrated, performance associated with this row decreases because Oracle must scan more than one data block to retrieve the information for that row.

o INSERT and UPDATE statements that cause migration and chaining perform poorly, because they perform additional processing.

o SELECTs that use an index to select migrated or chained rows must perform additional I/Os.

Detection:Migrated and chained rows in a table or cluster can be identified by using the ANALYZE command with the LIST CHAINED ROWS option. This command collects information about each migrated or chained row and places this information into a specified output table. To create the table that holds the chained rows,execute script UTLCHAIN.SQL.SQL> ANALYZE TABLE scott.emp LIST CHAINED ROWS;SQL> SELECT * FROM chained_rows;You can also detect migrated and chained rows by checking the table fetch continued row statistic in the v$sysstat view.SQL> SELECT name, value FROM v$sysstat WHERE name = table fetch continued row;NAME VALUE- table fetch continued row 308

Although migration and chaining are two different things, internally they are represented by Oracle as one. When detecting migration and chaining of rows you should analyze carrefully what you are dealing with.

Resolving:o In most cases chaining is unavoidable, especially when this involves tables with large columns such as LONGS, LOBs, etc. When you have a lot of chained rows in different tables and the average row length of these tables is not that large, then you might consider rebuilding the database with a larger blocksize.

e.g.: You have a database with a 2K block size. Different tables have multiple large varchar columns with an average row length of more than 2K. Then this means that you will have a lot of chained rows because you block size is too small. Rebuilding the database with a larger block size can give you a significant performance benefit.o Migration is caused by PCTFREE being set too low, there is not enough room in avoid migration, all tables that are updated should have their PCTFREE set so that there is enough space within the block for updates.You need to increase PCTFREE to avoid migrated rows. If you leave more free space available in the block for updates, then the row will have more room to grow.SQL Script to eliminate row migration : Get the name of the table with migrated rows:ACCEPT table_name PROMPT Enter the name of the table with migrated rows:

Clean up from last executionset echo offDROP TABLE migrated_rows;DROP TABLE chained_rows; Create the CHAINED_ROWS table@/rdbms/admin/utlchain.sqlset echo onspool fix_mig List the chained and migrated rowsANALYZE TABLE &table_name LIST CHAINED ROWS;

Copy the chained/migrated rows to another tablecreate table migrated_rows asSELECT orig.*FROM &table_name orig, chained_rows crWHERE orig.rowid = cr.head_rowidAND cr.table_name = upper(&table_name);

Delete the chained/migrated rows from the original tableDELETE FROM &table_name WHERE rowid IN (SELECT head_rowid FROM chained_rows);

Copy the chained/migrated rows back into the original tableINSERT INTO &table_name SELECT * FROM migrated_rows;

spool off

Tips1. Analyze the table and check the chained count for that particular table8671 Chain Count

analyze table tbl_tmp_transaction_details compute statistics

select table_name,chain_cnt,pct_free,pct_used from dba_tables where table_name=TBL_TMP_TRANSACTION_DETAILS

2. Increase the pctfree size to 30

alter table tbl_tmp_transaction_details pctfree 30

3. Regenerate Report (When rows get updated only we will have Chained rows)

tbl_report_generation_status

begin dbms_job.run(190); end;

4. Analyze the table and check the chained count for that particular table0 Chain Count

analyze table tbl_tmp_transaction_details compute statistics

select table_name,chain_cnt,pct_free,pct_used from dba_tables where table_name=TBL_TMP_TRANSACTION_DETAILS

Note:If we want to do the procedure to delete the chained rows from original table and insert the same again, then we need chained_rows tableTo create chained rows we need to run the utlchain.sql from $ORACLE_HOME/rdbms

Find out the chained rows.

analyze table tbl_tmp_transaction_details list chained count;

The above command will move the chained rows to chained_row tableBased on the rowid in chained_row table we can move those record to temp table and delete those chained rows from original table then insert the same again into original table.

select * from tbl_tmp_transaction_details where rowid=AAAG8DAAGAAAGOKABD:

Oracle Database Architectural Overview (In Depth)Oracle Architectural OverviewThe architecture of Oracle is configured in such a way as to ensure that client requests for data retrieval and modification are satisfied efficiently while maintaining database integrity. The architecture also ensures that, should parts of the system become unavailable, mechanisms of the architecture can be used to recover from such failure and, once again, bring the database to a consistent state, ensuring database integrity. Furthermore, the architecture of Oracle needs to provide this capability to many clients at the same time so performance is a consideration when the architecture is configured.

Oracle Instance-The instance is a combination of a memory structure shared by all clients accessing the data, and a number of background processes that perform actions for the instance as a whole.

The shared memory structure is called the SGA, which stands for System Global Area or Shared Global Area, depending on who you ask. Either term is equally acceptable and the acronym SGA is the most common way to refer to this memory structure.

Oracle also includes a number of background processes that are started when the instance is started. These include the database writer (DBW0), system monitor (SMON), process monitor (PMON), log writer (LGWR), and checkpoint process (CKPT). Depending on the configuration of your instance and your requirements, others may also be started. An example of this is the archiver process (ARC0), which will be started if automatic archiving of log files is turned on.

Oracle Database -The database consists of three types of files. Datafiles, of which there can be many depending on the requirements of the database, are used to store the data that users query and modify. The control file is a set of one or more files that keeps information about the status of the database and the data and log files that make it up. The redo log files are used to store a chronological record of changes to the data in the datafiles.

User Process -The user process is any application, either on the same computer as the database or on another computer across a network that can be used to query the database. For example, one of the standard Oracle query tools is SQL*Plusa user process. Another example of a user process is Microsoft Excel or an Oracle Financials application. Any application that makes use of the database to query and modify data in the database is considered a user process. The user process does not have to come from Oracle Corporation; it only needs to make use of the Oracle database.

Server Process -The server process is a process launched when a user process makes a connection to the instance. The server process resides on the same computer as the instance and database and performs all of the work that the user process requests. As you will find out in more detail later in this chapter, the server process receives requests from the user process in the form of SQL commands, checks their syntax, executes the statements and returns the data to the user process. In a typical Oracle configuration, each user process will have a corresponding server process on the Oracle server to perform all the work on its behalf.

Oracle Instance -As shown earlier in Figure 1-2, the Oracle instance is made up of a shared memory structure (the SGA), which is composed of a number of distinct memory areas. The other part of the instance is the set of background processes, both required and optional, that perform work on the database.

The instance is always associated with one, and only one, database. This means that when an instance is started, the DB_NAME parameter in the Oracle parameter (INIT.ORA) file specifies which database the instance will be connected to, while the INSTANCE_NAME parameter (which defaults to the value of the DB_NAME parameter) specifies the name of the instance. The configuration of the instance is always performed through parameters specified in the INIT.ORA file and one environment variableORACLE_SIDwhich is used to determine which instance to start and perform configuration operations on when on the same server as the database.

One of the main objectives of the instance is to ensure that connections by multiple users to access database data are handled as efficiently as possible. One way it accomplishes this is by holding information in the datafiles in one of its shared memory structuresthe database buffer cacheto allow multiple users reading the same data to retrieve that data from memory instead of disk since access to memory is about a thousand times quicker than access to a disk file.

Another reason that the instance is important is that, when multiple users access Oracle data, allowing more than one to make changes to the same data can cause data corruption and cause the integrity of the data to become suspect. The instance facilitates locking and the ability for several users to access data at the same time.

Note:It is important to remember that a user process, when attempting to access data in the database does not connect to the database but to the instance. When specifying what to connect to from a user process, you always specify the name of the instance and not the name of the database. The instance, in this way, is the gatekeeper to the database. It provides the interface to the database without allowing a user to actually touch the various files that make up the database.System Global Area (SGA) -The SGA is a shared memory structure that is accessed by all processes in order to perform database activity, such as read and write data, log changes to the log files, and keep track of frequently executed code and data dictionary objects. The SGA is allocated memory from the operating system on which the instance is started, but the memory that is allocated to it is managed by various Oracle processes. The SGA is composed of several specific memory structures, as shown earlier in Figure 1-2.

These include:

Shared Pool -The Shared Pool is an area of SGA memory whose size is specified by the INIT.ORA parameter SHARED_POOL_SIZE. The default value for SHARED_POOL_SIZE is 3,000,000 bytes, or just under 3MB in versions of Oracle prior to 8.1.7, and 8,000KB bytes, or just under 8MB in Oracle 8.1.7. The size of the shared pool remains constant while the instance is running and can only be changed by shutting down and restarting the instance, after modifying the value in the INIT.ORA file.

The shared pool is divided into two main areas of memory the data dictionary cache(also called the dictionary cache or row cache) andthe library cache. The data dictionary cache is used to store a cached copy of information on frequently accessed data dictionary objects. The information cached includes the name of the object, permissions granted on the object, dependency information, and so on. The data dictionary cache also includes information on the files that make up the database and what tablespaces they belong to, as well as other important information.

When a server process needs to determine what the name Students refers to, it queries the data dictionary cache for that information and, if the information cannot be found, it reads the information from the datafile where the data dictionary is located and then places it in a cache for others to read. The information in the cache is stored using a least-recently-used (or LRU) algorithm. This means that information that is frequently requested remains in the cache while information that is only occasionally required is brought into the cache and flushed out if space is required to bring other information in.

You cannot manually size the data dictionary cacheOracle does this dynamically and automatically. If more memory is required to cache data dictionary information, which may be the case in a database with many objects, the cache is made larger to accommodate the requests. If the memory is needed by the library cache component of the shared pool, some memory may be freed up and removed from the data dictionary cache.

The other major component of the shared pool is the library cache. The library cache is used to store frequently executed SQL statements and PL/SQL program units such as stored procedures and packages. Storing the parsed statement along with the execution plan for the commands sent to the server in memory allows other users executing the same statement (that is, identical in every way including case of statement text, spaces and punctuation) to reduce the work required by not having to re-parse the code. This improves performance and allows the code to appear to run quicker.

The library cache is broken up into a series of memory structures calledshared SQL areas that store three elements of every command sent to the server: the text of the SQL statement or anonymous PL/SQL block itself, the parse tree or compiled version of the statement, and the execution plan for the statement that outlines the steps to be followed to perform the actions for the SQL statement of PL/SQL block.

Each shared SQL area is assigned a unique value that is based upon the hash calculated by Oracle from the text of the statement, the letters and case thereof in it, spacing, and other factors. Identical statements always hash out to the same value whereas different statements, even returning the same result, hash out to different values. For example, the following two statements use two shared SQL areas because their case is different, though they both return the same information:

SELECT * FROM DBA_USERS;select * from dba_users;

One of the goals for ensuring good performance of the applications accessing data in the database is to share SQL areas by ensuring that the statement returning the same result are identical, thereby allowing each subsequent execution following the first of the same SQL statement to use the execution plan created the first time a command is run. The preceding two statements are considered inefficient because they would need to allocate two shared SQL areas to return the same results. This would consume more memory in the shared pool (once for each statement), as well as cause the server process to build the execution plan each time. Like the data dictionary cache, the library cache also works on an LRU algorithm that ensures that statements that are frequently executed by users remain in the cache while those executed infrequently or just once be aged out when space is required. Also like the data dictionary cache, you cannot specifically size the library cacheOracle sizes it automatically based upon the requirements of the users and statements sent to the server, as well as memory allocated to the shared pool with the SHARED_POOL_SIZE parameter.

Database Buffer Cache -The database buffer cache is used to store the most recently used blocks from the datafiles in memory. Because Oracle does not allow a server process to read data from the database directly before returning it to the user process, the server process always checks to see if a block it needs to read is in the database buffer cache, and, if so, retrieve it from the cache and return the rows required to the user. If the block the server process needs to read is not in the database buffer cache, it reads the block from the datafile and places it in the cache.

The database buffer cache also uses an LRU algorithm to determine which blocks should be kept in memory and which can be flushed out. The type of access can also have an impact on how long a block from the datafile is kept in the cache. If the situation where a block is placed in the cache as a result of an index lookup, the block is placed higher in the list of blocks to be kept in the cache than if it were retrieved as a result of a full table scan, where every block of the table being queried is read. Both placing the datafile blocks in the database buffer cache in the first place, and their importance in being kept there for a long or short period, is designed to ensure that frequently accessed blocks remain in the cache.

The database buffer cache is sized by a couple of Oracle initialization parameters. The INIT.ORA parameter DB_BLOCK_SIZE determines the size, in bytes, of each block in the database buffer cache and each block in the datafile. The value for this parameter is determined when the database is created and cannot be changed. Essentially, each block in the database buffer cache is exactly the same size, in bytes, as each database block in the datafiles. This makes it easy to bring datafile blocks into the database buffer cachethey are the same size. The default for DB_BLOCK_SIZE is 2048KB too small in almost all cases.

The other INIT.ORA parameter that is used to determine the size of the database buffer cache is DB_BLOCK_BUFFERS. This parameter defaults to 50, which is also its minimum value. The total amount of memory that will be used for the database buffer cache is DB_BLOCK_BUFFERS * DB_BLOCK_SIZE. For example, setting DB_BLOCK_BUFFERS to 2,000 when the DB_BLOCK_SIZE is 8,192, allocates 20008192 or 16MB of RAM for the database buffer cache. When sizing the database buffer cache, you need to consider the amount of physical memory available on the server and what the database is being used for. If users of the database are going to make use of full table scans, you may be able to have a smaller database buffer cache than if they frequently accessed the data with index lookups. The right number is always the balance between a sufficiently high number so that physical reads of the datafiles are minimized and not too high a number so that memory problems take place at the operating system level.

Redo Log Buffer -Before a change to a row or the addition or removal of a row from a table in the database is recorded to the datafiles, it is recorded to the redo log files and, even before that, to the redo log buffer. The redo log buffer is essentially a temporary storage area for information to be written to the redo log files.

When a server process needs to insert a row into a table, change a row, or delete a row, it first records the change in the redo log buffer so that a chronological record of changes made to the database can be kept. The information and the size of the information, that will be written to the redo log buffer, and then to the redo log files, depends upon the type of operation being performed. On an INSERT, the entire row is written to the redo log buffer because none of the data already exists in the database, and all of it will be needed in case of recovery. When an UPDATE takes place, only the changed columns values is written to the redo log buffernot the entire row. If a DELETE is taking place, then only the ROWID (unique internal identifier for the row) is written to the redo log buffer, along with the operation being performed. The whole point of the redo log buffer is to hold this information until it can be written to the redo log file. The redo log buffer is sized by the INIT.ORA parameter LOG_BUFFER. The default size depends on the operating system that is being used but is typically four times the largest operating system block size supported by the host operating system. It is generally recommended that the LOG_BUFFER parameter be set to 64KB in most environments since transactions are generally shor

Date post:	18-Dec-2015
Category:	Documents
Upload:	sravankumarthadakamalla
View:	13 times
Download:	5 times

Jul042013.doc

Documents