Gestionando AWR SNAPSHOTS con DBMS_WORKLOAD_REPOSITORY

Como modificar la configuración de AWR SNAPSHOT

BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    retention => 43200,        -- Minutes (43200 = 30 Days).
                               -- Current value retained if NULL.
    interval  => 30);          -- Minutes. Current value retained if NULL.
END;
/

Creando un SNAPSHOT de forma manual:

BEGIN
  DBMS_WORKLOAD_REPOSITORY.create_snapshot();
END;
/

Eliminando AWR snaps de una rango determinado:

BEGIN
  DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(
low_snap_id=>40,
High_snap_id=>80);
END;
/

Ref: How to Generate an AWR Report and Create Baselines (Doc ID 748642.1)

Generación de reportes AWR utilizando scripts SQL

Automatic Workload Repository (AWR) is a collection of persistent system performance statistics owned by the SYS user. 
It resides in SYSAUX tablespace. 
By default snapshot are generated once every 60min and maintained for 8 days to ensure the capture of an entire week of performance data (7 days in Oracle 10g). 

An AWR report outputs a series of statistics based on the differences between snapshots that may be used to investigate performance and other issues.

Running a Basic Report

With appropriate licenses for AWR, you may generate an AWR report by executing
the following script and pick the two snapshots you want to use for the sample :

$ORACLE_HOME/rdbms/admin/awrrpt.sql

Depending on the reasons for collecting the report, the default can be used, or for a more focused view, a short 10-15 minute snapshot could be used.

You will also be asked for the format of the report (text or html) along with the report name.

Generating Various Types of AWR Reports

Workload Repository Views

Tenemos disponibles las siguientes workload repository views:

V$ACTIVE_SESSION_HISTORY - Displays the active session history (ASH) sampled every second.
V$METRIC - Displays metric information.
V$METRICNAME - Displays the metrics associated with each metric group.
V$METRIC_HISTORY - Displays historical metrics.
V$METRICGROUP - Displays all metrics groups.
DBA_HIST_ACTIVE_SESS_HISTORY - Displays the history contents of the active session history.
DBA_HIST_BASELINE - Displays baseline information.
DBA_HIST_DATABASE_INSTANCE - Displays database environment information.
DBA_HIST_SNAPSHOT - Displays snapshot information.
DBA_HIST_SQL_PLAN - Displays SQL execution plans.
DBA_HIST_WR_CONTROL - Displays AWR settings.

Ref: How to Generate an AWR Report and Create Baselines (Doc ID 748642.1)

Errores ORA- relacionados con Background Processes

A continuación algunos errores relacionados con background processes y las MOS Notes asociadas:

ORA-443 background process did not start
          See Note 18442.1 - OERR: ORA 443 background process <name> did not start

ORA-444 background process failed while starting
          See Note 18443.1 - OERR: ORA 444 background process <name> failed while starting

ORA-445 background process did not start after seconds
          See Note 18444.1 - OERR: ORA 445 background process <name> did not start after <num> seconds

ORA-446 background process started when not expected
          See Note 18445.1 - OERR: ORA 446 background process started when not expected

ORA-447 fatal error in background process
          See Note 18446.1 - OERR: ORA 447 fatal error in background process

High Availability Best Practices: Oracle Database In-Memory (White Paper)

Oracle Database In-Memory

High Availability Best Practices

Oracle White Paper

Introduction

Oracle Database In-Memory (Database In-Memory) introduces dramatically better performance for analytic queries. Because the In-Memory column store has been seamlessly integrated into Oracle Database, all of the high availability benefits that come from the Maximum Availability Architecture (MAA) are inherited when implementing Database In-Memory. With generic MAA best practices as described in the HA documentation or MAA white papers located inwww.oracle.com/goto/maa, Oracle Database In-Memory can be configured to tolerate instance and node failures, protect and repair from data corruptions quickly, to fail over in the case of cluster, database failures or disasters in a timely manner and to address various planned maintenance activities with near zero database downtime. This paper focuses on additional best practices to achieve high availability and high performance application services for Oracle Database In-Memory during planned maintenance activities and failures.

http://www.oracle.com/technetwork/database/availability/dbim-maa-2658757.pdf