El blogoracle de Javier Morales

lunes, mayo 13, 2013

100.000 gracias.

El blog ha llegado a superar las 100.000 visitas desde su creación.

¡Muchísimas gracias!

Migraciones con mínimo tiempo de parada con Oracle GoldenGate.

Últimamente estoy enfrentando migraciones que suponen cambios de plataforma, que los clientes utilizan para subir la base de datos de versión. Así pues, bases de datos en solaris versión Oracle10g (10.1 por ejemplo) que han de migrarse a un entorno Linux Oracle11g ó Oracle10g (versión 10.2).

Si la plataforma del sistema operativo fuera la misma (de solaris a solaris o de linux a linux) y la migración no implicase un cambio de versión, una de las opciones recomendadas es duplicar la base de datos, convertir el clon duplicado en base de datos standby, aplicar los logs en el momento de la puesta en producción y abrir la base de datos duplicada como principal.

Si hay subida de versión, en la máquina destino debe haber dos juegos de binarios: el mismo que el de origen, para realizar la restauración, y el juego de binarios de la nueva versión. Así, con el juego de binarios primero se realiza el duplicado y restauración, y con el segundo se abre la base de datos en modo "migrate" y se ejecutan los scripts de upgrade. Mientras dure el proceso la base de datos principal ha de estar parada y eso es un obstáculo.

Si bien las arquitecturas de sistema operativo son diferentes será necesario comprobar si el "endian" es distinto entre las dos plataformas. Existen dos tipos de endian, el pequeño y el grande. Entre plataformas de un mismo endian, basta con duplicar con RMAN la base de datos, pero si el endian es distinto (de little a big, o de big a little) requiere además convertir los ficheros y realizar la migración transportando tablespaces.

SQL> select * from v$transportable_platform
2 order by endian_format;

PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
----------- ---------------------------------------- --------------
3 HP-UX (64-bit) Big
6 AIX-Based Systems (64-bit) Big
18 IBM Power Based Linux Big
2 Solaris[tm] OE (64-bit) Big
4 HP-UX IA (64-bit) Big
16 Apple Mac OS Big
1 Solaris[tm] OE (32-bit) Big
9 IBM zSeries Based Linux Big
17 Solaris Operating System (x86) Little
19 HP IA Open VMS Little
20 Solaris Operating System (x86-64) Little
12 Microsoft Windows x86 64-bit Little
13 Linux x86 64-bit Little
8 Microsoft Windows IA (64-bit) Little
21 Apple Mac OS (x86-64) Little
11 Linux IA (64-bit) Little
5 HP Tru64 UNIX Little
10 Linux IA (32-bit) Little
7 Microsoft Windows IA (32-bit) Little
15 HP Open VMS Little

20 filas seleccionadas.

Existen varias soluciones para hacer una migración de este tipo con mínimo tiempo de parada, como utilizar streams o utilizar un dataguard lógico, pero Oracle GoldenGate es definitivamente uno de los mejores métodos y más versátiles para migrar tanto bases de datos enteras, como esquemas, realizando además cambios de versión y de plataforma sincronizando lógicamente dos entornos.

Los pasos a seguir serían los siguientes, tomando nodo1 y nodo2 como los dos servidores, origen y destino.

1.- Descargar el software de Oracle GoldenGate de eDelivery http://edelivery.oracle.com y descomprimirlo en ambos servidores.
(el registro es gratuíto, y su descarga con fines no comerciales también!)

host1@oracle $ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle

Version 11.2.1.0.1 OGGCORE_11.2.1.0.1_PLATFORMS_120423.0230_FBO

Solaris, sparc, 64bit (optimized), Oracle 10g on Apr 24 2012 09:06:57

GGSCI (host1) 1> create subdirs

Creating subdirectories under current directory /opt/oracle/product/OracleGG

Parameter files /opt/oracle/product/OracleGG/dirprm: already exists

Report files /opt/oracle/product/OracleGG/dirrpt: created

Checkpoint files /opt/oracle/product/OracleGG/dirchk: created

Process status files /opt/oracle/product/OracleGG/dirpcs: created

SQL script files /opt/oracle/product/OracleGG/dirsql: created

Database definitions files /opt/oracle/product/OracleGG/dirdef: created

Extract data files /opt/oracle/product/OracleGG/dirdat: created

Temporary files /opt/oracle/product/OracleGG/dirtmp: created

Stdout files /opt/oracle/product/OracleGG/dirout: created

2.- Chequear que la base de datos origen está en modo ARCHIVELOG

ARCHIVE LOG LIST;

3.- Activar el suplemental logging en la base de datos.

SELECT force_logging, supplemental_log_data_min FROM v$database;

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

ALTER DATABASE FORCE LOGGING;

ALTER SYSTEM SWITCH LOGFILE;

4.-Crear el usuario GoldenGate en la base de datos origen.

CREATE USER oggadm1 IDENTIFIED BY “13c1sa”;

GRANT dba TO oggadm1;

5.-Comprobar la visibilidad entre las bases de datos (todas).

host1@oracle $ tnsping b_new

TNS Ping Utility for Solaris: Version 10.2.0.5.0 - Production on 30-APR-2013 12:23:25

Used parameter files:

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = host2)(PORT = 1521))) (CONNECT_DATA = (SID = BBDD2)))

OK (320 msec)

6.-Configurar manager.

host1@oracle $ more GLOBALS

CheckpointTable oggadm1.oggchkp

host1@oracle $ more startup.oby

DBLogin UserID oggadm1@B, Password 13c1sa

Start Mgr

Info Mgr

Info CheckpointTable

Set Editor vi

GGSCI (host1) 1> Edit Param mgr

"/opt/oracle/product/OracleGG/dirprm/mgr.prm" [New file]

Port 15002

PurgeOldExtracts ./dirdat/*, UseCheckpoints

GGSCI (host1) 1> obey startup.oby

GGSCI (host1) 2> DBLogin UserID oggadm1@B, Password 13c1sa

Successfully logged into database.

GGSCI (host1) 3> Start Mgr

MGR is already running.

GGSCI (host1) 4> Info Mgr

Manager is running (IP port host1.15001).

GGSCI (host1) 5> Info CheckpointTable

No checkpoint table specified, using GLOBALS specification (oggad1.oggchkp)...

Checkpoint table oggad1.oggchkp does not exist.

GGSCI (host1) 6> Set Editor vi

7.-Crear la tabla de checkpoints.

GGSCI (host1) 7> Add CheckpointTable

No checkpoint table specified, using GLOBALS specification (oggadm1.oggchkp)...

Successfully created checkpoint table oggadm1.oggchkp.

8.- Crear el proceso EXTRACT

GGSCI (host1) 9> edit param extr

host1@oracle $ more /opt/oracle/product/OracleGG/dirprm/extr.prm

Extract extr

UserID oggadm1@B, Password 13c1sa

ExtTrail ./dirdat/aa

Table USUARIO1.*;

Table USUARIO2.*;

Table USUARIO3.*;

Table USUARIO4.*;

GGSCI (host1) 2> Add Extract extr, TranLog, Begin Now

EXTRACT added.

GGSCI (host1) 18> info all

Program Status Group Lag at Chkpt Time Since Chkpt

MANAGER RUNNING

EXTRACT STOPPED EXTR 00:00:00 00:00:44

9.- Arrancar el proceso EXTRACT en el servidor origen. Una vez arrancado lanzar un log switch y un EXPORT DATA PUMP de la base de datos principal sobre la réplica con la opción FLASHBACK_SCN=xxxxxxx. En este caso es el 501308592, correspondiente al FIRST_CHANGE del último redolog online.

10.- Añadir trandata para tablas en el servidor origen.

Add TranData

Add TranData USUARIO1.*

Add TranData USUARIO2.*

Add TranData USUARIO3.*

Add TranData USUARIO4.*

11.- Configurar manager en servidor de replica (pasos 6 y 7)

12.- Configurar pump en servidor principal.

GGSCI (host1) 2> edit param pump

"/opt/oracle/product/OracleGG/dirprm/pump.prm"
[New file]

Extract pump

RmtHost host2, MgrPort 15002, Compress

RmtTrail ./dirdat/ab

Passthru

Table USUARIO1.*;

Table USUARIO2.*;

Table USUARIO3.*;

Table USUARIO4.*;

"/opt/oracle/product/OracleGG/dirprm/pump.prm"
[New file] 8 lines, 969 characters

GGSCI (host1) 3> Add
Extract pump, ExtTrailSource ./dirdat/aa

EXTRACT added.

GGSCI (host1) 4> Add
RmtTrail ./dirdat/ab, Extract pump, megabytes 5

RMTTRAIL added.

GGSCI (host1) 5> info
all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING

EXTRACT     RUNNING     EXTR       
00:00:00      00:00:02

EXTRACT     STOPPED     PUMP       
00:00:00      00:00:11

13.- Configurar replicat en servidor replica.

GGSCI (host2) 10> edit param repl

Replicat repl

UserID oggadm1@B, password 13c1sa

AssumeTargetDefs

DiscardFile ./dirrpt/repl.dsc

Map USUARIO1.*, Target USUARIO1.*;

Map USUARIO2.*, Target USUARIO2.*;

Map USUARIO3.*, Target USUARIO3.*;

Map USUARIO4.*, Target USUARIO4.*;

GGSCI (host2) 11> Add
Replicat repl, ExtTrail ./dirdat/ab

REPLICAT added.

GGSCI (host2) 12> info
all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING

REPLICAT    STOPPED     REPL       
00:00:00      00:00:06

14.- Arrancar pump en servidor principal.

GGSCI (host1) 7> start extract pump

Sending START request to MANAGER ...

EXTRACT PUMP starting

GGSCI (host1) 8> info all

Program    
Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER    
RUNNING

EXTRACT    
RUNNING     EXTR        00:00:00      00:00:08

EXTRACT    
RUNNING     PUMP        00:00:00      00:13:38

GGSCI (host1) 9> info all

Program    
Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER    
RUNNING

EXTRACT    
RUNNING     EXTR        00:00:00      00:00:08

EXTRACT     RUNNING    
PUMP        00:00:00      00:00:09

14.- Importar el fichero de Export Data Pump generado en el paso 9.

15.- Arrancar replicat en replica al SCN de la exportación.

GGSCI (host2) 16> info
all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING

REPLICAT    STOPPED     REPL       
00:00:00      00:06:11

GGSCI (host1) 7> Start
Replicat, aftercsn 501308592

GGSCI (host2) 9> Start Replicat repl, aftercsn 501308592

Sending START request to MANAGER ...

REPLICAT REPL starting

GGSCI (host2) 10> info
all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING

REPLICAT    RUNNING     REPL       
00:00:00      00:00:06

Una vez las dos bases de datos están sincronizadas, toda la información del servidor principal se propaga a la base de datos réplica, que es idéntica en estructura a la base de datos principal. En el momento de la puesta en producción simplemente hay que cambiar los clientes para dirigirlos a la réplica.

miércoles, septiembre 12, 2012

Optimización SQL en Oracle. En venta, próximamente!

En breve estará a la venta mi libro "Optimización SQL en Oracle".

Durante los últimos dos años he estado escribiendo este libro que resume, a mi modo de ver, todo lo que un administrador o programador debería conocer para optimizar código SQL.

En él describo cómo funciona el optimizador y cómo se comporta el servidor para escoger los mejores planes de ejecución, los aspectos a considerar para crear tablas de diferentes tipos (tablas IOT, clusters, tablas particionadas, etc.) y lo mismo relativo a los índices. Herramientas para optimizar SQL, desde asesores a las herramientas "manuales" como explain plan, tkprof, autotrace, generación de trazas, análisis de AWR, etc.

Además, también dedico un apartado a los entornos datawarehouse, a optimización SQL de código ineficiente con casos prácticos resueltos, y un glosario completo de hints con ejemplos de su uso y "maluso", y sus consecuencias para el rendimiento.

Este libro responde preguntas y cuestiones habituales como el motivo por qué no siempre es eficiente acceder a las tablas usando índices, escenarios ineficientes, usos incorrectos de tipos de datos y sus consecuencias en la optimización, uso correcto del paralelismo, el particionamiento, las vistas materializadas, jerarquías, dimensiones, consecuencias de usar NOLOGGING, como tratar subconsultas, uso de IN y EXISTS, DISTINCT, ordenaciones, etc.

El esquema del libro es el siguiente:

Por el momento está en fase BETA, pendiente de revisión técnica. Para esta revisión cuento con dos administradores de los más fuertes de España, y vamos a asegurarnos que en las más de 300 páginas no se nos escapa un error.

Me gustaría decir, como los de Valve, "When it's done, it's done" como fecha de publicación, pero espero que en cosa de un par de meses pueda estar disponible a la venta.

Estoy contento porque se trata del primer libro en español que trata exclusivamente de optimización SQL y todo su universo. Muchos libros (principalmente en inglés) tratan de aspectos del rendimiento, sobre todo del motor (memoria, procesos) o se centran exclusivamente en administración o programación, pero éste es el primer libro que conozco absolutamente específico, en español, con ejemplos en español, tablas con nombres en cristiano (vuelos, reservas, etc.), sin ser una traducción de una obra en inglés o un copia/pega de partes de la documentación de Oracle.

Yo estoy satisfecho del resultado, y espero que pueda ser de utilidad. Estoy seguro de que incluso los usuarios más avanzados se sorprenderán aprendiendo cosas nuevas, o redefiniendo conceptos, o encontrando una forma práctica y accesible de resumir las funcionalidades y componentes que afectan a la eficiencia del servidor de base de datos.

Os dejo unas imágenes del libro, en fase BETA, listo para revisarlo y corregirlo antes de sacarlo a la luz.

jueves, febrero 23, 2012

El misterioso caso del error de "privilegios insuficientes" en la creación de vista materializada dentro de un procedimiento PL/SQL.

Recuerdo aquella vez que me pidieron crear un usuario para una aplicación en desarrollo. El usuario debía ser capaz de crear vistas y vistas materializadas, de modo que usé la siguiente sintaxis.

SQL> create user desarrollo identified by desarrollo;
User created.
SQL> grant connect, resource, create view, create materialized view to desarrollo;
Grant succeeded.

De este modo, creía yo, garantizaba que el usuario podría tener ese privilegio de forma explícita, y no mediante un rol, y así descartaba errores que podrían producirse por la no herencia de privilegios a través de roles en el uso de PL/SQL.

No obstante, el usuario vino a mi mesa a decirme: "No puedo crear vistas materializadas. Privilegios insuficientes".
-¿Cómo es posible? - pregunté sorprendido. - Te aseguro que el usuario tiene privilegios para crearlas.

De modo que abrí una consola de sqlplus y ejecuté:

SQL> create materialized view test as select * from dual;
Materialized view created.

- ¿Ves? El usuario tiene privilegios.
- Ya, pero es que yo lo ejecuto dentro de un procedimiento PL/SQL, mediante el comando EXECUTE IMMEDIATE. - contestó.
- Vamos a probar.

SQL> drop materialized view test;
Materialized view dropped.
SQL> begin
2 execute immediate 'create materialized view test as select * from dual';
3 end;
4 /
PL/SQL procedure successfully completed.
SQL> desc test
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY VARCHAR2(1)

- Pues no lo entiendo - argumentaba, sin salir de su asombro- mi procedimiento PL/SQL da error al ejecutarlo, y la sintaxis ejecutada en una consola de SQL no da errores.

¿qué podría ser? ¿por qué una vista materializada daba error en un procedimiento y no en un bloque anónimo?. Decidí hacer la prueba y comprobarlo por mi mismo. No podía creerlo.

SQL> drop materialized view test;

Materialized view dropped.

SQL> create procedure crea_mv_test as

2 begin

3 execute immediate 'create materialized view test as select * from dual';

4 end;

5 /

ERROR at line 1:

ORA-01031: insufficient privileges

ORA-06512: at "DESARROLLO.CREA_MV_TEST", line 3

ORA-06512: at line 1

El usuario tenía privilegios explícitos para crear una vista materializada, incluso desde un bloque anónimo, pero no tenía privilegios suficientes para crearla desde dentro de un procedimiento PL/SQL.

No tenía sentido. El mismo usuario podía lanzar esa sintaxis desde la línea de comandos de sqlplus, dentro de un bloque anónimo, pero no en la creación de un procedimiento PL/SQL.

Entonces vi la respuesta, como una luz guiando mis dedos a añadir la cláusula authid current_user.

Así fue. La ejecución del código funcionaba cuando se especificaba claramente que los privilegios debían ser los del usuario conectado y no los del creador del procedimiento.

SQL> create or replace procedure crea_mv_test authid current_user as

2 begin

3 execute immediate 'create materialized view test as select * from dual';

4 end;

5 /

Procedure created.

SQL> exec crea_mv_test;

PL/SQL procedure successfully completed.

- Añade esta cláusula al procedure y vuelve a ejecutarlo.

- Funciona! - Exclamó. - ¿Cómo es posible?

- Porque la cláusula authid current_user está heredando los privilegios del usuario que ejecuta el procedimiento, y no los privilegios que tiene el usuario creador del procedimiento.

- Pero, ¡Si se trata del mismo usuario! ¿qué sentido tiene?

Yo ya no atendía a sus planteamientos. Había resuelto el problema. El código se compilaba y ejecutaba correctamente. Las vistas materializabas se creaban todas en sucesión, sin mostrar ningún error. Mi trabajo estaba hecho. Pasó el tiempo, y nunca sabré si lo sucedido aquel día respondía a, lo que se suele llamar en los círculos técnicos, un "expected behaviour".

jueves, junio 23, 2011

Instalación Oracle Grid Control 11g para Solaris/Linux plataforma 64bit.

INGREDIENTES:

Java versión 1.6u18 (Descargar del archivo histórico de versiones antiguas de Java)

http://www.oracle.com/technetwork/java/archive-139210.html

NOTA: En Solaris es necesario descargar el bundle de JDK 32bit y las librerías de 64bit.

Java SE Development Kit 6u18
jdk-6u18-solaris-sparcv9.sh

Java SE Development Kit 6u18
jdk-6u18-solaris-sparcv9.tar.Z

Weblogic 10.3.2 (Descargar del archivo histórico de versiones de Weblogic)

http://www.oracle.com/technetwork/middleware/weblogic/downloads/wls-main-097127.html

Oracle11gR2 (11.2.0.2)

Oracle Grid Control 11.1.0.1

PASOS A SEGUIR:

1.- Instale la versión de java en un directorio a su gusto, y compruebe la versión.

oracle@leg93uxgrid:~$ /u01/app/oracle/java/jdk1.6.0_18/bin/java -version

java version "1.6.0_18"

Java(TM) SE Runtime Environment (build 1.6.0_18-b07)

Java HotSpot(TM) Server VM (build 16.0-b13, mixed mode)

2.- Tras comprobar con un xclock que las Xwindows están habilitadas, ejecute el weblogic invocando el java recién instalado.

oracle@leg00uxgrid:~$ /u01/app/jdk-6u18/jdk1.6.0_18/bin/java -d64 -jar /software/wls1032_generic.jar

Extracting 0%..................................................................................100%

2.1.- Escoger “Typical” con las opciones por defecto.

2.2.- En la última pantalla “Installation Complete” DESACTIVAR la opción de “Run Quickstar”.

2.3.- Done.

4.- SOLO EN LINUX. Instalar el parche de Weblogic WDJ7

oracle@leg00uxgrid:~$ /u01/app/Middleware/utils/bsu/bsu.sh

5.- Verifique los parches e instale el software de Oracle11g.

6.- Cree una base de datos para el respositorio del Grid Control.

6.1.- Escoger el modo “Personalizado” y desmarcar la opción “Configure Enterprise Manager”.

6.2.- En el apartado de componentes, desmarcar “Enterprise Manager Repository”.

6.3.- Definir los parámetros de procesos a más de 500 y session_cachad_cursors a 550

6.4.- Aumentar el datafile de UNDO a 2Gb

7.- Desactivar dbconsole y el repositorio de Enterprise Manager de la base de datos recién creada en caso de que exista (al haber ejecutado incorrectamente el paso 6.1).

oracle@leg93uxgrid:~$ emca -deconfig dbcontrol db -repos drop

STARTED EMCA at 13/06/2011 13:17:30

EM Configuration Assistant, Version 11.2.0.0.2 Production

Enter the following information:

Database SID: omsgrid

Listener port number: 1521

Password for SYS user:

Password for SYSMAN user:

----------------------------------------------------------------------

WARNING : While repository is dropped the database will be put in quiesce mode.

----------------------------------------------------------------------

Do you wish to continue? [yes(Y)/no(N)]: y

8.- Habilitar el usuario DBSNMP.

SQL> alter user DBSNMP account unlock;

User altered.

SQL> alter user DBSNMP identified by grid13c1sa;