Sunday, September 30, 2018

Parallel DDL and DML (create table as select)

Oracle Parallel DDL and DML Operations

Oracle Database provides powerful capabilities for parallelizing both Data Definition Language (DDL) and Data Manipulation Language (DML) operations. This can significantly reduce the execution time for large operations such as creating tables from existing data, or inserting large volumes of data.

Parallel DDL: CREATE TABLE AS SELECT

Parallel DDL allows the creation of database objects (like tables, indexes) to be performed by multiple parallel execution servers. This is particularly beneficial when creating a new table based on a SELECT statement from a large existing table.

Example: Creating a new table APP_SCHEMA2.APP_TABLE2 from APP_SCHEMA1.APP_TABLE1 in parallel.

CREATE TABLE APP_SCHEMA2.APP_TABLE2 PARALLEL 15 AS
SELECT /*+ PARALLEL(A,15) */ *
FROM APP_SCHEMA1.APP_TABLE1 A;

Explanation:

  • PARALLEL 15 (in CREATE TABLE clause): This specifies the default degree of parallelism (DOP) for the newly created table APP_SCHEMA2.APP_TABLE2. Any subsequent DML or DDL on this table might use this DOP if parallel execution is enabled.

  • /*+ PARALLEL(A,15) */ (hint in SELECT clause): This hint explicitly tells the optimizer to use 15 parallel execution servers for the SELECT operation on APP_SCHEMA1.APP_TABLE1. The CREATE TABLE AS SELECT operation will then leverage this parallelism to read data and populate the new table concurrently.

Benefits: Faster table creation, especially for very large tables, by distributing the work among multiple processes.

Parallel DML: INSERT Operations

Parallel DML enables INSERT, UPDATE, DELETE, and MERGE statements to be executed by multiple parallel execution servers. For INSERT statements, this is most effective with direct-path inserts.

Prerequisite: Enable parallel DML for the session.

ALTER SESSION ENABLE PARALLEL DML;

Example: Inserting data from APP_USER1.APP_TABLE1 into APP_USER2.APP_TABLE2 using parallel DML.

INSERT /*+ APPEND PARALLEL(A,60) */ INTO APP_USER2.APP_TABLE2 A
SELECT /*+ PARALLEL(B,60) */ *
FROM APP_USER1.APP_TABLE1 B;

Explanation:

  • ALTER SESSION ENABLE PARALLEL DML;: This statement is mandatory to enable parallel DML for the current session. Without it, the parallel hints in the DML statement will be ignored.

  • /*+ APPEND */: This hint instructs Oracle to perform a direct-path insert. Direct-path inserts write data directly to the datafiles, bypassing the buffer cache, which is significantly faster for bulk data loading. It also acquires an exclusive table lock during the operation.

  • /*+ PARALLEL(A,60) */ (hint in INSERT clause): This hint specifies that the INSERT operation on APP_USER2.APP_TABLE2 should use 60 parallel execution servers.

  • /*+ PARALLEL(B,60) */ (hint in SELECT clause): This hint specifies that the SELECT operation on APP_USER1.APP_TABLE1 should also use 60 parallel execution servers.

Benefits: Dramatically faster data insertion for large datasets by leveraging multiple CPUs and I/O channels.

Important Considerations

  • Resource Consumption: Parallel operations consume more CPU, memory, and I/O resources. Ensure your system has sufficient capacity.

  • Table Locking: Direct-path inserts (APPEND hint) acquire an exclusive lock on the target table, preventing other DML operations on that table until the insert completes.

  • Undo Generation: Direct-path inserts generate minimal undo, which is another reason for their speed.

  • Degree of Parallelism (DOP): The optimal DOP depends on your hardware (number of CPU cores, I/O bandwidth) and the nature of the operation. Experimentation is often required to find the best value.

  • Indexing: Indexes on the target table will be maintained during parallel DML, but this can impact performance. For very large inserts, it might be faster to drop indexes, perform the insert, and then rebuild the indexes.

  • Transaction Management: Parallel DML operations are part of a transaction and require a COMMIT or ROLLBACK.

By strategically using parallel DDL and DML, you can significantly improve the performance of large-scale data operations in your Oracle database.

Tuesday, July 3, 2018

DB IOPS & Throughput from AWR report Oracle DB

Detailed I/O Metrics and Network Throughput

The AWR report provides more granular I/O and network metrics, often summarized in an "I/O Profile" or found within "Instance Activity Stats."

I/O Profile (Summary):

  • IOPS: Total Requests: Read + Write Per Second

  • Throughput (MB): Total (MB): Read + Write Per Second

Mapping from "Instance Activity Stats" to "IO Profile":

Instance Activity Stats Metric

IO Profile Metric (Per Second)

physical read total IO requests

Total Requests: Read per Second

physical write total IO requests

Total Requests: Write Per Second

physical read total bytes / 1024 / 1024

Total (MB): Read per Second

physical write total bytes / 1024 / 1024

Total (MB): Write Per Second

Mapping from "Load Profile" to "Instance Activity Stats":

Load Profile Metric

Instance Activity Stats Metric

Read IO requests

physical read IO requests

Write IO requests

physical write IO requests

Read IO(MB)

physical read bytes

Write IO(MB)

physical write bytes

Network Throughput:

These metrics provide insight into network activity related to SQL*Net communication.

  • bytes received via SQL*Net from client

  • bytes sent via SQL*Net to client

  • MB received via SQL*Net from client

  • MB sent via SQL*Net to client

Friday, June 1, 2018

Avamar Client installation for Oracle 12cR2 RAC database

Avamar Client Installation for Oracle 12cR2 RAC Database

This document outlines the step-by-step process for installing and configuring the Avamar Client and RMAN plugin on an Oracle 12cR2 Real Application Clusters (RAC) database. This setup enables Avamar to perform RMAN backups of your RAC database.

Prerequisites

  • Access to the Avamar Client and RMAN plugin RPM files.

  • root privileges on all RAC nodes.

  • Knowledge of your Oracle Clusterware Home and Oracle Home paths.

  • Avamar Administrator Server address and domain.

Installation and Configuration Steps

Step 1: Install Avamar Client RPM

Install the core Avamar client RPM package on all RAC nodes.

rpm -ivh AvamarClient-linux-sles11-x86_64-7.5XXXXXX.rpm

(Replace AvamarClient-linux-sles11-x86_64-7.5XXXXXX.rpm with the actual filename of your Avamar Client RPM.)

Step 2: Install Avamar RMAN RPM

Install the Avamar RMAN plugin RPM package on all RAC nodes. This RPM provides the necessary integration for RMAN backups.

rpm -ivh AvamarRMAN-linux-sles11-x86_64-7.5XXXXXXXX.rpm

(Replace AvamarRMAN-linux-sles11-x86_64-7.5XXXXXXXX.rpm with the actual filename of your Avamar RMAN RPM.)

Step 3: Client Configuration for RAC Node 1

Perform the RAC client configuration on the first node using the rac_config utility.

Navigate to the Avamar client binaries directory:

cd /usr/local/avamar/bin/

Execute the rac_config script:

[root@Hostname1 bin]# ./rac_config

Follow the prompts as shown in the example:

  • Enter the path of Oracle Clusterware Home: /XXXX/XXXXX/product/12.2.0/grid

    • (This should be your actual Grid Infrastructure Home path.)

  • Using ORACLE_HOME: /XXXX/XXXXX/product/12.2.0/grid

    • (Confirms the detected Oracle Home, which should be the Grid Home.)

  • Setting PATH set for Oracle commands

  • Oracle cluster version 12cR2

  • Do you want to configure on a cluster shared filesystem? [y/n] [y]: n

    • (Choose 'n' if /usr/local/avamar/var is not on a shared filesystem. If you have a shared filesystem for Avamar configuration, you might choose 'y'.)

  • Enter the full path of var directory location[]: /usr/local/avamar/bin/var

    • (This is where Avamar will store its variable data. Ensure it's local to each node if not using a shared filesystem.)

  • Using /usr/local/avamar/bin/var as var directory location

  • Enter the cluster scan name [scanXXXX]: scanXXXX

    • (Enter your Oracle SCAN name. If it's already detected correctly, you can just press Enter.)

  • Using scanXXXX as hostname

  • Now adding resource EMCagent.

  • The resource EMCagent is added successfully.

The script will then provide instructions for the next steps:

  1. Run rac_config with the same var directory on other nodes.

  2. Run /usr/local/avamar/ora_rac/bin/avregister to register and activate this client with the Administrator server.

  3. Copy cid.bin and avagent.cfg from Hostname1 to other nodes.

Step 4: Client Configuration for RAC Node 2 (and other nodes)

Repeat the rac_config process on each subsequent RAC node (e.g., Hostname2). Ensure you provide the same var directory location as used on Hostname1.

cd /usr/local/avamar/bin/
[root@Hostname2 bin]# ./rac_config

Follow the same prompts, providing consistent information.

Step 5: Register Client to Avamar Server

After rac_config has been run on all nodes, register the client with the Avamar Administrator server from one of the RAC nodes (e.g., Hostname1).

[root@Hostname1 bin]# /usr/local/avamar/ora_rac/bin/avregister

Follow the prompts:

  • Enter the Administrator server address (DNS text name or numeric IP address, DNS name preferred): Backup server name/IP

    • (Provide the hostname or IP address of your Avamar Administrator server.)

  • Enter the Avamar server domain [clients]: (Press Enter for default 'clients' or specify your domain)

The registration process will then proceed, showing output similar to this:

avagent.d Info: Client Agent not running.           [PASSED]
avagent Info : Logging to /usr/local/avamar/ora_rac/var/avagent.log
avagent Info : - Reading /usr/local/avamar/ora_rac/var/avagent.cmd
avagent.d Info: Client activated successfully.      [  OK  ]
avagent Info : Logging to /usr/local/avamar/ora_rac/var/avagent.log
avagent Info : - Reading /usr/local/avamar/ora_rac/var/avagent.cmd
avagent Info : daemonized as process id 25161
avagent.d Info: Client Agent started.               [  OK  ]
avagent.d Info: Stopping Avamar Client Agent (avagent)...
avagent.d Info: Client Agent stopped.               [  OK  ]
CRS-2672: Attempting to start 'EMCagent' on 'Hostname1'
CRS-2676: Start of 'EMCagent' on 'Hostname1' succeeded
Registration Complete.

Step 6: Transfer Configuration Files to Other Nodes

The avregister command creates or updates critical configuration files (cid.bin and avagent.cfg) on the node where it was executed. These files need to be copied to the corresponding var directory on all other RAC nodes to ensure consistent client registration across the cluster.

cp /usr/local/avamar/ora_rac/var/cid.bin /usr/local/avamar/ora_rac/var/avagent.cfg Hostname2:/usr/local/avamar/ora_rac/var/

(Replace Hostname2 with the actual hostname of your second RAC node, and repeat for any other nodes in the cluster.)

After these steps, your Avamar client and RMAN plugin should be successfully installed and configured across your Oracle 12cR2 RAC database, ready for backup operations.

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.