Friday, January 4, 2019

Recreate Lob table or big table in PARALLEL

Recreating LOB/Big Tables in Parallel

This section provides steps to recreate a large table, potentially containing LOBs, in parallel for improved performance. This is useful for reorganizing data, applying new storage attributes, or simply moving data efficiently.

Source Table: APP_USER.APP_TABLE1 Target Table: APP_USER.APP_TABLE2

Step 1: Create a Sequence (for Logging Timing)

Create a sequence to generate unique IDs for logging the start and end times of the operation.

CREATE SEQUENCE Myuser.T_SQ
  START WITH 1
  INCREMENT BY 1
  NOCACHE;

-- Create a table to log the job times (if it doesn't exist)
CREATE TABLE Myuser.job_time (
    t_id    NUMBER,
    t_name  VARCHAR2(100),
    t_type  VARCHAR2(10),
    t_time  DATE
);

Step 2: Create a Procedure

Create a PL/SQL procedure that performs the parallel insert operation and logs its timing.

CREATE OR REPLACE PROCEDURE Myuser.my_proc AS
  v_seq NUMBER;
BEGIN
  -- Enable parallel processing for the current session
  EXECUTE IMMEDIATE 'ALTER SESSION SET PARALLEL_FORCE_LOCAL=TRUE';
  EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML';

  -- Get the next sequence value for logging
  SELECT Myuser.T_SQ.NEXTVAL INTO v_seq FROM dual;

  -- Log the start time of the operation
  INSERT INTO Myuser.job_time (t_id, t_name, t_type, t_time) VALUES (v_seq, 'APP_TABLE1', 'START', SYSDATE);
  COMMIT;

  -- Perform the parallel insert from source to target table
  -- APPEND hint for direct path insert, PARALLEL hint for parallel execution
  INSERT /*+ APPEND PARALLEL(A,60) */ INTO APP_USER.APP_TABLE2 A
  SELECT /*+ PARALLEL(B,60) */ * FROM APP_USER.APP_TABLE1 B;
  COMMIT;

  -- Log the end time of the operation
  INSERT INTO Myuser.job_time (t_id, t_name, t_type, t_time) VALUES (v_seq, 'APP_TABLE1', 'END', SYSDATE);
  COMMIT;

EXCEPTION
  WHEN OTHERS THEN
    -- Log any errors
    INSERT INTO Myuser.job_time (t_id, t_name, t_type, t_time) VALUES (v_seq, 'APP_TABLE1', 'ERROR', SYSDATE);
    COMMIT;
    RAISE; -- Re-raise the exception after logging
END;
/

Note:

  • PARALLEL(A,60) and PARALLEL(B,60) hints suggest using 60 parallel slaves. Adjust this number based on your system's CPU cores and I/O capabilities.

  • APPEND hint performs a direct-path insert, which is faster for large data volumes as it bypasses the buffer cache.

  • Ensure that APP_USER.APP_TABLE2 is already created with the desired structure (including LOB segments if APP_TABLE1 has them) and any necessary indexes or constraints are handled separately.

Step 3: Execute Procedure

Execute the procedure to start the parallel table recreation process.

EXEC Myuser.my_proc;

After execution, you can query Myuser.job_time to check the start and end times of the operation.

This comprehensive overview should provide a solid understanding of Oracle's Multitenant Architecture and its evolution across recent database releases.

Tuesday, January 1, 2019

Good motivational books to read 2025

  • "The Monk Who Sold His Ferrari" by Robin Sharma: A classic allegorical tale offering profound lessons on living a more fulfilling life.
  • "No Excuses: The Power of Self-Discipline" by Brian Tracy: A practical guide to developing self-discipline in various aspects of life to achieve greater success.
  • "Atomic Habits" by James Clear: Focuses on how tiny changes can lead to remarkable results. It's practical and actionable for building good habits and breaking bad ones.
  • "The 7 Habits of Highly Effective People" by Stephen Covey: A timeless classic that provides a holistic, integrated, principle-centered approach for solving personal and professional problems.
  • "Grit: The Power of Passion and Perseverance" by Angela Duckworth: Explores why talent isn't the only factor for success, highlighting the importance of passion and long-term perseverance.
  • "Mindset: The New Psychology of Success" by Carol S. Dweck: Introduces the concepts of fixed and growth mindsets and how they impact our ability to learn and grow.
  • "Can't Hurt Me: Master Your Mind and Defy the Odds" by David Goggins: An intense and inspiring memoir about overcoming incredible adversity through extreme mental toughness.
  • "The Power of Habit" by Charles Duhigg: Delves into the science behind habit formation in individuals, organizations, and societies.
  • "Drive: The Surprising Truth About What Motivates Us" by Daniel H. Pink: Challenges traditional ideas of motivation and explores the power of autonomy, mastery, and purpose.
  • Wednesday, November 28, 2018

    query execution taking long time in oracle (parse bug)

    Oracle Query Execution Long Time Due to Parsing Bug

    Issue Description

    In certain Oracle environments, a specific query has been observed to exhibit erratic execution times, ranging significantly from approximately 3 seconds to 50 seconds. Upon detailed analysis, it was determined that the variability in execution time was primarily attributable to the parsing phase of the query.

    This prolonged parsing time was often exacerbated by sub-optimal application coding practices, which led to the query undergoing frequent hard parses rather than leveraging soft parsing. Hard parsing is resource-intensive and contributes significantly to query latency when repeated often.

    Resolution

    The root cause of this inconsistent parsing performance was identified as a parsing bug within the Oracle Database software. The following workaround was implemented to mitigate the issue:

    ALTER SYSTEM SET "_fix_control"='13836796:OFF' SCOPE=BOTH SID='*';
    ALTER SYSTEM SET "_optimizer_cost_based_transformation"=OFF SCOPE=BOTH SID='*';
    

    Explanation of Parameters:

    • _fix_control='13836796:OFF': This is a hidden parameter used to disable a specific internal Oracle fix (identified by bug ID 13836796). Setting it to OFF reverts a change that might be causing the parsing issue.

    • _optimizer_cost_based_transformation=OFF: This hidden parameter controls whether the optimizer performs cost-based query transformations. Disabling it can prevent certain transformation paths that might interact negatively with the parsing bug, leading to more stable execution plans and faster parsing.

    Important Note:

    It is crucial to understand that setting hidden parameters (those prefixed with an underscore _) should generally be avoided without prior consultation and guidance from Oracle Support. Hidden parameters are internal to Oracle and their behavior or impact can change between database versions or even patches, potentially leading to unforeseen side effects or stability issues. Always open a Service Request (SR) with Oracle Support for confirmation and advice before applying such changes in a production environment.

    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