Archivo de la categoría: Oracle

Entradas sobre bases de datos Oracle

Bloques coruptos en una base de datos

Posted on por
Responder

Uno de los problemas a los que tenemos que enfrentarnos dia a dia es el de lidiar con bloques corruptos en la base de datos.

Vayamos al supuesto en el que alguna de nuestras herramientas (RMNA,EMC,dbvf, el propio motor en algun acceso) ha detectado que tenemos estos bloques corruptos. La manera de encontarlos es mediante la vista V$DATABASE_BLOCK_CORRUPTION 

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
	 FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
	 2      88231          1            6821577 NOLOGGING
	 2      58442          1            6821577 NOLOGGING

Recuperacion de bloques corruptos

La manera de recuperarlos es tan sencillo como decirle al RMAN que lo haga, para esto ejecutaremos el comando de rman RECOVER CORRUPTION LIST;: 
RMAN> RECOVER CORRUPTION LIST;
Starting recover at 14-JAN-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=206 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 14-JAN-18

Comprobacion de que han sido recuperados

Aunque rman nos haya dicho OK, deberemos revisar que los bloques estan correctos, para ello usaremos la opcion VALIDATE DATAFILE de RMAN aplicado al FILE# que nos indicaba la vista de bloques corruptos 
RMAN>  validate datafile 2;

Starting validate at 14-JAN-18
using channel ORA_DISK_1
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=2 name=/u01/app/oracle/ORASID/sysaux01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     0              21603        336384          41455048 

Finished validate at  14-JAN-18

Y si no lo ha solucionado?

Que ocurre si RMAN no ha podido recuperar el bloque corrupto?
En este caso el comando validate nos devolveria algo similar a 

RMAN> validate datafile 2;
Starting validate at 14-JAN-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=2 name=/u01/app/oracle/ORASID/sysaux01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     2              20225        99863           49937565
File Name: /u01/app/oracle/ORASID/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              26483
Index      0              24051
Other      0              29081
Finished validate at 14-JAN-18

Por que puede ser esto?
En el caso en que no resolvamos el problema, echaremos un vistazo al alert.log, 


ORA-01578: ORACLE data block corrupted (file # ORA-01578: ORACLE data block corrupted (file # 2, block # 58442)
ORA-01110: data file 2: '/u01/app/oracle/ORASID/sysaux01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

Lo que nos esta indicando este error es que el objeto se creo en modo nologging por lo que la base de datos no tiene informacion de como recuperarla, si queremos recuperar esta informacion deberemos de recrear el objeto ( y cruzar los dedos para que este objeto sea un indice y no datos de negocio)

COmo siempre podemos encontrar mas informacion al respecto en soporte Oracle en las notas:

  • How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY (Doc ID 819533.1)
  • ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING - Error explanation and solution (Doc ID 794505.1)
  • How to identify all the Corrupted Objects in the Database with RMAN (Doc ID 472231.1)

Checklist de SQLtuning en la version 12c

Posted on por
Responder

Hoy vamos a seguir con pequeñas notas sobre la nueva version 12c, en este caso veremos mejoras en la gestion de estadisticas y planes

Uso de Adaptative Execution Plans/adaptative query optimization

La nueva funcionalidad de los planes de ejecicion flexibles (también llamado optimización de querys flexibles) permite que el optimizador sea capaz de ajustar los planes en tiempo de ejecución y obtener información adicional que le permita obtener mejores planes de ejecución.
En ved de usar planes de ejecución fijos esta funcionalidad permite al optimizador el posponer el plan hasta el momento de la ejecución.
Esta funcionalidad se basa en dos métodos:

  • Adaptative plans: Se centra en mejorar el plan del optimizador en runtime
  • Adaptative statistics: Se centra en obtener estadísticas adicionales para mejorar las siguientes ejecuciones de una consulta

Adaptative plans

Muchas veces el optimizador falla en la cardinalidad de las consultas generando un plan deficiente ( default plan), la funcionalidad de adaptative plans ajusta el plan a las estadísticas actuales, que son mas exactas que las estadísticas iniciales que fueron obtenidas en una ejecución anterior. Cuando selecciona el plan el optimizador usará este plan en las siguientes ejecuciones (del child cursor)
Esta funcionalidad depende de los dos siguientes parámetros

optimizer_features_enable            string  12.1.0.2
optimizer_adaptive_reporting_only    boolean FALSE

Si ponemos el parámetro OPTIMIZER_ADAPTIVE_REPORTING_ONLY=TRUE el optimizador si que obtiene las estadísticas, pero no las usará (usará el default plan)
Lo que hace el optimizador con esta funcionalidad es que obtiene multiples subplanes para porciones del plan para determinar en tiempo de ejecución que método usar. Una vez el optimizador decide un plan dejará de recopliar estadísticas y usará este plan para las siguientes ejecuciones del child cursor
Podemos saber cuales de las SQL han usado esta funcionalidad mediante la nueva columna de la vista v$SQL IS_RESOLVED_ADAPTIVE_PLAN que tendría un Y
Cuando una consulta usa el Adptative Query Optimization el plan mostrado en el EXPLAIN PLAN no tiene por que ser el que ha usado, para ver el que ha usado deberíamos de usar la función XDBS_XPLAN.DISPLAY_CURSOR
Este método también es “muy útil” con las ejecuciones paralelas , aquí se usa una técnica llamada hybrid data distribution

Adaptative statistics

Las Adaptative statistics son usadas por el optimizador para lidiar con los predicados complejos. En la versión 12 el dynamic sampling ha sido renombrado como dynamic statistics y puede obtener estadísticas no solamente de una tabla sino también de joins y predicados del tipo group-by
Esto se gestiona mediante el parámetro OPTIMIZER_DYNAMIC_SAMPLING (modificable a nivel sesión),que puede tener valores entre 0 y 11

LEVEL

WHEN
DYNAMIC STATISTICS WILL BE USED

SAMPLE
SIZE (BLOCKS)

0

Switches
off dynamic statistics

N/A

1

At least one non-partitioned
table in the statement has no statistics

32

2(default)

One or
more tables in the statement have no statistics

This
setting is suitable for the majority of systems

64

3

Any
statement that meets level 2 criteria and any statement that has one or more
expressions used in the where clause predicates e.g. Where
substr(CUSTLASTNAME,1,3) or Where a + b =5

64

4

Any statement that meets level 3 criteria and any
statement that has complex predicates. An OR or AND operator between multiple
predicates on the same table

64

5

Any
statement that meets level 4 criteria

128

6

Any statement that meets level 4 criteria

256

7

Any
statement that meets level 4 criteria

512

8

Any statement that meets level 4 criteria

1024

9

Any
statement that meets level 4 criteria

4086

10

All statements

All Blocks

11

The
database determines automatically if dynamic statistics are required

Automatically
determined

AUTOMATIC REOPTIMIZATION

Muchas veces los Apdaptative plans no son posibles(queryes con joins ineficientes ..), en esos casos el optimizador opta por esta funcionalidad que es el automatic reoptimization, donde el optimizador cambia el plan para las siguientes ejecuciones.
El optimizador usa estos dos métodos

Statistics feedback

También llamado cardinality feedback , lo que hace el planificador en este caso es mejorar los planes en los que encuentra cardinalediades erróneas , cuando se usa eeste método el optimizador compara las estadísticas que tiene con las cardinalidades observadas durante la ejecución, en caso de que difieran significativamente el optimizador hace dos cosas:
1- Guarda la cardinalidad nueva en las estadísticas
2- Crea un SQLplan mejor para las siguientes ejecuciones de esta consilta
Performance feedback
Esta funcionalidad neceita tener el parámetro PARALLEL_DEGREE_POLICY=ADAPTATIVE
Está mas enfocado a el grado de paralelismo, tras la ejecución compara el grado de paralelismo elegido por el optimizador con el grado de paralelismo,si los dos varían significativamente, el optimizador lo marcará para reoptimizacion y guardará las estadísticas para un mejor plan en la siguientes execuciones

SQL Plan directives

SI

NO

Creados en shared pool y bajados a sysaux

Creados para SQL con cardinalidad incorrecta

NO Gestionados
por el optimizador (solo usados por)

NO para
recopilar estadísticas de objetos que la tienen mal

Uso avanzado de obtencion de estadisticas

La versión 12c nos aporta mejoras substanciales en lo que a la obtención de estadísticas se refiere

  • Estadisticas online para bulk-load
  • incremental statisticas
  • concurrent statistics
  • Extended statistics (gloumn group)

La version 12c introduce una mejora im

Online Statistics gathering for bulk-load

La version 12c introduce una mejora importante en la obtención de estadísticas en los procesos de carga BULK-LOAD, ahora el optimizador regoje estadísticas d manera automática en procesos de carga de este tipo, esto incluye los procesos deCTAS (create table as), INSERT INTO …

La base de datos obtendrá las estadísticas del objeto, es decir, si se hace sobre una tabla particionada obtendrá estadísticas a nuivel de tabla, pero no de paticion, si se hace sobre una partición si que obtiene estadísticas a nivel de partición , pero no a nivel global de la tabla.
La base de datos no obtendrá estadísticas en los casos de
• Esquema SYS
• Es una nested table
• Es un IOT (index organized table)

Incremental statistics

Antes de la 12c cuando había cambios en las filas de una de lsparticiones de la tabla cambiaban todaslas estadísticas de la tabla quedaban como STALE. En la 12c tenemos u nuevo parámetro llamado INCREMENTAL_STALENESS que nos permite determinar cuando las estadísticas de las particiones deben de ser consideradas como STALE.
El valor por defecto de este parámetro es NULL (lo que hace que se comporte como en la 11g)
Puede tomar los valores:
• USE_STALE_PERCENT: Las estadísticas de la partición no serán consideradas STALE hasta que el número de filas que se cambien no sea mayor del porcentaje que se indique ( 10% por defecto)
• USE_LOCKED_STATS: Si las estadísticas de la partición están bloqueadas se usarán para generar las estadísticas globales indepeneientemente de las filas que hayan sido modificadas
Otra mejora en las estadísticas incrementales está relaccionada con el EXCHANGE PARTITION, el Exchange partition permite meter los datos de una tabla como una partición de otra.

Concurrent statistics

Ahora es posible obtener estadísticas de la tabla y de los índices de manera concurrente,se puede configurar incluso que tablas particionadas quieres que usen esté método y cual no.
Para poder usar esta funcionalidad es necesario
• JOB_QUEUE_PROCESSES debe de ser mayor de 4
• Tener el resource manager habilitado

Esta funcionalidad usa la propiedad CONCURRENT del paquete DBMS_STATS en las prefrencias globales. Este puede tener 3 valoers
• MANUAL.concurrencia habilitada solo para las ejecuciones manuales
• AUTOMATIC: Concurrencia habilitado solo apra las automáticas
• ALL: habilitado para todas

El valor por defecto es OFF 

SELECT DBMS_STATS.GET_PREFS('CONCURRENT') FROM DUAL;
OFF

Extended statistics/column group

La idea de esta funcionalidad es la de obtener estadísticas en casos en que los predicados son complejos. Ahora se pueden hacer dos tipos mas de estadísticas:
• Column group statistics: Estadistias sobre grupos de columnas
• Expression statistics: Estadisticas sobre columnas que son parte de un Where

El proceso para obtener este tipo de estadistiacas es:
1-Habilitar la monitorización de la carga, para esto se usa el paquete SEED_COL_USAGE del DBMS_STATS
exec DBMS_STATS.SEED_COL_USAGE(null,null,600)
2-Ejecutas la carga de trabajo
3-Revisas el uso de las columnas con DBMS_STATS.REPORT_COL_USAGE
Select DBMS_STATS.REPORT_COL_USAGE(‘ESQUEMA’,’TABLA’) from dual
4-creas las estadisticas grupales que consideres con DBMS_STATS.CREATE_EXTENDED_STATS
Select DBMS_STATS.CREATE_EXTENDED_STATS(‘ESQUEMA’,’TABLA’) from dual

Uso de Adaptive SQL Plan Management (SPM)

El SPM es el mecanismo que tiene oracle dede la 11c para evitar que los planes de ejecución se degraden, el SPM captura los SQLplans, verifica su rendimiento y en caso de ser mejorables los evoluciona.

El optimizador solamente utiliza los “know plans”, si fijamos a TRUE el parámetro OPTIMIZER_CAPTURE_SQLPLAN_BASELINES, entonces capturará los planes, pero seguirá usando solo los conocidos. El trabajo nocturno DBMS_SPM.EVOLVE_SQL_PLAN_BASELINES comprueba los planes con carga mas alta y mira a ver si hay un plan mejor, para que , de manera manual el DBA lo evolucione y se use ese plan.
Este conjunto de planes conocidos es lo que llamamos una BASELINE
Esto forma parte del TUNNING PACK
SPM consiste en tres componentes
1-SQLPLAN baseline capture
2-SQLPLAN baseline selection
3-SQLPLAN baseline evolution

En la 12c Oracle ofrece el SPM Evolve Advisor que evoluciona los planes recientemente añadidos sn necesidad de que el DBA

Normalmente los pasos son:
• Create an evolve task
• (optionally) set evolve tas parameters
• Execute the evolve task
• Implement the recoomendatios in the task
• Report the task outcome

Checklist de informacion sobre usuarios en 12c con CDB/PDB

Posted on por
Responder

En esta entrada seguiremos con las cheklist de cosas a tener en cuenta en la nueva version 12c, en este caso trataremos la informacion sobre usuarios

Tenemos dos tipos de usuario.

  • Commonuser: Tendrá la misma identidad en el root y en los PDB donde se le den permisos
  • Local user: Solamente exisistirá en el PDB donde se declare.

Common users

  • Para crearlo has de estar logado al CDB$ROOT
  • El nombre debe de comenzar por c## o C## y contener solo caracteres ASCII o EBCDIC
  • Para indicar explícitamente que el usuario va a estar en todos los contenedores hay que poner la cápsula CONTAINER=ALL
  • Si te encuentras en el root y no indicas la cláusula CONTAINER se presupone que es ALL
  • Los usuarios common users no pueden tener objetos creados en sus esquemas
  • Para podrán navegar entre los contenedores en los que tengan los permisos SET CONTAINER y CREATE SESSION
  • Para poder crear mas usuarios comunes debe de tener los privilegios SET CONTAINER y CREATE USER
  • Un usuario comun puede hacer:

    Grant privileges a common users o common roles

  • Run anALTER DATABASE statement que especifiquen clausulas de recuperacion que afectan a todo el CDB

    Usuarios locales

  • No puedes tener usuarios locales llamados SYS o SYSTEM
  • No puedes definir usuarios locales el el ROOT$CDB
  • Los local users pueden administrar un PDB, incluido arrancarlo y/o abrirlo
  • Están limitados a su PDB, NO pueden hacer SET CONTAINER
  • No pueden comenzar por c## o C##
  • La cláusula CONTAINER=CURRENT debe de especificarse en su creación
  • Para poder crear mas usuarios locales
  • Para crearlo has de estar conectado al PDB donde quieres crearlo
  • Se puede dar privilegios con los comunes y que le den privilegios comunes
  • En la sintaxis SQL de estos usuarios la cláusula CONTAINER indica en que containers aplica el comando

    Privilegios globales y locales

  • Lo privilegios globales una deben de ser otorgados a PUBLIC
  • Un privilegio local solo puede usarse en el container donde ha sido otorgado, incluso si ese container es ROOT
  • Un usuario local solo puede tener privilegios locales, pero uno común puede tener globales y locales.
  • Se dan con GRANT y REVOKE, solo que hay que añadir la clausula del CONTAINER
  • Para poder dar SYSTEM PRIVILEGES has de ter el privilegio SET CONTAINER

    Roles locales y globales

  • Los roles globales se crean en root y existen en los containers presentes y futuros.
  • Los usuarios globales pueden crear roles globales y darlos a otros users globales o locales
  • Los usuarios locales no pueden crear roles globales pero si que pueden darlos a usuarios globales o locales
  • Los usuarios locales puedan grantcommon roles a usuarios globales o locales
  • Al igual que los nombres de usuarios, los nombres de roles globales han de empezar por C##o c##
  • Si creas un role global desde un container has de poner la cláusula CONTAINER=ALL
  • Si otorgas un role global a un user global sin añadir la cláusula CONTAINER se aplica solo al container en el que estás, aunque este sea el CDBROOT

    • Problemas con optachauto y resolucion de nombres (error code 238)

    Posted on por
    Responder

    Hoy vamos a ver una entrada rápida

    Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.

    Al intentar llevar a cabo el parcheado me devolvía el siguiente error:

    root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 
OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 

Patch version not found


OPatchauto session completed atSun Nov 18 15:56:20 2017 
Time taken to complete the session 0 minute, 7 seconds 

opatchauto bootstrapping failed with error code 238.

    La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .

    Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.

    El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:

    
10.0.0.1  SERVER server server.dominio  server-vip.dominio

    Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.

    Sin embargo, al cambiar esa linea por

    
10.0.0.1  server server.dominio
10.0.0.1  SERVER  SERVER.dominio 
10.0.0.1  serve-vip  server-vip.dominio

    Todo volvió a funcionar a la perfeccion.

    Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados