Tuesday, February 27, 2018

Stored outlines vs SQL plan baseline vs SQL PROFILE

Oracle SQL Tuning Features: Stored Outlines, SQL Plan Baselines, and SQL Profiles

Oracle Database provides several powerful features to influence and stabilize SQL execution plans, helping to optimize query performance. This document explains three key features: Stored Outlines, SQL Plan Baselines, and SQL Profiles.

Stored Outlines

Stored Outlines were an earlier mechanism to "freeze" the execution plan for a specific SQL statement.

  • Purpose: To ensure that a particular SQL statement always uses the same execution plan, regardless of changes in statistics, database parameters, or optimizer versions.

  • Limitation: While they freeze a plan, they also prevent the optimizer from generating potentially more beneficial execution plans in the future. This can be a disadvantage if database conditions or data distribution change significantly, and a new, better plan could be generated.

SQL Plan Baseline

SQL Plan Management (SPM), introduced in Oracle Database 11g, provides a more robust and flexible way to manage and evolve SQL execution plans through SQL Plan Baselines.

  • Concept: When SPM is enabled, the optimizer stores generated execution plans in a special repository called the SQL Management Base (SMB). All stored plans for a specific SQL statement form its plan history.

  • Accepted Plans: Some of the plans in the history can be explicitly marked as "accepted." When the SQL statement is re-parsed, the optimizer considers only these accepted plans from the history. This set of accepted plans for that SQL statement is called a SQL plan baseline.

  • Flexibility: With SQL plan management, you can:

    • Examine all available plans in the plan history for a SQL statement.

    • Compare them to see their relative efficiency.

    • Promote a specific plan to "accepted" status.

    • Even make a plan the permanent ("fixed") one, similar to a stored outline but within the SPM framework.

  • Creation Methods: You can create a SQL plan baseline in several ways:

    • Using a SQL Tuning Set (STS).

    • From the cursor cache.

    • Exporting from one database and importing into another.

    • Automatically for every statement (if configured).

  • Evolution: A SQL plan baseline can be "evolved" (meaning new, better plans can be tested and added to the baseline) either by executing the evolve_sql_plan_baseline function (part of DBMS_SPM package) or by using the SQL Tuning Advisor.

  • Querying Baselines: You can view accepted SQL plan baselines using:

    SELECT sql_text, plan_name, enabled, accepted FROM dba_sql_plan_baselines;
    

SQL Profile

A SQL Profile is a set of auxiliary information that the query optimizer uses to enhance its ability to select the best execution plan for a SQL statement.

  • Purpose: The optimizer normally uses inputs like object and system statistics, compilation environment, and bind values to determine the optimal plan. However, in some cases, defects in these inputs or in the optimizer itself can lead to a sub-optimal plan. A SQL profile contains additional, corrective information that mitigates these problems.

  • Functionality: When used together with its regular inputs, a SQL profile helps the optimizer minimize mistakes and thus is more likely to select the best plan. It doesn't "freeze" a plan like an outline or baseline, but rather provides hints and corrections to guide the optimizer's decision-making process.

  • Creation: SQL profiles are typically created by the SQL Tuning Advisor when it identifies a sub-optimal plan for a SQL statement and finds better execution paths.

Tuesday, May 2, 2017

RMAN LEVEL 0 , LEVEL 1 and Arch Backup & restore script [Networker]

Oracle RMAN Backup and Restore Examples

This document provides practical examples of RMAN (Recovery Manager) scripts for performing various backup and restore operations in an Oracle Database environment. These examples cover full database backups, incremental backups, archive log backups, and database restores to a point in time.

RMAN Backup Examples

1. Full/Level 0 Incremental Backup to Tape (SBT_TAPE) with Archive Log Backup and Deletion

This script performs a Level 0 incremental backup of the database, including the current control file, to tape. It then archives the current log, crosschecks existing archive logs, backs up archive logs not yet backed up to tape, and finally deletes archive logs that have been backed up at least once to tape and are older than 1/24th of a day (2.5 minutes).

RUN {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE';
  ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE';

  -- Perform a Level 0 incremental backup of the database
  -- filesperset 1: Each backup set will contain only one datafile.
  -- format: Defines the naming convention for backup pieces.
  -- include current controlfile: Ensures the latest control file is part of the backup.
  backup incremental level 0 filesperset 1 format '%d_LEVEL0_%s_%t_%p.dbf' database include current controlfile;

  -- Force an archive log switch to ensure all committed transactions are in an archive log.
  sql 'alter system archive log current';

  -- Crosscheck archive logs to update their status in the RMAN catalog (e.g., AVAILABLE/EXPIRED).
  change archivelog all crosscheck;

  -- Backup archive logs that have not been backed up at least once to tape.
  backup NOT BACKED UP 1 TIMES archivelog all filesperset 1 format '%d_arch_%s_%t_%p.arc';

  -- Delete archive logs that have been backed up at least once to tape and are older than 2.5 minutes.
  DELETE ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';

  -- Release the allocated channels.
  RELEASE CHANNEL CH1;
  RELEASE CHANNEL CH2;
  RELEASE CHANNEL CH3;
  RELEASE CHANNEL CH4;
}

2. Archive Log Backup and Deletion to Tape (SBT_TAPE)

This script focuses solely on backing up and deleting archive logs to tape. It's often run more frequently than full database backups.

RUN {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE' ;
  ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE' ;

  -- Crosscheck archive logs to update their status in the RMAN catalog.
  change archivelog all crosscheck;

  -- Backup archive logs that have not been backed up at least once to tape.
  backup NOT BACKED UP 1 TIMES archivelog all filesperset 1 format '%d_arch_%s_%t_%p.arc' ;

  -- Delete archive logs that have been backed up at least once to tape and are older than 2.5 minutes.
  -- NOPROMPT: Suppresses the confirmation prompt for deletion.
  DELETE NOPROMPT ARCHIVELOG ALL BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';

  -- Release the allocated channels.
  RELEASE CHANNEL CH1;
  RELEASE CHANNEL CH2;
  RELEASE CHANNEL CH3;
  RELEASE CHANNEL CH4;
}

3. Level 1 Incremental Backup to Disk (Compressed)

This example performs a Level 1 incremental backup (only blocks changed since the last Level 0 or Level 1 backup) to disk, with compression.

run {
  -- Allocate disk channels. Note: Each channel should ideally have a unique format string
  -- if you intend to write to different physical locations or distinct backup pieces.
  -- The example below uses the same format for all, which might overwrite or lead to issues
  -- if not managed carefully (e.g., using %U for unique filenames).
  ALLOCATE CHANNEL backup_disk1 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf';
  ALLOCATE CHANNEL backup_disk2 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name
  ALLOCATE CHANNEL backup_disk3 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name
  ALLOCATE CHANNEL backup_disk4 TYPE DISK FORMAT '/migration/level0_bkp/db_%s_%t_%p.dbf'; -- Corrected channel name

  -- Perform a Level 1 incremental backup.
  -- as compressed backupset: Enables compression for the backup.
  -- filesperset 1: Each backup set contains one datafile.
  -- tag: Assigns a tag to the backup set for easier identification.
  -- include current controlfile: Includes the control file in the backup.
  backup as compressed backupset incremental level 1
  filesperset 1 tag  'TEST_STANDARD_LEVEL1'  database include current controlfile;

  -- Release the allocated channels.
  RELEASE CHANNEL backup_disk1;
  RELEASE CHANNEL backup_disk2; -- Corrected channel name
  RELEASE CHANNEL backup_disk3; -- Corrected channel name
  RELEASE CHANNEL backup_disk4; -- Corrected channel name
}

Correction Note: In the original allocate channel commands for disk backup, all channels were named backup_disk1. For parallel operation, they should be distinct (e.g., backup_disk1, backup_disk2, etc.) and released accordingly. The example above has been corrected for clarity.

RMAN Restore Examples

1. Restoring Control File from Tape (SBT_TAPE)

This script is used to restore the control file from a tape backup. This is typically done when the control file is lost or corrupted, and the database cannot be mounted.

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;

  -- Send environment variables to the media management software (MMS).
  -- NSR_SERVER, NSR_CLIENT, NSR_DATA_VOLUME_POOL are NetWorker specific variables.
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Restore the control file using its backup piece name or tag.
  restore controlfile from 'MYSID_c-569933170-20171012-03'; -- Replace with actual backup piece name/tag

  RELEASE CHANNEL ch1;
}

2. Full Database Restore to a Point in Time (using Shell Script)

This section shows how to automate a full database restore to a specific point in time using a shell script to invoke RMAN.

invoke_restore_MYSID.ksh (Shell Script):

export ORACLE_SID=MYSID # Set the Oracle SID
export ORACLE_HOME=/applic/oracle/product/11.2.0/dbhome_1 # Set the Oracle Home
export PATH=$PATH:$ORACLE_HOME/bin # Add Oracle binaries to PATH

# Execute RMAN, targeting the database, logging output, and using a command file.
rman target / log=MYSID_restore_$(date '+%Y%m%d_%H%M%S').log cmdfile=restore_MYSID.rcv

restore_MYSID.rcv (RMAN Command File for Restore):

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch2 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch4 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch5 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch6 DEVICE TYPE sbt_tape;

  -- Set the point in time for the restore operation.
  set until time "to_date('10/12/2017 15:01:39', 'mm/dd/yyyy hh24:mi:ss')";

  -- Send environment variables to the media management software (MMS).
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Set new names for datafiles if relocating the database or restoring to a different storage.
  -- This example sets all datafiles to an ASM diskgroup named +DATA_DG.
  set newname for database to '+DATA_DG';

  -- Restore the entire database.
  restore database;

  -- Update the control file with the new datafile locations after restore.
  switch datafile all;

  RELEASE CHANNEL ch1;
  RELEASE CHANNEL ch2;
  RELEASE CHANNEL ch3;
  RELEASE CHANNEL ch4;
  RELEASE CHANNEL ch5;
  RELEASE CHANNEL ch6;
}

3. Database Recovery to a Point in Time (using Shell Script)

This script is used after a database restore to apply archive logs and recover the database to the specified point in time.

recover_MYSID.rcv (RMAN Command File for Recover):

run
{
  ALLOCATE CHANNEL ch1 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch2 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch3 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch4 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch5 DEVICE TYPE sbt_tape;
  ALLOCATE CHANNEL ch6 DEVICE TYPE sbt_tape;

  -- Set the point in time for the recovery operation. This must match the restore point.
  set until time "to_date('10/12/2017 15:01:39', 'mm/dd/yyyy hh24:mi:ss')";

  -- Send environment variables to the media management software (MMS).
  send 'NSR_ENV=(NSR_SERVER=*****,NSR_CLIENT=*****,NSR_DATA_VOLUME_POOL=*****)'; -- Replace with actual values

  -- Recover the database by applying necessary archive logs.
  recover database;

  RELEASE CHANNEL ch1;
  RELEASE CHANNEL ch2;
  RELEASE CHANNEL ch3;
  RELEASE CHANNEL ch4;
  RELEASE CHANNEL ch5;
  RELEASE CHANNEL ch6;
}

4. Restore Specific Archive Log Range

This command can be used to restore a specific range of archive logs.

restore archivelog from logseq 330570 until logseq 330590;

This restores archive logs with sequence numbers from 330570 up to (and including) 330590.

Wednesday, February 1, 2017

DBA Daily useful commands

Oracle DBA Quick Reference Queries

This document compiles a set of useful SQL queries and commands for Oracle Database Administrators (DBAs) to monitor, manage, and troubleshoot various aspects of an Oracle database.

RMAN Backup & Restore Status

These queries help monitor the status and details of RMAN backup and restore jobs.

1. RMAN Backup Job Details (Summary)

col START_TIME for a30
col END_TIME for a30
col STATUS format a30
col hrs format 999.99
set linesize 300
select
SESSION_KEY, INPUT_TYPE, STATUS,
to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,
to_char(END_TIME,'mm/dd/yy hh24:mi')   end_time,
elapsed_seconds/3600                   hrs
from V$RMAN_BACKUP_JOB_DETAILS
order by session_key;

2. RMAN Backup Job Details (Size & Duration)

set linesize 150
select SESSION_KEY, INPUT_TYPE,to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,STATUS,to_char(END_TIME,'mm/dd/yy hh24:mi')   end_time,round(elapsed_seconds/60)+1 mins,round(input_bytes/1024/1024/1024) Size_Gigs from V$RMAN_BACKUP_JOB_DETAILS order by session_key;

3. RMAN Backup Status (Disk Incrementals)

set lines 300
select to_char(start_time,'DD/MM/RR HH24:MI:SS') ,to_char(end_time,'DD/MM/RR HH24:MI:SS') ,Input_bytes/(1024*1024*1024),output_bytes/(1024*1024*1024) from v$rman_Status where OUTPUT_DEVICE_TYPE='DISK'and object_type='DB INCR' order by end_time desc;

4. RMAN Output Log

select output
from v$rman_output
where session_recid in (select session_recid from v$rman_status
where start_time > sysdate-2)
order by recid ;

5. RMAN Session Long Operations (Progress)

set linesize 126
column Pct_Complete format 99.99
column client_info format a25
column sid format 999
column MB_PER_S format 999.99
select s.client_info,
l.sid,
l.serial#,
l.sofar,
l.totalwork,
round (l.sofar / l.totalwork*100,2) "Pct_Complete",
aio.MB_PER_S,
aio.LONG_WAIT_PCT
from v$session_longops l,
v$session s,
(select sid,
serial,
100* sum (long_waits) / sum (io_count) as "LONG_WAIT_PCT",
sum (effective_bytes_per_second)/1024/1024 as "MB_PER_S"
from v$backup_async_io
group by sid, serial) aio
where aio.sid = s.sid
and aio.serial = s.serial#
and l.opname like 'RMAN%'
and l.opname not like '%aggregate%'
and l.totalwork != 0
and l.sofar <> l.totalwork
and s.sid = l.sid
and s.serial# = l.serial#
order by 1;

6. RMAN Throughput Calculation

TTITLE OFF
SET HEAD OFF
SELECT 'Throughput: '||
        ROUND(SUM(v.value/1024/1024),1) || ' Meg so far @ ' ||
        ROUND(SUM(v.value      /1024/1024)/NVL((SELECT MIN(elapsed_seconds)
             FROM v$session_longops
             WHERE opname        LIKE 'RMAN: aggregate input'
               AND sofar         != TOTALWORK
               AND elapsed_seconds IS NOT NULL
        ),SUM(v.value      /1024/1024)),2) || ' Meg/sec'
 FROM gv$sesstat v, v$statname n, gv$session s
WHERE v.statistic# = n.statistic#
  AND n.name        = 'physical write total bytes'
  AND v.sid         = s.sid
  AND v.inst_id     = s.inst_id
  AND s.program LIKE 'rman@%'
GROUP BY n.name
/
SET HEAD ON

Data Guard Archive Log Gap Status

Queries to check the synchronization status of a Data Guard standby database.

1. Archive Log Gap (Sequence Difference)

SELECT /*+ rule */ ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received", APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"
FROM
(SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
(SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
WHERE
ARCH.THREAD# = APPL.THREAD#
ORDER BY 1;

2. Managed Standby Processes

SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM GV$MANAGED_STANDBY;

Tablespace Status

Queries to monitor tablespace usage and properties.

1. Tablespace Free Space and Autoextend Info

SELECT d.tablespace_name as name,
NVL (dfs.BYTES, 0) AS freeSp,
NVL (TRUNC (dfs.BYTES / ddf.BYTES * 100, 3), 0) AS avPct,
NVL (dfs.antall, 0) as chunks,
ddf.autoextend_flag as autoext,
NVL (TRUNC ((ddf.maxbytes)), 0) as maxSize,
NVL (TRUNC (  (ddf.BYTES - NVL (dfs.BYTES, 0))/(ddf.maxbytes)*100,3),0) as maxPct
FROM dba_tablespaces d,
(SELECT    tablespace_name, SUM (BYTES) BYTES, COUNT (1) antall FROM dba_free_space GROUP BY tablespace_name) dfs,
(SELECT    tablespace_name, SUM (BYTES) BYTES, SUM (GREATEST (maxbytes, BYTES)) maxbytes, COUNT (1) antall, MAX(autoextensible) autoextend_flag    FROM dba_data_files GROUP BY tablespace_name) ddf
WHERE d.tablespace_name = ddf.tablespace_name(+)
AND d.tablespace_name = dfs.tablespace_name(+)
AND NOT (d.extent_management LIKE 'LOCAL'
AND d.CONTENTS LIKE 'TEMPORARY')
UNION ALL
SELECT LTRIM (d.tablespace_name) as name,
NVL (TRUNC (ddf.BYTES - NVL(dfs.BYTES, 0)), 0) AS freeSp,
NVL (TRUNC ((ddf.BYTES - NVL(dfs.BYTES, 0)) / ddf.BYTES * 100), 0) AS avPct,
DECODE (NVL (TRUNC (((ddf.BYTES - NVL(dfs.BYTES, 0)) / ddf.BYTES) * 100), 0),  0, 1,  100, 0,1) as chunks,
ddf.autoextend_flag as autoext,
NVL (TRUNC ((ddf.maxbytes)), 0) as maxSize,
NVL (TRUNC ((NVL(dfs.BYTES, 0)) / (ddf.maxbytes)* 100,3),0) as maxPct
FROM dba_tablespaces d,
(SELECT    tablespace_name, SUM (BYTES) BYTES, SUM (GREATEST (maxbytes, BYTES)) maxbytes, COUNT (1) antall, MAX(autoextensible) autoextend_flag
             FROM dba_temp_files GROUP BY tablespace_name) ddf,
(SELECT    ss.tablespace_name, SUM ( ss.used_blocks * ts.BLOCKSIZE) BYTES, COUNT (1) antall
             FROM gv$sort_segment ss, SYS.ts$ ts WHERE ss.tablespace_name = ts.NAME GROUP BY ss.tablespace_name) dfs
WHERE d.tablespace_name = ddf.tablespace_name(+)
AND d.tablespace_name = dfs.tablespace_name(+)
AND d.extent_management LIKE 'LOCAL'
AND d.CONTENTS LIKE 'TEMPORARY'
ORDER BY 1;

2. Tablespace Used/Free Space (Simplified)

select df.tablespace_name "Tablespace",
totalusedspace "Used MB",
(df.totalspace - tu.totalusedspace) "Free MB",
df.totalspace "Total MB",
round(100 * ( (df.totalspace - tu.totalusedspace)/ df.totalspace))
"Pct. Free"
from
(select tablespace_name,
round(sum(bytes)/1048576) TotalSpace
from dba_data_files
group by tablespace_name) df,
(select round(sum(bytes)/(1024*1024)) totalusedspace, tablespace_name
from dba_segments
group by tablespace_name) tu
where df.tablespace_name = tu.tablespace_name ;

Temp Tablespace Usage

Query to check the current usage of temporary tablespaces.

SET PAGESIZE 60
SET LINESIZE 300
SELECT
    A.tablespace_name tablespace,
    D.mb_total,
    SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_used,
    D.mb_total - SUM (A.used_blocks * D.block_size) / 1024 / 1024 mb_free
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;

CREATE TABLESPACE / ADD DATAFILE / RESIZE DATAFILE

Commands for managing tablespaces and datafiles.

1. Create Tablespace

CREATE TABLESPACE "My_abs" DATAFILE
SIZE 1073741824
AUTOEXTEND ON NEXT 104857600 MAXSIZE 30720M
LOGGING ONLINE PERMANENT BLOCKSIZE 32768
EXTENT MANAGEMENT LOCAL AUTOALLOCATE DEFAULT
NOCOMPRESS  SEGMENT SPACE MANAGEMENT AUTO;

2. Add Datafile to Tablespace

ALTER TABLESPACE ARCH_data_TS ADD DATAFILE SIZE 10G AUTOEXTEND ON NEXT 100M MAXSIZE 30G;

3. Resize Datafile

ALTER DATABASE DATAFILE '+DATA_DG/ABCP0009EC/DATAFILE/arch_lobs_ts.305.1003252759' resize 30G;

4. Get Tablespace DDL

set long 99999999
select dbms_metadata.get_ddl('TABLESPACE',tb.tablespace_name) from dba_tablespaces tb;

ASM Disk and Diskgroup Size

Queries to monitor Oracle Automatic Storage Management (ASM) disks and diskgroups.

1. ASM Disk Information

col path for a30
set linesize 300
select name,path,os_mb,header_Status from v$ASM_DISK;

2. ASM Disk Information (GV$)

select INST_ID,name,path from gv$ASM_DISk order by name,INST_ID;

3. ASM Diskgroup Size

select name,total_mb/1024,free_mb/1024 from v$ASM_DISKGROUP;

4. Candidate ASM Disks

select name,path,os_mb,header_Status from v$ASM_DISK where header_Status='CANDIDATE';

ASM Rebalance Status

Query to check the status of an ongoing ASM rebalance operation.

set linesize 300
select INST_ID, OPERATION, STATE, POWER, SOFAR, EST_WORK, EST_RATE, EST_MINUTES from GV$ASM_OPERATION ;

DB Directory Name and Path

Query to list all database directory objects and their paths.

set linesize 300
col OWNER for a20
col DIRECTORY_NAME for a20
col DIRECTORY_PATH for a50
select * from  dba_directories;

AWR Interval and Retention Change

Command to modify AWR snapshot settings.

-- Set AWR snapshot interval to 30 minutes and retention to 15 days (21600 minutes)
exec dbms_workload_repository.modify_snapshot_settings(interval => 30, retention => 21600) ;

AWR Manual Snapshot

Command to manually create an AWR snapshot.

EXEC dbms_workload_repository.create_snapshot;

Redo Log Member Size

Query to check the size of redo log members.

SELECT a.group#, a.member, b.bytes FROM v$logfile a, v$log b WHERE a.group# = b.group#;

GATHER_TABLE_STATS & GATHER_SCHEMA_STATS

Examples of gathering optimizer statistics for tables and schemas.

1. Gather Table Statistics

BEGIN
    SYS.DBMS_STATS.GATHER_TABLE_STATS (
    OwnName => 'MyOwner',
    TabName => 'Mytable',
    Estimate_Percent => SYS.DBMS_STATS.AUTO_SAMPLE_SIZE,
    Method_Opt => 'FOR ALL COLUMNS SIZE AUTO',
    Degree => 4,
    Cascade => TRUE
--  ,No_Invalidate=> FALSE -- Uncomment and set to FALSE if you want to invalidate dependent cursors immediately
);
END;
/

2. Gather Schema Statistics

BEGIN
  SYS.DBMS_STATS.GATHER_SCHEMA_STATS (
      OwnName           => 'MyOwner'
    , Granularity       => 'DEFAULT'
    , Estimate_Percent  => SYS.DBMS_STATS.AUTO_SAMPLE_SIZE
    , Method_Opt        => 'FOR ALL COLUMNS SIZE AUTO'
    , Degree            => 4
    , Cascade           => TRUE
--  , No_Invalidate     => FALSE -- Uncomment and set to FALSE if you want to invalidate dependent cursors immediately
    );
END;
/

  • No_Invalidate => FALSE: This option dictates that a change in statistics always invalidates the dependent SQL cursors immediately upon a change to the statistics.

Table Size in Database / Schema Size

Queries to calculate the size of tables and schemas.

1. Table Size (including LOBs and Indexes)

set linesize 300
col owner for a30
col table_name for a30
select * from (
SELECT
    owner,
    table_name,
    TRUNC(sum(bytes)/1024/1024) "SIZE MB"
    FROM
(SELECT segment_name table_name, owner, bytes
 FROM dba_segments
 WHERE segment_type IN ('TABLE', 'TABLE PARTITION', 'TABLE SUBPARTITION')
 UNION ALL
 SELECT i.table_name, i.owner, s.bytes
 FROM dba_indexes i, dba_segments s
 WHERE s.segment_name = i.index_name
 AND    s.owner = i.owner
 AND    s.segment_type IN ('INDEX', 'INDEX PARTITION', 'INDEX SUBPARTITION')
 UNION ALL
 SELECT l.table_name, l.owner, s.bytes
 FROM dba_lobs l, dba_segments s
 WHERE s.segment_name = l.segment_name
 AND    s.owner = l.owner
 AND    s.segment_type IN ('LOBSEGMENT', 'LOB PARTITION')
 UNION ALL
 SELECT l.table_name, l.owner, s.bytes
 FROM dba_lobs l, dba_segments s
 WHERE s.segment_name = l.index_name
 AND    s.owner = l.owner
 AND    s.segment_type = 'LOBINDEX')
--WHERE table_name='***********' -- Uncomment and specify table name to filter
GROUP BY table_name, owner
ORDER BY SUM(bytes) desc ) where rownum <= 10; -- Shows top 10 largest tables

2. Schema Size (in GB)

col owner for a30
col tablespace_name for a30
SELECT owner,SUM(BYTES)/1024/1024/1024 "GB" FROM DBA_SEGMENTS WHERE OWNER in ('ABC') group by owner;

3. Tablespace Size for a Schema (in GB)

SELECT tablespace_name, Sum(bytes)/1024/1024/1024 "GB"  FROM dba_segments WHERE OWNER in ('ABC') group by  tablespace_name;

Hidden Parameter Check

Query to check the current values of hidden (underscore prefixed) parameters.

SELECT x.ksppinm "Parameter",
        Y.ksppstvl "Session Value",
        Z.ksppstvl "Instance Value"
FROM    x$ksppi X,
        x$ksppcv Y,
        x$ksppsv Z
WHERE  x.indx = Y.indx
AND    x.indx = z.indx
AND    x.ksppinm LIKE '/_%' escape '/' -- Filters for hidden parameters
AND    x.ksppinm='_optimizer_cost_based_transformation' -- Specify a particular hidden parameter
order by x.ksppinm;

Service Creation in RAC

Commands for creating and managing services in an Oracle Real Application Clusters (RAC) environment.

1. Add Service

srvctl add service -d MYDB -s My_SRV -r MYDB1,MYDB2

2. Start Service

srvctl start service -d MYDB -s My_SRV

3. Service Status

srvctl status service -d MYDB -s My_SRV

Blocking Session

Query to identify blocking sessions in the database.

SELECT DISTINCT S1.USERNAME || '@' || S1.MACHINE
|| ' ( INST=' || S1.INST_ID || ' SID=' || S1.SID || ' Module=' || S1.MODULE || ') IS BLOCKING '
|| S2.USERNAME || '@' || S2.MACHINE || ' ( INST=' || S1.INST_ID || ' SID=' || S2.SID || ' Module=' || S2.MODULE || ') ' AS BLOCKING_STATUS
FROM GV$LOCK L1, GV$SESSION S1, GV$LOCK L2, GV$SESSION S2
WHERE S1.SID=L1.SID AND S2.SID=L2.SID
AND S1.INST_ID=L1.INST_ID AND S2.INST_ID=L2.INST_ID
AND L1.BLOCK > 0 AND L2.REQUEST > 0
AND L1.ID1 = L2.ID1 AND L1.ID2 = L2.ID2;

Kill Session for Users

PL/SQL block to kill all sessions for a specific user.

BEGIN
  FOR r IN (select inst_id,sid,serial# from gv$session where username = 'Myuser')
  LOOP
    EXECUTE IMMEDIATE 'alter system kill session ''' || r.sid
      || ',' || r.serial# ||',@'|| r.inst_id || '''';
  END LOOP;
END;
/

Dynamic SQL Query Generation

Examples of generating DDL/DML statements dynamically from dictionary views.

1. Generate Synonym Creation SQL

select 'create synonym '||owner||'.'||SYNONYM_NAME||' '||' FOR '|| TABLE_OWNER||'.'||TABLE_NAME||' ;' FROM DBA_SYNONYMS WHERE OWNER like 'ABC%' and table_owner='MY_ABC';

2. Generate Table Move to Tablespace SQL

SELECT 'ALTER TABLE ' || OWNER || '.' || TABLE_NAME || ' MOVE TABLESPACE ' || tablespace_name || ';' from DBA_TABLES WHERE OWNER IN ('OWNER1','OWNER2');

3. Generate LOB Segment Move SQL

SELECT 'ALTER TABLE ' || OWNER || '.' || TABLE_NAME || ' MOVE LOB ('||COLUMN_NAME||') STORE AS SECUREFILE '||SEGMENT_NAME||CHR(10)||'(TABLESPACE My_lob);' SQL_STATEMENTS FROM DBA_LOBS WHERE OWNER like 'OWNER1%';

4. Generate Index Rebuild SQL

select 'ALTER INDEX ' || OWNER || '.' || INDEX_NAME || ' REBUILD TABLESPACE Mytablespace1 ' ||  ';' from DBA_INDEXES WHERE OWNER='OWNER1' and  tablespace_name in ('Mytablespace') ;

Database Properties

Query to check database properties, especially NLS (National Language Support) settings.

col PROPERTY_VALUE for a50
set linesize 300
select PROPERTY_NAME,PROPERTY_VALUE from database_properties where PROPERTY_NAME like 'NLS%';

Friday, August 7, 2015

11g Active Data Guard - enabling Real-Time Query

Oracle 11g Active Data Guard: Enabling Real-Time Query

In Oracle Database 11g, the Active Data Guard feature was introduced. This powerful capability allows a physical standby database to be open in read-only mode for queries while simultaneously applying redo information received from the primary database. This means the standby database can be actively used for reporting and other read-intensive workloads, yet remain continuously up-to-date with the primary.

It's important to note that Active Data Guard is a licensed feature.

Enabling Active Data Guard for Real-Time Query

To enable Active Data Guard and allow real-time querying on your 11g standby database, follow these SQL*Plus commands:

  1. Shutdown the Standby Database: Ensure the standby database is completely shut down before changing its mode.

    SHUTDOWN IMMEDIATE;
    
  2. Start the Standby Database in Mount Mode: The database must be in mount mode to change its open state.

    STARTUP MOUNT;
    
  3. Open the Standby Database in Read-Only Mode: This command opens the database for read access.

    ALTER DATABASE OPEN READ ONLY;
    
  4. Start Managed Recovery and Disconnect from Session: This critical step starts the managed recovery process, which continuously applies redo logs, while allowing your current session to disconnect. The DISCONNECT FROM SESSION clause ensures that the recovery process runs in the background.

    ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
    

    Once managed recovery starts with Active Data Guard, it continues to apply redo even while the database is open read-only. Therefore, there is no need to explicitly switch back from read-only mode to managed recovery mode in this configuration.

Managing Redo Apply via Data Guard Broker (DGMGRL)

If you are using Oracle Data Guard Broker, you can also control the redo apply process from the DGMGRL command-line interface. This provides a more integrated way to manage your Data Guard configuration.

  • Stop Redo Apply: This command stops the redo apply process on the standby database.

    DGMGRL> EDIT DATABASE 'PRODDB' SET STATE='APPLY-OFF';
    

    (Replace 'PRODDB' with the unique name of your standby database as defined in the Data Guard Broker configuration.)

  • Open Standby Read-Only (via SQL*Plus): If redo apply was stopped, you can then open the standby database for read-only access.

    SQL> ALTER DATABASE OPEN READ ONLY;
    
  • Restart Redo Apply: After performing any necessary read-only operations, you can restart the redo apply process using DGMGRL.

    DGMGRL> EDIT DATABASE 'PRODDB' SET STATE='APPLY-ON';
    

    (Replace 'PRODDB' with the unique name of your standby database.)

By following these steps, you can leverage Oracle 11g Active Data Guard to enable real-time querying on your standby database, enhancing its utility for reporting and offloading primary database workload.

Wednesday, July 29, 2015

Direct read in oracle 10G & 11G

Oracle Direct Reads: 10g vs. 11g

In Oracle Database, when a server process needs data blocks that are not found in the database buffer cache (SGA), it reads them from disk into memory. How these blocks are read into memory can significantly impact performance and buffer cache utilization.

Blocks can be read into:

  • Buffer Cache (Buffered Read):

    • These blocks are placed in the Shared Global Area (SGA) buffer cache.

    • They can be accessed and shared by other server processes, promoting data reuse and reducing physical I/O.

    • However, if the buffer cache is full, some older blocks may need to be aged out to make space for new blocks, potentially causing useful data to be evicted.

  • PGA of the Server Process (Direct Read):

    • These blocks are read directly into the Program Global Area (PGA) of the individual server process, bypassing the SGA buffer cache.

    • The blocks are private to that server process and cannot be accessed by other server processes from memory.

    • No blocks in the SGA buffer cache need to be aged out to make space for these new blocks.

Direct reads are typically used when:

  • The data blocks being read are unlikely to be needed by any other process (e.g., large scans).

  • There's a desire to avoid aging out a large number of potentially useful blocks from the shared buffer cache.

Direct Read Behavior in Oracle 10g

In Oracle Database 10g, the behavior of direct reads was largely determined by the type of query:

  • Parallel Queries: All parallel queries, regardless of the amount of data being read, resulted in direct reads. This was based on the assumption that parallel queries are typically used in data warehousing environments where the amount of data read is large, and the data is unlikely to be reused by other sessions immediately.

  • Serial Queries: All serial queries were generally executed using buffered reads, assuming that the amount of data read would not be excessively large.

Limitations in 10g:

  1. Inefficient Parallel Queries: Parallel queries fetching even a small amount of data would bypass the buffer cache. This meant that if any other server process subsequently needed to access the same data, it would have to perform another physical I/O from disk, even if the data was just read by a parallel process.

  2. Buffer Cache Flooding by Serial Queries: A serial query fetching a massive amount of data (e.g., a full table scan on a very large table) could flood the buffer cache, aging out a lot of valuable data that might be frequently accessed by other sessions.

Direct Read Behavior in Oracle 11g

Oracle 11g introduced more flexibility and control over direct read behavior, primarily through undocumented parameters, to address the limitations observed in 10g.

  1. Controlling Parallel Query Behavior (_small_table_threshold):

    • You can set a threshold on the number of blocks read (_small_table_threshold).

    • If a parallel query fetches data less than this threshold, it will perform buffered I/O instead of direct I/O. This allows the fetched data to reside in the buffer cache, making it accessible to other server processes and promoting reuse.

  2. Enabling Direct I/O for Serial Queries (_serial_direct_read):

    • For serial queries, you can enable direct I/O for all full table scans, irrespective of the amount of data read.

    • This is controlled by the _serial_direct_read parameter. Setting this to TRUE (or a non-default value) will cause Full Table Scans (FTSs) to read data directly into the PGA.

    • This prevents large serial scans from aging out a significant amount of data from the SGA buffer cache, preserving valuable cached blocks.

Important Note: Parameters prefixed with an underscore (_) are undocumented and should only be used under the explicit guidance of Oracle Support. Their behavior can change in future releases or patches, and improper use can lead to unexpected performance issues or instability.

Tuesday, July 29, 2014

Oracle Flashback Technology

Oracle Flashback Features Explained

Oracle Flashback Technology provides a set of powerful features that allow users to view past states of data or rewind the database (or specific objects) to a previous point in time. These features offer efficient alternatives to traditional point-in-time recovery, significantly reducing recovery times and simplifying data retrieval.

1. Oracle Flashback Database

Oracle Flashback Database offers a more efficient alternative to traditional database point-in-time recovery (DBPITR). It allows you to revert your entire database (all datafiles) to its state at a past time. This process is much faster than conventional media recovery because it primarily uses "flashback logs" to undo changes, rather than restoring full datafiles from backup and applying extensive redo logs.

  • Reliance: Flashback Database relies on Flashback logs, which are generated in the Flashback Recovery Area (FRA).

  • Key Benefit: No need to restore datafiles from backup; fewer individual changes need to be reapplied from redo logs compared to conventional media recovery.

Managing Restore Points for Flashback Database:

Restore points are crucial for Flashback Database, allowing you to rewind to a specific, named point in time.

  • View Existing Restore Points:

    set linesize 132 pages 80
    col name format a30
    col time format a32
    SELECT name,to_char(scn),time,guarantee_flashback_database FROM v$restore_point order by name;
    
  • Creating Guaranteed Restore Points (Example in Data Guard): This example shows how to create guaranteed restore points on both primary and standby in a Data Guard setup.

    -- On Standby (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Stadnby' SET STATE = 'APPLY-OFF';
    
    -- On Primary (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Primary' SET STATE = 'TRANSPORT-OFF';
    
    -- On Standby (SQL*Plus)
    SQL> CREATE RESTORE POINT Test GUARANTEE FLASHBACK DATABASE;
    
    -- On Primary (SQL*Plus)
    SQL> CREATE RESTORE POINT Test GUARANTEE FLASHBACK DATABASE;
    
    -- On Primary (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Primary' SET STATE = 'TRANSPORT-ON';
    
    -- On Standby (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Stadnby' SET STATE = 'APPLY-ON' WITH APPLY INSTANCE = '';
    
  • Performing Flashback Database to a Restore Point (Example in Data Guard):

    -- On Standby (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Stadnby' SET STATE = 'APPLY-OFF';
    
    -- On Primary (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Primary' SET STATE = 'TRANSPORT-OFF';
    
    -- Stop Databases on Primary and Standby
    -- (Standard shutdown commands for each instance)
    
    -- Start one of the instances in MOUNT mode (e.g., primary)
    -- SQL> STARTUP MOUNT;
    
    -- On Primary (SQL*Plus)
    SQL> FLASHBACK DATABASE TO RESTORE POINT Test;
    
    -- On Standby (SQL*Plus)
    SQL> FLASHBACK DATABASE TO RESTORE POINT Test;
    
    -- Start Databases on Primary and Standby (in normal mode)
    -- (Standard startup commands for each instance)
    
    -- On Primary (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Primary' SET STATE = 'TRANSPORT-ON';
    
    -- On Standby (DGMGRL CLI)
    DGMGRL> EDIT DATABASE 'Stadnby' SET STATE = 'APPLY-ON' WITH APPLY INSTANCE = '';
    

2. Oracle Flashback Query

Oracle Flashback Query allows you to specify a target time (or SCN) and then run SQL queries against your database, viewing the results as they would have appeared at that past time. This is invaluable for recovering from accidental data modifications.

  • Purpose: To retrieve the contents of lost or erroneously changed rows by querying data as it existed at a past point in time.

  • Reliance: Relies on undo data.

  • Example:

    SELECT * FROM EMPLOYEE AS OF TIMESTAMP TO_TIMESTAMP('2009-04-04 09:30:00', 'YYYY-MM-DD HH:MI:SS') WHERE name = 'Adwin';
    

3. Oracle Flashback Version Query

Flashback Version Query lets you view all the versions of all the rows that ever existed in one or more tables within a specified time interval. It also provides metadata about each version, such as start/end SCN/time, operation type (INSERT, UPDATE, DELETE), and transaction ID.

  • Purpose: To recover lost data values, audit changes to tables, and understand the history of row modifications.

  • Reliance: Relies on undo data.

  • Example:

    SELECT versions_startscn, versions_starttime,
           versions_endscn, versions_endtime,
           versions_xid, versions_operation,
           last_name, salary
    FROM employees
    VERSIONS BETWEEN TIMESTAMP
    TO_TIMESTAMP('2013-02-18 14:00:00', 'YYYY-MM-DD HH24:MI:SS')
    AND TO_TIMESTAMP('2014-12-18 18:00:00', 'YYYY-MM-DD HH24:MI:SS')
    WHERE first_name = 'Adwin';
    

4. Oracle Flashback Transaction Query

Flashback Transaction Query allows you to retrieve metadata and historical data for a specific transaction or for all transactions within a given time interval. A unique feature is the UNDO_SQL column, which shows the SQL code that is the logical opposite of the DML operation performed by the transaction, making it useful for reversing changes.

  • Purpose: To audit transaction history, analyze changes made by specific transactions, and generate undo SQL.

  • Reliance: Relies on undo data.

  • Example:

    SELECT xid, operation, start_scn, commit_scn, logon_user, undo_sql
    FROM flashback_transaction_query
    WHERE xid = HEXTORAW('000200030000002D'); -- Replace with your transaction ID
    

5. Oracle Flashback Table

Oracle Flashback Table enables you to return a table to its state at a previous point in time. This operation can be performed while the database remains online, undoing changes only to the specified table.

  • Purpose: To quickly recover a table from logical corruption or accidental changes without performing a full database restore.

  • Reliance: Relies on undo data.

  • Example:

    FLASHBACK TABLE employee TO TIMESTAMP TO_TIMESTAMP('2003-04-04 09:30:00', 'YYYY-MM-DD HH24:MI:SS');
    

6. Oracle Flashback Drop

Flashback Drop reverses the effects of a DROP TABLE statement. When a table is dropped, Oracle does not immediately remove its associated space. Instead, the table is renamed (to a system-generated name) and, along with its associated objects (indexes, constraints, etc.), is placed in the database's Recycle Bin. The Flashback Drop operation recovers the table from this Recycle Bin.

  • Purpose: To recover accidentally dropped tables.

  • Examples:

    • Recover using Recycle Bin name:

      FLASHBACK TABLE "BIN$KSD8DB9L345KLA==$0" TO BEFORE DROP;
      
    • Recover using original table name (if unique in Recycle Bin):

      FLASHBACK TABLE HR.INT_ADMIN_EMP TO BEFORE DROP;
      
    • Recover and rename:

      FLASHBACK TABLE "BIN$KSD8DB9L345KLA==$0" TO BEFORE DROP RENAME TO HR.int2_admin_emp;
      

Underlying Mechanism: Flashback Table, Flashback Query, Flashback Transaction Query, and Flashback Version Query all fundamentally rely on undo data. Undo records store the information necessary to reconstruct data as it stood at a past time and to examine the history of changes. These undo records are primarily used for read consistency and transaction rollback, but they also serve as the foundation for these powerful flashback capabilities.

Saturday, April 12, 2014

Parallel Backup of the Same Datafile (Intrafile parallel backup)

RMAN Intrafile Parallel Backup (SECTION SIZE)

This document describes the concept of Intrafile Parallel Backup in Oracle Recovery Manager (RMAN), specifically focusing on the SECTION SIZE feature, which allows for parallel backup of a single large datafile.

Understanding Intrafile Parallel Backup

Traditionally, when you allocate multiple channels in RMAN, each channel backs up a separate datafile. This means that even with several channels, a single large datafile is still backed up by only one channel at a time, which might not fully utilize the parallel capabilities of your backup infrastructure.

Starting with Oracle Database 11g RMAN, the concept of Intrafile Parallel Backup was introduced. This allows RMAN channels to break a single large datafile into smaller, independent units called "sections." Each section can then be backed up concurrently by a different channel, truly parallelizing the backup of a single large file.

How SECTION SIZE Works

The SECTION SIZE clause in the RMAN BACKUP command allows you to specify the maximum size of each section. RMAN will then divide the datafile into chunks of this specified size, and each chunk can be processed by an available channel in parallel.

Example RMAN Command

Here's an example demonstrating how to use SECTION SIZE to back up a large datafile in parallel:

RMAN> run {
2>      allocate channel c1 type disk format '/backup1/%U';
3>      allocate channel c2 type disk format '/backup2/%U';
4>      backup
5>      section size 500m
6>      datafile 6;
7> }

Explanation:

  • allocate channel c1 type disk format '/backup1/%U'; and allocate channel c2 type disk format '/backup2/%U';: These commands allocate two disk channels, c1 and c2, and specify their respective backup destinations (/backup1 and /backup2).

  • backup section size 500m datafile 6;: This is the core command. It instructs RMAN to back up datafile 6. The SECTION SIZE 500m clause tells RMAN to divide datafile 6 into 500MB sections. Each of these sections will then be backed up concurrently by the allocated channels (c1 and c2).

This setup allows for a significant speedup when backing up very large individual datafiles, as multiple channels can work on different parts of the same file simultaneously.

Listing Backed-Up Sections

When a datafile is backed up using SECTION SIZE, the backup pieces reflect these sections.

RMAN> list backup of datafile 6;

Example Output:

...
...
    List of Backup Pieces for backup set 901 Copy #1
    BP Key  Pc# Status      Piece Name
    -------    ---  -----------      ----------
    2007    1   AVAILABLE   /backup1/9dhk7os1_1_1
    2008    2   AVAILABLE   /backup2/9dhk7os1_1_1
    2009    3   AVAILABLE   /backup1/9dhk7os1_1_3
    2009    3   AVAILABLE   /backup2/9dhk7os1_1_4

Notice how the backup pieces (/backup1/9dhk7os1_1_1, /backup2/9dhk7os1_1_1, etc.) correspond to different sections of the datafile. Since each section can go to a different channel, you can direct them to different mount points (like /backup1 and /backup2 in the example), enabling parallel writing to disk or even tape.

Important Consideration for Disk Performance

While SECTION SIZE offers great parallelization benefits, it's crucial to consider the underlying storage.

  • No Advantage on Single Disk: If the large datafile resides entirely on a single physical disk, there is generally no performance advantage to using parallel backups with SECTION SIZE. In such a scenario, the disk head would have to constantly move back and forth to access different sections of the file, which can outweigh the benefits of parallel processing and actually degrade I/O performance.

  • Benefit with Striped/Multiple Disks: The true benefit of SECTION SIZE comes when the large datafile is spread across multiple physical disks (e.g., via RAID, ASM, or striped file systems) or when the backup pieces are written to different physical backup destinations. This allows the parallel I/O operations to be truly concurrent.

Thursday, April 10, 2014

RMAN LEVEL 0 Backup

RUN {
ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE'; 
ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE';  
backup incremental level 0 filesperset 1 format '%d_LEVEL0_%s_%t_%p.dbf' database include current controlfile; 
sql 'alter system archive log current'; 
change archivelog all crosscheck; 
backup NOT BACKED UP 1 TIMES archivelog all  filesperset 1 format '%d_arch_%s_%t_%p.arc';
DELETE ARCHIVELOG ALL  BACKED UP 1 TIMES TO DEVICE TYPE sbt COMPLETED BEFORE 'SYSDATE-1/24';
RELEASE CHANNEL CH1; 
RELEASE CHANNEL CH2; 
RELEASE CHANNEL CH3; 
RELEASE CHANNEL CH4;  
}

Monday, April 7, 2014

what you mean by 11.2.0.3.0 (Major release.release.app release #.patch set.PSU)

11.2.0.3.0 : The first digit  is the major release number.  When we say 9i, 10g or 11g we mean the major release number

11.2.0.3.0 : This second digit is the maintenance release number. This is usually called only "release". For example when you say 11g Release 1 or 11g Release 2 in fact you are mentioning maintenance release number. Maintenance releases are full installations. It means that all files are replaced during upgrade. Maintenance releases contain bug fixes and new features for database.

11.2.0.3.0 : This third digit is the release number for Oracle application servers.  For database software, it should be 0.

11.2.0.3.0 : The fourth digit is called component specific release number. It shows the patch set version that has been applied to database. As of 11g, the patch sets are now full installations. They contain bug fixes and add new features to database. However the number of new features is not as high as maintenance releases'. Its scope is limited. This bugs fixed with this patch set are not listed here because applying a patchset is a full installation.

11.2.0.3.0 :The last digit is called platform specific release number. Patch set updates use this fifth number. A patch set update (PSU) is a collection of patches distributed 4 times a year by Oracle (every 3 months). They contain patches for most common bugs and security holes. They don't add a new feature to database. They are not full installations. Only faulty files on your database are replaced. Oracle recommends installing patch sets even if you haven't hit any of the bugs fixed in those patch sets

Wednesday, April 2, 2014

10G R2 New feature

- OCR can now be mirrored ,2 Copies Max
- Voting Disk can be mirrored ,3 Copies Max

Saturday, March 29, 2014

11G R2 RAC: GPNP PROFILE

Oracle GPnP Profile Explained

The Global Plug and Play (GPnP) Profile is a crucial component of Oracle Clusterware, particularly in Oracle Grid Infrastructure environments. It's a small XML file that plays a vital role in establishing the correct global personality and configuration of each node within an Oracle Cluster.

What is the GPnP Profile?

The GPnP profile is a small XML file typically located under GRID_HOME/gpnp/<node_name>/profiles/peer/profile.xml. Each node in the cluster maintains a local copy of this profile. Its primary function is to provide essential configuration information that allows a node to correctly identify itself and integrate into the cluster.

The GPnP Profile is primarily maintained and managed by the GPnP Daemon (GPnPD), which runs on each node in the cluster.

What Does the GPnP Profile Contain?

The profile.xml file contains critical configuration details that define the cluster's identity and resource locations:

  • Cluster Name: The unique name of the Oracle Cluster.

  • Network Classifications: Information about public and private (interconnect) network interfaces, including their roles and IP addresses.

  • Storage to be Used for Cluster Synchronization Services (CSS): This specifies the location of the Voting Disk, which is essential for cluster quorum and membership.

  • Storage to be Used for Automatic Storage Management (ASM):

    • SPFILE Location: The location of the ASM SPFILE (Server Parameter File).

    • ASM Disk String: The discovery string used by ASM to find its disks.

    • Other ASM-related configuration details.

Who Updates the GPnP Profile?

The GPnPD daemon is responsible for replicating changes to the GPnP profile. This replication occurs during:

  • Installation: Initial configuration during Grid Infrastructure setup.

  • System Boot: When a node starts up and joins the cluster.

  • When Updated: Whenever configuration changes are made to the cluster using specific Oracle Clusterware and ASM configuration tools.

The profile is automatically updated when changes are made using tools such as:

  • oifcfg: Used to change network configurations (e.g., adding or modifying public/private interfaces).

  • crsctl: Used to change the location of the Voting Disk or other Clusterware resources.

  • asmcmd: Used to modify ASM parameters like ASM_DISKSTRING or the ASM SPFILE location.

How is the GPnP Profile Used by Clusterware?

The GPnP profile is fundamental to the Clusterware startup process and overall cluster operation:

  • Clusterware Startup: To start Clusterware, the Voting Disk needs to be accessed. If the Voting Disk resides on ASM (which is common), the GPnP profile provides the necessary information (e.g., ASM Disk String and ASM SPFILE location) to locate and read the Voting Disk even before the ASM instance itself is fully up.

  • kfed Utility: The Voting Disk can be read using the kfed utility (Kernel File Edition utility) directly from the disk even if ASM is not running, leveraging the information from the GPnP profile.

  • ASM SPFILE Search Order: When an ASM instance starts, it searches for its SPFILE in a specific order, with the GPnP profile being the first place it looks:

    1. GPnP profile

    2. $ORACLE_HOME/dbs/spfile<SID>.ora

    3. $ORACLE_HOME/dbs/init<SID>.ora

Useful gpnptool Commands

The gpnptool utility allows you to interact with and query the GPnP profile.

  • How to read the entire GPnP profile:

    [root@inssc3 bin]# ./gpnptool get
    

    This command outputs the full XML content of the local GPnP profile.

  • How to find if GPnP Daemons are running on the local node:

    [root@host01 peer]# gpnptool lfind
    Success. Local gpnpd found.
    

    This confirms the local GPnPD is active.

  • How to find the location of the ASM SPFILE if ASM is down:

    [root@host01 peer]# gpnptool getpval -asm_spf
    +DATA/cluster01/asmparameterfile/registry.253.783619911
    

    This command extracts the value of the asm_spf parameter from the GPnP profile, showing the path to the ASM SPFILE.

  • How to find all RD-discoverable resources of a given type:

    [root@host01 peer]# gpnptool find
    Found 3 instances of service ‘gpnp’.
            mdns:service:gpnp._tcp.local.://host03:18015/agent=gpnpd,cname=cluster01,host=host03,pid=5066/gpnpd h:host03 c:cluster01
            mdns:service:gpnp._tcp.local.://host02:17637/agent=gpnpd,cname=cluster01,host=host02,pid=5236/gpnpd h:host02 c:cluster01
            mdns:service:gpnp._tcp.local.://host01:16633/agent=gpnpd,cname=cluster01,host=host01,pid=5206/gpnpd h:host01 c:cluster01
    

    This command uses multicast DNS (mDNS) to discover GPnP services (and thus active GPnPDs) across the cluster, providing details like hostname, cluster name, and process ID.

Understanding the GPnP profile and its associated tools is essential for advanced troubleshooting and management of Oracle Clusterware environments.

Friday, November 1, 2013

RMAN new features

9i 

CONFIGURE BACKUP OPTIMIZATION ON 

10G

Fast Incremental Backups (Block Change Tracking)

Cataloging Backup Pieces

Automatic Instance Creation for RMAN TSPITR

Backupset Compression

Restore Preview

Automatic Datafile Creation 

11G

Improved Integration with Data Guard

Archived Log Deletion Policy Enhancements

Network-Enabled Database Duplication Without Backups

Recovery Catalog Enhancements (virtual private catalog)


IMPORT CATALOG

Archived Redo Log Failover

Undo Optimization

Improved Block Media Recovery Performance

Block Change Tracking Support for Standby Databases

Backup of Read-Only Transportable Tablespaces

Tuesday, January 8, 2013

if you want check the CPU patch is whether rolling support or not

To check if a CPU patch supports rolling upgrades, you need to use the opatch query -all command. This command provides detailed information about the patches applied to your Oracle Home.

Here's the SOP:

Standard Operating Procedure (SOP) to Check if a CPU Patch Supports Rolling Upgrade:

  1. Log in to the Oracle Server: Connect to the server where your Oracle database software is installed, using the oracle user or an account with appropriate permissions to run opatch.

  2. Set Oracle Environment: Ensure your ORACLE_HOME and PATH are correctly set for the Oracle Home you want to check. You can use the oraenv utility for this:

    . oraenv
    

    (Enter the ORACLE_SID associated with the ORACLE_HOME you're interested in, or set ORAENV_ASK=N and ORACLE_SID before running).

  3. Execute opatch query -all: Run the opatch command with the -all option.

    opatch query -all
    
  4. Review the Output: In the output generated by opatch query -all, look for a line that explicitly states whether the patch is a rolling patch or not.

    You will find a line similar to this:

    Patch is a rolling patch: true
    

    or

    Patch is a rolling patch: false
    
    • If the value is true, then the CPU patch supports rolling upgrades.
    • If the value is false, then the CPU patch does not support rolling upgrades, and a full cluster shutdown might be required for patching.

This line is the definitive indicator within the opatch output for rolling patch support.

Monday, July 30, 2012

How to read AWR Report oracle DB

Oracle AWR Report Analysis: Key Sections for Performance Monitoring

The Automatic Workload Repository (AWR) report is a powerful diagnostic tool in Oracle Database that provides a snapshot of database performance over a specified time interval. Analyzing different sections of the AWR report helps DBAs identify performance bottlenecks and trends.

This document outlines several key sections of an AWR report and what information they provide.

Report Header

This is the introductory section of the AWR report.

  • Content: Provides fundamental information about the database and the AWR snapshot interval, including:

    • Database Name and ID

    • Instance Name (if RAC)

    • Platform Information

    • Snap Interval (the duration of the snapshot)

Load Profile

The Load Profile section provides a high-level summary of database activity during the snapshot interval, normalized to per-second rates.

  • DB time(s): The total amount of time Oracle has spent performing database user calls. This does not include background processes.

  • DB CPU(s): The amount of CPU time spent on user calls. Similar to DB time, it does not include background processes. The value is typically in microseconds.

  • Redo size: The average amount of redo data generated per second by transactions.

  • Logical reads: Represents Consistent Gets + DB Block Gets. This is the total number of blocks read from the buffer cache (logical I/O).

  • Block Changes: The number of data blocks modified during the sample interval.

  • Physical reads: The number of block requests that caused a physical I/O operation (i.e., had to be read from disk).

  • Physical writes: The number of physical writes performed to datafiles.

  • User calls: The number of user queries/calls generated per second.

  • Parses: The total number of parse operations (both hard and soft) per second.

  • Hard Parses: The number of parses requiring a completely new parse of the SQL statement. These consume significant resources (latches and shared pool area).

  • Soft Parses: (Derived by subtracting hard parses from total parses). A soft parse reuses a previously hard-parsed SQL statement, consuming significantly fewer resources.

  • Sorts: The number of sort operations performed per second.

  • Logons: The number of new user logons during the interval.

  • Executes: The number of SQL executions per second.

  • Transactions: The number of user transactions per second.

Shared Pool Statistics

This section provides insights into the utilization and efficiency of the Shared Pool, a critical SGA component.

  • Begin/End Memory Usage %: Shows the percentage of the Shared Pool used at the beginning and end of the snapshot.

  • SQL with executions > 1 %: Percentage of SQL statements in the Shared Pool that have been executed more than once.

  • Memory for SQL w/exec > 1 %: Percentage of Shared Pool memory consumed by SQL statements executed more than once.

Interpretation:

  • Ideally, memory usage should not be excessively high (e.g., consistently beyond 90%), as this could indicate contention in the shared pool and suggest it is too small.

  • If the percentage is very low (e.g., around 50%), it might indicate that the shared pool is too large for the current workload, leading to wasted memory.

Instance Efficiency Percentages (Target 100%)

These percentages indicate how efficiently the database instance is operating. Values close to 100% are desirable.

  • Buffer Nowait %: Percentage of buffer gets that did not have to wait.

  • Redo NoWait %: Percentage of redo entries that did not have to wait for space in the redo buffer.

  • Buffer Hit %: Percentage of logical reads that found the block already in the buffer cache (avoiding physical I/O).

  • In-memory Sort %: Percentage of sort operations performed entirely in memory (not spilling to disk).

  • Library Hit %: Percentage of parse calls that found the SQL statement already in the library cache (soft parse).

  • Soft Parse %: Percentage of total parse calls that were soft parses.

  • Execute to Parse %: Percentage of executions relative to parses. A high value indicates good SQL reuse.

  • Latch Hit %: Percentage of latch gets that were successful on the first attempt.

  • Parse CPU to Parse Elapsd %: Ratio of CPU time spent parsing to total elapsed time during parsing. A low value might indicate parsing contention.

  • % Non-Parse CPU: Percentage of CPU time spent on actual execution rather than parsing.

Top 5 Timed Foreground Events

This crucial section identifies the top 5 events that foreground processes spent the most time waiting for. "Time" is a very important component here, as it directly points to where the database is spending its time waiting. Analyzing these events is often the starting point for performance tuning.

RAC Statistics

This section is present in AWR reports generated for Oracle Real Application Clusters (RAC) environments. It provides metrics specific to inter-instance communication and resource management, such as Global Cache (GC) related wait events (e.g., gc current block request, gc cr block request).

Time Model Statistics

This section breaks down the total DB time into various components, showing how much time was spent on different database activities (e.g., SQL execution, parsing, PL/SQL execution, Java execution). This provides a granular view of where the database time is actually being consumed.

SQL Statistics

This section provides detailed performance metrics for individual SQL statements. It typically includes sub-sections that order SQL statements by:

  • SQL ordered by Elapsed Time: Top SQL statements consuming the most total time (CPU + Wait).

  • SQL ordered by CPU Time: Top SQL statements consuming the most CPU time.

  • SQL ordered by Gets: Top SQL statements performing the most logical reads (buffer gets).

  • SQL ordered by Reads: Top SQL statements performing the most physical reads.

I/O Stats Section

This section provides detailed statistics about I/O operations.

  • Av Rd(ms) (Average Read time in milliseconds): This metric is a key indicator of I/O latency. Ideally, this value should not cross beyond 10ms. A value consistently above this threshold is considered an I/O bottleneck, indicating that the storage subsystem is struggling to deliver data quickly.

Advisory Statistics

Advisory sections provide recommendations for optimizing various SGA and PGA memory components.

  • Buffer Pool Advisory: Recommends optimal DB_CACHE_SIZE based on workload simulation.

  • PGA Aggr Summary: Summary of PGA memory usage.

  • PGA Aggr Target Stats: Statistics related to the PGA Aggregate Target.

  • PGA Aggr Target Histogram: Distribution of PGA memory usage.

  • PGA Memory Advisory: Recommends optimal PGA_AGGREGATE_TARGET based on workload.

  • Shared Pool Advisory: Recommends optimal SHARED_POOL_SIZE.

  • SGA Target Advisory: Recommends optimal SGA_TARGET (if using Automatic Shared Memory Management).

  • Streams Pool Advisory: Recommends optimal STREAMS_POOL_SIZE (if using Oracle Streams).

  • Java Pool Advisory: Recommends optimal JAVA_POOL_SIZE (if using Java in the database).

init.ora Parameters

This section lists the values of all initialization parameters that were set at the instance level during the AWR snapshot interval. This is useful for understanding the database's configuration.

By thoroughly reviewing these sections in an AWR report, DBAs can gain a comprehensive understanding of database performance, identify bottlenecks, and make informed decisions for tuning and optimization.


=====================================================================


Here's how you can derive DB IOPS (Input/Output Operations Per Second) and Throughput (data transferred per second) from the sections of an AWR report you've described:

To understand your database's I/O performance, you'll primarily look at the "Load Profile" and potentially infer from the "I/O Stats" section.

Deriving DB IOPS (Input/Output Operations Per Second)

IOPS represents the number of individual read or write operations performed per second.

  1. Identify Key Metrics in "Load Profile":

    • Physical reads: This is the total number of data blocks that Oracle had to read from disk into memory during the AWR snapshot interval. Each of these counts as an I/O operation.
    • Physical writes: This is the total number of data blocks that Oracle wrote from memory to disk during the AWR snapshot interval. Each of these also counts as an I/O operation.
  2. Find the AWR Snapshot Interval:

    • Look at the "Report Header" section. It will specify the start and end times of the AWR snapshot, from which you can calculate the elapsed_seconds.
      • AWR Interval (seconds) = END_TIME - START_TIME
  3. Calculate IOPS:

    • Total IOPS = (Physical reads + Physical writes) / AWR Interval (seconds)

    Example: If Physical reads = 1,000,000, Physical writes = 500,000, and AWR Interval = 3600 seconds (1 hour): Total IOPS = (1,000,000 + 500,000) / 3600 = 1,500,000 / 3600 ≈ 416.67 IOPS

Deriving DB Throughput (Data Transferred per Second)

Throughput represents the total volume of data (in MB/GB) transferred to or from disk per second.

  1. Identify Key Metrics in "Load Profile":

    • Again, use Physical reads and Physical writes.
  2. Determine Database Block Size:

    • The AWR report itself usually lists the database block size (e.g., 8KB, 16KB) in the "Report Header" or "init.ora Parameters" section. If not, you can query show parameter db_block_size in SQL*Plus.
    • Convert the block size to bytes (e.g., 8KB = 8 * 1024 bytes = 8192 bytes).
  3. Find the AWR Snapshot Interval:

    • As before, from the "Report Header".
  4. Calculate Throughput:

    • Total Throughput (Bytes/sec) = ((Physical reads + Physical writes) * Database Block Size in Bytes) / AWR Interval (seconds)
    • To convert to Megabytes per second (MB/sec), divide the result by (1024 * 1024).
    • To convert to Gigabytes per second (GB/sec), divide the result by (1024 * 1024 * 1024).

    Example: Using the above IOPS example, with a Database Block Size = 8192 bytes: Total Throughput (Bytes/sec) = (1,500,000 * 8192) / 3600 = 12,288,000,000 / 3600 ≈ 3,413,333 Bytes/sec Total Throughput (MB/sec) = 3,413,333 / (1024 * 1024) ≈ 3.25 MB/sec

Using "I/O Stats" Section

The "I/O Stats" section, particularly the Av Rd(ms) (Average Read time in milliseconds), is an indicator of I/O latency, not directly IOPS or throughput.

  • Av Rd(ms): This metric tells you how quickly your storage subsystem is responding to read requests.
    • A value consistently above 10ms (as you noted) indicates a potential I/O bottleneck, suggesting that your storage system might be struggling to keep up with the demand, which would directly impact your achievable IOPS and throughput. While it doesn't give you the raw numbers, it's a critical health check for your I/O subsystem.