Mostrando entradas con la etiqueta Performance. Mostrar todas las entradas
Mostrando entradas con la etiqueta Performance. Mostrar todas las entradas

[ 2018-10-11 ]

ODC Appreciation Day: Minimizando contención con “scalable sequences” en Oracle 18c

Es la primera vez que participo en el Oracle Development Community Appreciation Day, promovido por Tim Hall  para contribuir con la comunidad publicando algo de información sobre la tecnología Oracle que utilizamos a diario. 
En mi caso, trataré en este artículo una nueva funcionalidad incorporada en el último release de Oracle Database 18c.

Con la versión 18.1, se ha introducido una nueva funcionalidad en la base de datos Oracle: Las  "secuencias escalables” o en inglés  "Scalable Sequences".
Se trata de la capacidad de poder crear secuencias escalables para mejorar el rendimiento durante la carga masiva de datos, en tablas que utilizan como claves el valor generado por una secuencia. Las secuencias escalables optimizan el proceso de generación de valores secuenciales mediante el uso de una combinación única del número de instancia y el número de sesión para minimizar la contención sobre los bloques “leaf” en índices durante cargas masivas. Esta es una de las pocas funciones que no es habilita automáticamente y requiere la intervención del DBA para garantizar que su implementación no afecte ni cambie la lógica de negocio necesaria.
Por su parte, desde el punto de vista de negocio, esta funcionalidad brinda una mejora notable en los procesos de carga masiva de datos al reducir, como comenté anteriormente, la contención generada al insertar  datos en tablas que utilizan valores de secuencia.
Al incorporar la capacidad de poder crear valores de secuencias con componente de instancia e identificadores de sesión agregados al valor propio de la secuencia, la contención en la generación  y en las inserciones en bloques de índice para los valores clave, se reduce significativamente. Esto significa que Oracle Database es aún más escalable para la carga de datos y puede admitir tasas de rendimiento en este tipo de operaciones todavía más altas.

[ 2018-07-24 ]

Privilegios necesarios para generar reportes AWR

Resulta bastante común que bajo ciertas situaciones especiales, o en determinados proyectos, haya usuarios no administradores requieran la posibilidad de ejecutar reportes AWR de una base de datos para analizar distintas cuestiones.
Para permitir esto, aplicando el principio de “mínimos privilegios”, podemos construir un role de base de datos con los "grants" necesarios para poder generar los reportes, y asignarlo luego a los usuarios que lo necesiten.

Los privilegios necesarios para generar un reporte son los siguientes:

grant select on sys.v_$database to rol_exec_awr;
grant select on sys.v_$instance to rol_exec_awr;
grant execute on sys.dbms_workload_repository to rol_exec_awr;
grant select on sys.dba_hist_database_instance to rol_exec_awr;
grant select on sys.dba_hist_snapshot to rol_exec_awr;

Veamos un ejemplo de como hacerlo:

Vamos a crear primero un usuario (awrusr) con privilegios de connect y resource para simular el usuario que necesita correr los reportes AWR. 

[oracle@server01 ~]$ sqlplus / as sysdba

SQL> create user awrusr identified by oracle
     default tablespace users
     temporary tablespace temp;

User created.

[ 2018-06-29 ]

Como verificar, habilitar y deshabilitar paralelismo SQL a nivel sesión

Para saber si está habilitada o no la ejecución de sentencias SQL con paralelismo en nuestra sesión,  podemos consultar la vista v$session. Con sentencias SQL me refiero a operaciones DDL, DML o consultas (queries). Necesitamos como mínimo tener privilegios de select_catalog_role o SELECT sobre la vista para poder hacerlo.
Los campos que nos muestran la información necesaria son:

PDML_ENABLED y  PDML_STATUS: Indican si las operaciones DML en paralelo esta habilitadas o no (ENABLE/DISABLE). Por defecto están deshabilitadas (DISABLED).
PDDL_STATUS:  Indica si está habilitado o no (ENABLE/DISABLE)  el paralelismo para sentencias DDL. Por defecto está habilitado (ENABLED).
PQ_STATUS:  Indica si el “parallel query” está habilitado o deshabilitado (ENABLE/DISABLE).  Por defecto está habilitado (ENABLED)

Veamos un ejemplo de como consultar la vista:

SQL> select PDML_ENABLED, PDML_STATUS, PDDL_STATUS, PQ_STATUS
           from v$session where sid = (select sid from v$mystat where rownum = 1);

PDML_ENABLED PDML_STATUS PDDL_STATUS PQ_STATUS
------------ ----------- ----------- ---------
NO           DISABLED    ENABLED     ENABLED

[ 2018-06-28 ]

Restaurando versiones previas de estadísticas (optimizer statistics)

En ciertos casos, es probable que luego de una actualización de estadísticas (en una o varias tablas y/o índices), el plan ejecución para ciertas consultas puede llegar a variar, ocasionando una posible degradación de la performance. Si bien está claro que las estadísticas “frescas” deberían a ayudar al optimizador (CBO) a seleccionar el mejor plan de ejecución posible, no siempre las cosas funciona de esta manera y por el contrario el rendimiento puede llegar a verse afectado. Si esta situación  ocurre  en un ambiente productivo, es probable que no tengamos mucho tiempo para analizar las causas  y determinar una posible solución.
Una buena opción para intentar  revertir el problema de manera rápida, es restaurar las estadísticas a valores previos.
Para esto, a partir de la versión 10g de Oracle Database, cuando nuevas estadísticas son tomadas en un objeto, los valores de la estadísticas anteriores son conservadas para que en el caso de ser necesario puedan ser restaurados.
Por defecto, el tiempo de retención de 31 días. Esto significa que serán conservadas todas las estadísticas tomadas durante ese periodo.

Podemos verificarlo con la siguiente consulta:

SQL> select DBMS_STATS.GET_STATS_HISTORY_RETENTION from dual;

GET_STATS_HISTORY_RETENTION
---------------------------
                         31

Si queremos modificar este tiempo de retención, podemos hacerlo ejecutando el siguiente procedimiento:

SQL> execute DBMS_STATS.ALTER_STATS_HISTORY_RETENTION (XXXX);

[ 2018-06-13 ]

El evento de espera: "Buffer Exterminate"

Dias atrás, analizando un problema de performance en una sentencia SQL, me encontré con un evento de espera a tope de un reporte ASH el cual no es muy común ver:  "buffer exterminate".
Profundizando un poco más sobre la causa de este evento, su origen y su impacto, pude allanar bastante el camino hacia la resolución del caso.
El reporte mostraba los siguientes indicadores:

[ 2018-05-13 ]

Oracle Database 18c: Utilizando Memoptimized Rowstore (Parte I)

Artículo publicado en Oracle Technology Network (OTN) en español -  mayo de 2018 


Introducción


En lo que a performance se refiere, uno de los new features más importantes de Oracle Database 18c, es Memoptimized Rowstore. Esta nueva funcionalidad provee una mejora notable en el rendimiento de aplicaciones que, cuando realizan consultas a la base de datos, acceden frecuentemente a tablas utilizando columnas con clave primaria, por ejemplo las aplicaciones del tipo “Internet of Things” (IoT),

La funcionalidad Memoptimized Rowstore posibilita la capacidad de fast lookup de datos sobre este tipo de tablas cuando se realizan esas consultas. Para ello, Oracle utiliza una nueva área de memoria SGA (System Global Area) llamada memoptimize pool,  la cual almacena índices tipo hash para las tablas que tienen habilitada la opción de fast lookup. Un hash index es una estructura interna que es mantenida en este nuevo pool, e indexa áreas de memoria para el acceso a través de claves primarias.

En esta primera parte del artículo, veremos de qué se trata esta nueva estructura de memoria y cómo podemos configurarla para posteriormente utilizarla. En la segunda, profundizaremos en detalle cómo utilizar la funcionalidad de Memoptimized Rowstore.
Memoptimize Pool:  una nueva área de memoria en la SGA

Al igual que ocurre con el In-Memory Column Store, el memoptimize pool es una subarea de memoria en la SGA que tiene como objetivo aportar funcionalidades para la mejora de rendimiento en la ejecución de consultas SQL.

Cuando una tabla del tipo heap-organized (el tipo de tabla default en bases de datos Oracle)  es definida como MEMOPTIMIZE FOR READ, este nuevo pool almacena buffers y estructuras relacionadas que permiten un acceso optimizado a esa tabla.

Esta estructura de memoria, le proporciona un excelente rendimiento y escalabilidad a consultas basadas en clave primaria. Para reducir el tiempo de respuesta “end-to-end”, los clientes extraen los búferes solicitados directamente desde la SGA a través de la red, evitando de esta manera el consumo de CPU y sobrecarga del sistema operativo en general. Por otro lado, las aplicaciones pueden beneficiarse del memoptimize pool sin necesitar cambios en su código.

[ 2018-02-20 ]

Oracle Database 12.2: Reportes AWR a nivel PDB

Artículo publicado en Oracle Technology Network (OTN) en español -  febrero de 2018 


Introducción

Desde su aparición en Oracle Database 10g, Automatic Workload Repository (AWR) ha ido evolucionando constantemente con el correr de las versiones.
Oracle 12c introdujo un gran cambio en la arquitectura de la base de datos incorporando el concepto de “multitenant”.  En el primer release de 12c, los reportes de AWR solamente pueden ser generados a nivel “Container Database” (CDB). Esto nos impide, en cierta manera, poder analizar en profundidad el comportamiento de determinadas PDBs puntuales.
La versión 12.2 introduce una notable mejora en AWR,  la capacidad de poder correr snapshots  tanto a nivel CDB como de PDB cuando trabajamos en ambientes “multitenant”.
Esta nueva característica nos permite un diagnóstico más granular de problemas de performance focalizados en una PDB en particular, situación que resulta sumamente interesante y útil en soluciones DBaaS donde se espera que el rol de DBA tienda a ser el de un “pDBA” ( Pluggable Database Administrator), es decir un DBA responsable de la administración de una o varias PDBs en particular, pero que a nivel físico comparten recursos con otras en el mismo CDB.

[ 2017-09-23 ]

Identificando el SQL_ID de una consulta


En el siguiente artículo vamos a ver dos métodos para obtener el SQL_ID de una sentencia utilizando una parte del texto de la misma (o una secuencia que nos permita identificarla).
Previamente generé una tabla "T1" con dos campos "C1 y C2" y un único registro, esta tabla la voy a utilizar para realizar una consulta y poder ejemplificar el procedimiento.

Ejecutamos una consulta sobre la tabla:

SQL> select c1, c2 from t1;

        C1 C2
---------- --------------------
         1 AAA

Al ejecutarse el query, pasa por todas las fases normales de procesamiento: 
- análisis de la sintaxis (parsing)
- análisis de las variables (binding)
- ejecución (executing)
- recuperación de datos (fetching)
Entre otras cosas se genera el plan de ejecución y se le asigna un "SQL_ID" a la sentencia.

Ahora utilizando la siguiente consulta a la vista  v$sql, vamos a buscar en la shared pool, el SQL_ID de la sentencia ejecutada, indicándole una porción del texto para poder  filtrar por el campo SQL_TEXT:

SELECT sql_id, plan_hash_value, substr(sql_text,1,40) sql_text
      FROM  v$sql
      WHERE sql_text like '%<PORCION DE TEXTO A BUSCAR>%'

[ 2017-07-04 ]

Optimizer with Oracle Database 12c Release 2 (White Paper)


Nuevo Oracle White Paper
Optimizer with Oracle Database 12c Release 2
 
Introduction
The Oracle Optimizer is one of the most fascinating components of the Oracle Database, since it is essential to the processing of every SQL statement. The optimizer determines the most efficient execution plan for each SQL statement based on the structure of the given query, the available statistical information about the underlying objects, and all the relevant optimizer and execution features. This paper introduces all of the new optimizer and statistics related features in Oracle Database 12c Release 2 and provides simple, reproducible examples to make it easier to get acquainted with them, especially when migrating from previous versions. It also outlines how existing functionality has been enhanced to improve both performance and manageability.

Some Oracle Optimizer features have been broken out of this paper and covered in their own.

Specifically, they are:
» Optimizer Statistics and Optimizer Statistics Advisor
» SQL Plan Management
» Approximate Query Processing

To get a complete picture of the Oracle Optimizer, it is recommended that you read this paper in conjunction with the relevant papers listed in the References section. See page 28 for details.


[ 2017-06-28 ]

Oracle GoldenGate Performance Best Practices (White Paper)

Oracle White Paper
Oracle GoldenGate Performance Best Practices

Introduction
The strategic integration of Oracle Exadata Database Machine and Oracle Maximum Availability Architecture (MAA) best practices (Exadata MAA) provides the best and most comprehensive Oracle Database availability solution. Oracle GoldenGate is a key component of MAA, providing a logical replication solution for fast platform migration and a near zero downtime solution for application and database upgrades. It complements the rest of Oracle’s MAA solution that tolerates failures and enables online maintenance and rolling upgrade through Oracle Real Application Clusters (Oracle RAC), Oracle Automatic Storage Management (Oracle ASM), and Oracle Active Data Guard.

This white paper describes best practices for configuring Oracle GoldenGate for the best performance, simple manageability, and stability for Oracle databases. Non-Oracle databases are not covered in this paper.
Refer to “Oracle GoldenGate with Oracle Real Application Clusters Configuration” MAA white paper at the link below for the initial configuration of Oracle GoldenGate, including installation, Oracle Database File System (DBFS) configuration for shared Oracle GoldenGate files, and Oracle Real Application Clusters (Oracle RAC) services configuration.

http://www.oracle.com/technetwork/database/availability/maa-gg-performance-1969630.pdf

[ 2017-06-15 ]

Gestión de "Hints" utilizando SQL Patch

En este post Adding and Disabling Hints Using SQL Patch escrito por Nigel Bayliss
se comenta un poco sobre los cambios incorporados a la API de SQL Patch en 12c Release 2, en esta versión la interfaz se ha mejorado bastante y resulta más facil de utilizar.
Como novedades interesantes, el texto para hints "hint_text" es ahora de tipo CLOB en vez de un varchar2 como lo era hasta 12c R1, además l aAPI incluye un nuevo parametro para el SQL_ID.

Podemos verlo con mas claridad en la documentación:


DBMS_SQLDIAG.CREATE_SQL_PATCH (
    sql_text        IN   CLOB,
    hint_text       IN   CLOB,
    name            IN   VARCHAR2   := NULL,
    description     IN   VARCHAR2   := NULL,
    category        IN   VARCHAR2   := NULL,
    validate        IN   BOOLEAN    := TRUE)
RETURN VARCHAR2;

DBMS_SQLDIAG.CREATE_SQL_PATCH (
    sql_id          IN   VARCHAR2,
    hint_text       IN   CLOB,
    name            IN   VARCHAR2   := NULL,
    description     IN   VARCHAR2   := NULL,
    category        IN   VARCHAR2   := NULL,
    validate        IN   BOOLEAN    := TRUE)
RETURN VARCHAR2;


Como DBAs, es muy probable que muchas veces hayamos encontrado sistemas en los cuales muchisimas sentancias SQL utilizan "Hints" casi como una política o regla de desarrollo. A veces resulta interesante poder averiguar si estos "Hints" realmente están ayudando o no a la ejecución de la consulta y también poder demostrarle a un "team" de desarrollo, que no siempre es tan útil el micro-management del Optimizador de Oracle. A veces, es posible que también que sea necesario aplicar "hints" sobre la marcha.

[ 2017-04-30 ]

The Oracle Optimizer: Explain the Explain Plan (White Paper)

Oracle White Paper
The Oracle Optimizer Explain the Explain Plan

Introduction
The purpose of the Oracle Optimizer is to determine the most efficient execution plan for your queries.
It makes these decisions based on the statistical information it has about your data and by leveraging Oracle database features such as hash joins, parallel query, partitioning, etc. Still it is expected that the optimizer will generate sub-optimal plans for some SQL statements now and then. In cases where there is an alternative plan that performed better than the plan generated by the optimizer, the first step in diagnosing why the Optimizer picked the sub-optimal plan is to visually inspect both of the execution plans.

Examining the different aspects of an execution plan, from selectivity to parallel execution and understanding what information you should be gleaming from the plan can be overwhelming even for the most experienced DBA. This paper offers a detailed explanation about each aspect of the execution plan and an insight into what caused the CBO to make the decision it did. 

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-explain-the-explain-plan-052011-393674.pdf

[ 2017-04-19 ]

Understanding Optimizer Statistics With Oracle Database 12c Release 2 (White Paper)

Oracle White Paper
Understanding Optimizer Statistics With Oracle Database 12c Release 2

Introduction
When the Oracle database was first introduced, the decision of how to execute a SQL statement was determined by a Rule Based Optimizer (RBO). The Rule Based Optimizer, as the name implies, followed a set of rules to determine the execution plan for a SQL statement.

In Oracle Database 7, the Cost Based Optimizer (CBO) was introduced to deal with the enhanced functionality being added to the Oracle Database at this time, including parallel execution and partitioning, and to take the actual data content and distribution into account. The Cost Based Optimizer examines all of the possible plans for a SQL statement and picks the one with the lowest cost, where cost represents the estimated resource usage for a given plan. The lower the cost, the more efficient an execution plan is expected to be. In order for the Cost Based Optimizer to accurately determine the cost for an execution plan, it must have information about all of the objects (tables and indexes) accessed in the SQL statement, and information about the system on which the SQL statement will be run.

This necessary information is commonly referred to as optimizer statistics. Understanding and managing optimizer statistics is critical for achieving optimal SQL execution. This whitepaper is the first in a two part series on optimizer statistics and describes the core concepts of what statistics are and what types are statistics are used by the Oracle Optimizer. The second paper in the series (Best Practices for Gathering Optimizer Statistics with Oracle Database 12c) covers how to keep optimizer statistics up-to-date so that they accurately represent the data that’s stored in the database.

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-statistics-concepts-12c-1963871.pdf


[ 2017-02-21 ]

SQL Plan Management with Oracle Database 12c Release 2 (White Paper)

Oracle White Paper
SQL Plan Management with Oracle Database 12c Release 2

Introduction

The performance of any database application heavily relies on consistent query execution. While the Oracle Optimizer is perfectly suited to evaluate the best possible plan without any user intervention, a SQL statement’s execution plan can change unexpectedly for a variety of reasons including regathering optimizer statistics, changes to the optimizer parameters or schema/metadata definitions.
The lack of a guarantee that a changed plan will always be better leads some customers to freeze their execution plans (using stored outlines) or lock their optimizer statistics. However, doing so prevents them from ever taking advantage of new optimizer functionality (like new access paths), that would result in improved plans. An ideal solution to this conundrum would preserve the current execution plans amidst environment changes, yet allow changes only for better plans.
SQL Plan Management (SPM) provides such a framework and allows for complete controlled plan evolution. With SPM the optimizer automatically manages execution plans and ensures that only known or verified plans are used. When a new plan is found for a SQL statement, it will not be used until it has been verified to perform better than the current plan.
This paper provides an in-depth explanation of how SPM works and why it should be a critical part of every DBAs toolkit. The paper is divided into three sections. The first section describes the fundamental aspects of SPM and how they work together to provide plan stability and controlled plan evolution. It then discusses how SPM interacts with other Oracle Database features that influence the optimizer plan selection. The final section provides a more step-by-step guide on how to use SPM to ensure consistent database and application performance during some of the more daunting tasks of a DBA, including upgrades.

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-sql-plan-mgmt-12c-1963237.pdf


[ 2016-12-28 ]

Efficient Statistics Maintenance for Partitioned Tables Using Incremental Statistics – Part 1

Concepts

What statistics are there on partitioned tables?  

Consider a partitioned table called SALES that has date-range partitions for financial quarters 1 and 2 (Q1 and Q2). The partition key is on the column QUARTER. The database gathers statistics for individual partitions so that cardinality can be estimated for queries that are pruned to a single partition. These are called partition-level statistics. To illustrate this with an example, I’m going to consider just a couple of statistics and ignore the others. The number of rows in Q1 and Q2 are 600 and 550 respectively. The number of distinct values (NDVs) for SALE_TYPE in Q1 is 30 and Q2 it’s 50:
Partition-level statistics

When a query is compiled, if the Oracle Optimizer determines that it will need to access a single partition (using partition pruning, for example) then the statistics at the partition-level
will be enough to help determine the execution plan. Here’s a query that reads Q1 only:

SELECT SUM(amount) FROM sales WHERE quarter = 'Q1' AND sale_type = 'DIRECT';

If the Optimizer determines at compile-time that a query has the potential to access more than one partition, then individual partition statistics are not enough. In the next example, the query needs to access more than one partition:

SELECT SUM(amount) FROM sales 
WHERE  sale_type = 'DIRECT';

Continuar aqui

[ 2016-12-15 ]

Optimizer with Oracle Database 12c Release 2 (White Paper)

Oracle White Paper
Optimizer with Oracle Database 12c Release 2

Introduction

The Oracle Optimizer is one of the most fascinating components of the Oracle Database, since it is essential to the processing of every SQL statement. The optimizer determines the most efficient execution plan for each SQL statement based on the structure of the given query, the available statistical information about the underlying objects, and all the relevant optimizer and execution features.
This paper introduces all of the new optimizer and statistics related features in Oracle Database 12c Release 21 and provides simple, reproducible examples to make it easier to get acquainted with them, especially when migrating from previous versions. It also outlines how existing functionality has been enhanced to improve both performance and manageability.
Some Oracle Optimizer features have been broken out of this paper and covered in their own. Specifically, they are:

» Optimizer Statistics and Optimizer Statistics Advisor
» SQL Plan Management
» Approximate Query Processing

http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-optimizer-with-oracledb-12c-1963236.pdf

[ 2016-11-14 ]

Database Manageability and Real Application Testing



Database Manageability and Real Application Testing
Demos and How To:
 Script: Oracle Database 11g Database Replay Workload Analyzer ZIP
 Screenwatch: Offline Analysis of Long Running SQL using SQL Monitoring Active ReportsScreenwatch
 Screenwatch: Detecting Unwanted Schema Changes in Real Time using Oracle Change Management Pack Screenwatch
 Screenwatch: Simplify Oracle Database Upgrades Using SQL Performance AnalyzerScreenwatch
 Script: RAC AWR report for Oracle Database 10 g Release 2 ZIP
 Script: RAC AWR report for Oracle Database 11 g Release 1 ZIP
 Examples and Scripts: Command Line Interface Usage of Database Replay ZIP
 Examples and Scripts: Oracle Database 9 i/10.1 to 10.2 Upgrade Use Case with SQL Performance Analyzer ZIP
 Oracle Database 11 g: Automatic SQL Tuning Viewlet
 Oracle Database 11 g: SQL Performance Analyzer Viewlet
 Oracle Database 11 g: Database Replay Viewlet
 Oracle Enterprise Manager 10 g: ADDM Overview  Viewlet
 Oracle Enterprise Manager 10 g: Analyzing ASH Reports Viewlet
 Oracle Enterprise Manager 10 g: Performance Page Overview Viewlet
 Oracle Database 10 g: Installation and Configuration on a Windows Platform Viewlet
 Oracle Database 10 g: Installation and Configuration on a UNIX Platform (Linux) Viewlet
 Oracle Database 10 g: Client Installation on a Windows Platform Viewlet
 Oracle Database 10 g: Upgrade Viewlet
 Oracle Database 10 g: Performance Diagnostics and SQL Tuning Viewlet
 Oracle Database 10 g: SQL Access Advisor Viewlet
 Oracle Database 10 g: Automatic Shared Memory Tuning Viewlet
 Oracle Database 10 g: Proactive Space Management and Segment Advisor Viewlet
 
Ref:  http://www.oracle.com/technetwork/database/manageability/demos-and-howtos-083960.html


[ 2016-08-19 ]

Gestionando AWR Baselines con DBMS_WORKLOAD_REPOSITORY

Creando una Baseline:

BEGIN
  DBMS_WORKLOAD_REPOSITORY.create_baseline (
    start_snap_id => 10,
    end_snap_id   => 100,
    baseline_name => 'AWR First baseline');
END;
/

NOTE: In 11g, there is a newly introduced procedure DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE that specifies a template for how baselines should be created for future time periods:

BEGIN
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE_TEMPLATE (
start_time => to_date('&start_date_time','&start_date_time_format'),
end_time => to_date('&end_date_time','&end_date_time_format'),
baseline_name => 'MORNING',
template_name => 'MORNING',
expiration => NULL ) ;
END;
/

"expiration => NULL" means that this baseline will be kept forever.

Eliminando AWR baseline:

BEGIN
    DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'AWR First baseline');
END;
/

[ 2016-07-16 ]

In-Memory Column Store: Cuando solo "In-Memory" no es suficiente

Comparto aqui, un nuevo artículo publicado en el sitio de OTN en español. Donde seguimos profundizando In-Memory Database, esta extraordinaria "new feature" de 12c.   
En esta oprtunidad, el artículo fué desarrollado junto a Joel Perez y Flávio Soares (publicado en el sitio de OTN - Oracle Technology Network - en español en Mayo de 2016).
Esta es una serie de artículos dedicados a la nueva funcionalidad “Oracle In-Memory Column Store”, presente en la versión de base de datos Oracle 12c. Oracle lleva muchos años permitiendo la lectura de bloques directamente desde memoria RAM por medio de la utilización del buffer cache (v$bh). A lo largo de todos estos años realizó un gran trabajo perfeccionando continuamente el algoritmo LRU que utiliza, con el fin de optimizar las búsquedas de bloques calientes y poder mantenerlos el mayor tiempo posible en memoria, logrando de esta manera un acceso más rápido y actuando como un verdadero “cache” para la base de datos.

[ 2016-06-29 ]

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)