Sunday, December 10, 2017

Data Guard concepts and processes

Data Guard Modes include the following three:
- Maximum Protection
- Maximum Availability
- Maximum Performance

Physical
Logincal
Snapshot

In the physical standby database, your standby database is identical to the primary database, even at the block level. So the redo from the Primary could be applied directly to Standby.
MRP - Managed Recovery Process applies the redo entries from archived logs (or from 12c redo logs) to Physical Standby


Logical Standby database is different. It is independent database and its DB name is different from Primary Database.
LSP - Logical Standby Process applies the redo records from archived logs (or from 12c redo logs) to Logical Standby. LSP reads redo and convert it to SQL statement. LSP not applies redo, but applies SQL statement eventually.
Because SQL statements applies then the Logical Standby DB can be higher version of database or lower version. That's why we use Logical Standby DB in case of rolling upgrade.
Standby Logical Database is more resource usage consumable. Because we use LogMiner and other BG processes to read redo, to convert redo into SQL, to evaluate SQL statement, to apply SQL statement. We experience little more overhead that with physical stb db, but it is acceptable.


Friday, May 26, 2017

SQL Server Index and Statistics Maintenance

https://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html

Monday, May 22, 2017

Oracle waits прозрачно

https://sites.google.com/site/embtdbo/wait-event-documentation/oracle-io-waits

Tuesday, May 09, 2017

Linux 'screen' command

It is very useful to use screen in the terminal leaving your session at work with a process and return to it at home. Below is example with steps sequence of using the 'screen'. 

$ script -c 'screen' /dev/null

$ screen -ls
There are screens on:
        32156.pts-8.host022     (Attached)
        25681.xdbfix    (Attached)
        3074.pts-8.host022      (Attached)
        25658.pts-2.host022     (Attached)
        1289.pts-11.host022     (Detached)
5 Sockets in /var/run/screen/S-oracle.



$ screen -r 1289.pts-11.host022

Wednesday, May 03, 2017

Multiple AWR reports with one hour break up

It seems strange, but sometimes Application support asks about AWR Reports on 1-2 days with one hour break up.

In this case it is useful  multiple_awr.sql script from
https://oracle-base.com/dba/script?category=10g&file=generate_multiple_awr_reports.sql

First to identify snap range for the date you can use the following:
set linesize 500
set head off
--col snap_id for a45
col begin_interval_time for a30
select snap_id,begin_interval_time,end_interval_time from dba_hist_snapshot
where trunc(begin_interval_time) = to_date('03/05/2017','DD/MM/YYYY')
order by snap_id;

and then use the multiple_awr.sql script replacing values of the: 
  l_snap_start       NUMBER := 7724;
  l_snap_end         NUMBER := 7730;

------- multiple_awr.sql ----------------------------------------------------------------------------

-- File Name    : http://www.oracle-base.com/dba/10g/generate_multiple_awr_reports.sql
-- Author       : DR Timothy S Hall
-- Description  : Generates AWR reports for all snapsots between the specified start and end point.
-- Requirements : Access to the v$ views, UTL_FILE and DBMS_WORKLOAD_REPOSITORY packages.
-- Call Syntax  : Create the directory with the appropriate path.
--                Adjust the start and end snapshots as required.
--                @generate_multiple_awr_reports.sql
-- Last Modified: 02/08/2007
-- -----------------------------------------------------------------------------------
CREATE OR REPLACE DIRECTORY awr_reports_dir AS '/tmp/awr';

DECLARE
  -- Adjust before use.
  l_snap_start       NUMBER := 7724;
  l_snap_end         NUMBER := 7730;
  l_dir              VARCHAR2(50) := 'AWR_REPORTS_DIR';

  l_last_snap        NUMBER := NULL;
  l_dbid             v$database.dbid%TYPE;
  l_instance_number  v$instance.instance_number%TYPE;
  l_file             UTL_FILE.file_type;
  l_file_name        VARCHAR(50);

BEGIN
  SELECT dbid
  INTO   l_dbid
  FROM   v$database;

  SELECT instance_number
  INTO   l_instance_number
  FROM   v$instance;

  FOR cur_snap IN (SELECT snap_id
                   FROM   dba_hist_snapshot
                   WHERE  instance_number = l_instance_number
                   AND    snap_id BETWEEN l_snap_start AND l_snap_end
                   ORDER BY snap_id)
  LOOP
    IF l_last_snap IS NOT NULL THEN
      l_file := UTL_FILE.fopen(l_dir, 'awr_' || l_last_snap || '_' || cur_snap.snap_id || '.htm', 'w', 32767);

      FOR cur_rep IN (SELECT output
                      FROM   TABLE(DBMS_WORKLOAD_REPOSITORY.awr_report_html(l_dbid, l_instance_number, l_last_snap, cur_snap.snap_id)))
      LOOP
        UTL_FILE.put_line(l_file, cur_rep.output);
      END LOOP;
      UTL_FILE.fclose(l_file);
    END IF;
    l_last_snap := cur_snap.snap_id;
  END LOOP;

EXCEPTION
  WHEN OTHERS THEN
    IF UTL_FILE.is_open(l_file) THEN
      UTL_FILE.fclose(l_file);
    END IF;
    RAISE;
END;
/
=============

Monday, April 10, 2017

How to identify ORACLE_HOME of an Oracle instance process?

How to identify ORACLE_HOME of an Oracle instance process?
Use strings /proc//environ | grep ORACLE_HOME

For, instance,
ps -ef|grep pmon
oracle 9466     1  0  2016 ?        00:29:36 ora_pmon_DBName

$ strings /proc/9466/environ | grep ORACLE_HOME
ORACLE_HOME=/oracle/app/product ...

Friday, March 17, 2017

oracle preinstall

# cd /etc/yum.repos.d
# wget http://public-yum.oracle.com/public-yum-ol6.repo

oracle-rdbms-server-11gR2-preinstall
oracle-rdbms-server-12cR1-preinstall

echo "proxy=http://Proxy:Port/" >> /etc/yum.conf

Thursday, March 02, 2017

No incremental levels for DB INCR in v$rman_backup_job_details

It is advised to use V$RMAN_BACKUP_JOB_DETAILS to identify status of backup jobs. But it is difficult to understand when it was taken full backup of Oracle DB due to in the INPUT_TYPE of the output you can find "DB INCR" value as for FULL Incremental level 0 backups as for Incremental level 1 backups.

You can find way to clarify incremental levels or to find out when was taken FULL backup with the V$BACKUP_SET_DETAILS view.

For instance,
select * from V$BACKUP_SET_DETAILS  where BACKUP_TYPE='I' and INCREMENTAL_LEVEL='0'