Auditoria en Oracle 11g

Posted by josefabre | Posted in Administración, Aplicaciones, Base de Datos, Oracle, Proyectos, Software Libre, Unix/Linux | Posted on 15-05-2014

Tags: , ,

4

AUDITORIA EN ORACLE

VERSIÓN: 11G




  1. Auditoria informática
  2. Auditoria en Oracle
  3. Tablas y Vistas
  4. Comprobar activación de auditoria
  5. Comandos audit y noaudit
  6. Consultas de auditoria
  7. Descripción de tablas de auditoria

Auditoria informática

Consiste en recoger, agrupar y evaluar evidencias para determinar si un sistema de información salvaguarda el activo empresarial, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organización, utiliza eficientemente los recursos, y cumple con las leyes y regulaciones establecidas.

Auditoria para Oracle

En el caso de Oracle, la auditoría es un conjunto de características que permite al administrador de la base de datos y a los usuarios hacer un seguimiento del uso de la base de datos. El administrador de base de datos puede definir la actividad de auditoría predeterminada. La información de las auditorías se almacena en el diccionario de datos, en la tabla SYS.AUD$ o en la pista de auditoría del sistema operativo (si lo permite). Lo anterior viene definido en el parámetro audit_trail.

Se pueden auditar tres tipos de acciones: intentos de inicio de sesión, accesos a objetos y acciones de la base de datos. Cuando se realizan auditorías, la funcionalidad de la base de datos es dejar constancia de los comandos correctos e incorrectos. Esto puede modificarse cuando se configura cada tipo de auditoría.

 Tablas y Vistas

Oracle almacena en la tabla SYS.AUD$ o en la pista de auditoría del sistema operativo (si lo permite).

Existen varias vistas que se usan para ayudar a la extracción de los datos  deseado en una auditoria en esta tabla (SYS.AUD$).

  • ALL_AUDIT_POLICIES
  • ALL_AUDIT_POLICY_COLUMNS
  • ALL_DEF_AUDIT_OPTS
  • ALL_REPAUDIT_ATTRIBUTE
  • ALL_REPAUDIT_COLUMN
  • APEX_DEVELOPER_AUDIT_LOG
  • DBA_AUDIT_EXISTS
  • DBA_AUDIT_OBJECT
  • DBA_AUDIT_POLICIES
  • DBA_AUDIT_POLICY_COLUMNS
  • DBA_AUDIT_SESSION
  • DBA_AUDIT_STATEMENT
  • DBA_AUDIT_TRAIL
  • DBA_COMMON_AUDIT_TRAIL
  • DBA_FGA_AUDIT_TRAIL
  • DBA_OBJ_AUDIT_OPTS
  • DBA_PRIV_AUDIT_OPTS
  • DBA_REPAUDIT_ATTRIBUTE
  • DBA_REPAUDIT_COLUMN
  • DBA_STMT_AUDIT_OPTS
  • GV_$XML_AUDIT_TRAIL
  • KU$_AUDIT_DEFAULT_VIEW
  • KU$_AUDIT_OBJ_BASE_VIEW
  • KU$_AUDIT_OBJ_VIEW
  • KU$_AUDIT_VIEW
  • KU$_PROC_AUDIT_VIEW
  • KU$_PROCDEPOBJ_AUDIT_VIEW
  • KU$_PROCOBJ_AUDIT_VIEW
  • KU$_10_1_AUDIT_VIEW
  • MGMT$AUDIT_LOG
  • MGMT$ESA_AUDIT_SYSTEM_REPORT
  • SM$AUDIT_CONFIG
  • USER_AUDIT_OBJECT
  • USER_AUDIT_POLICIES
  • USER_AUDIT_POLICY_COLUMNS
  • USER_AUDIT_SESSION
  • USER_AUDIT_STATEMENT
  • USER_AUDIT_TRAIL
  • USER_OBJ_AUDIT_OPTS
  • USER_REPAUDIT_ATTRIBUTE
  • USER_REPAUDIT_COLUMN
  • V_$XML_AUDIT_TRAIL
Estas vistas se pueden ver ejecutando la consulta SQL:

SELECT view_name
FROM dba_views
WHERE view_name LIKE ‘%AUDIT%’
ORDER BY view_name

Las principales son:

– DBA_AUDIT_OBJECT: guarda la información relativa a la auditoría de



– DBA_AUDIT_SESSION: guarda la información relativa a la auditoría de los inicios de sesión de los usuarios.



– DBA_AUDIT_TRAIL: muestra la auditoría estándar (de la tabla AUD$)



– USER_AUDIT_TRAIL: muestra la auditoría estándar (de la tabla AUD$) relativa al usuario actual



– DBA_FGA_AUDIT_TRAIL: muestra información de auditoría de grano fino (obtenida de FGA_LOG$). La auditoría de grano fino (FGA) extiende la auditoría estándar y, además, captura la sentencia SQL que ha sido ejecutada.


Nota: Todo lo anterior estará condicionado al tipo de auditoría que se haya establecido para la base de datos Oracle,

Comprobar activación de auditoría

La activación de la auditoría en Oracle  viene definida por el valor del parámetro: audit_trail.

Para comprobar si la auditoría de la base de datos está activa ejecutamos el siguiente query :

select name, value
from v$parameter
where name like ‘audit_trail’
Valores:

– none: desactiva la auditoría de la base de datos.



– os: activa la auditoría de la base de datos. Los sucesos auditados se escribirán en la pista de auditoría del sistema operativo, no se auditará en Oracle sino en el sistema operativo anfitrión. Esta opción funcionará dependiendo del sistema operativo.



– db: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle.



– db, extended: activa la auditoría y los datos se almacenarán en la taba SYS.AUD$ de Oracle. Además se escribirán los valores correspondientes en las columnas SQLBIND y SQLTEXT de la tabla SYS.AUD$.



– xml: activa la auditoría de la base de datos, los sucesos será escritos en ficheros XML del sistema operativo.



– xml, extended: activa la auditoría de la base de datos, los sucesos será escritos en el formato XML del sistema operativo, además se incluirán los valores de SqlText y SqlBind.


Activa la auditoria
ALTER SYSTEM SET audit_trail = “DB” SCOPE=SPFILE;
Desactivar la auditoria
ALTER SYSTEM SET audit_trail = “NONE” SCOPE=SPFILE;
Nota: En Oracle 11g la auditoria viene activada por defecto, el valor del parámetro “audit_trail” está a “DB”.

Comandos audit y noaudit

Audit

Este comando puede funcionar aunque no esté activada la auditoría de la base de datos. Pero no dejara registro alguno guardado.

Auditorías de inicio de sesión

audit session;

Nota: Auditará tanto los intentos fallidos como los aciertos.

             Sólo los intentos fallidos : audit session whenever not successful;

             Sólo los intentos fallidos : audit session whenever  successful;


Auditorías de acción

Nota: Cualquier acción que afecte a un objeto de la base de datos (tabla, enlace de base de datos, espacio de tablas, sinónimo, segmento de anulación, usuario, índice, etc.) puede auditarse

audit role; 

Nota: Este comando activará la auditoría de las acciones: create rolealter roledrop role y set role.
Auditar a un usuario al realizar la acción “update” :

audit update table by nombre_usuario;



Auditorías de objeto


Auditar las acciones de manipulación de datos sobre objetos.

Por ejemplo, para auditar los “insert” realizados sobre una  tabla:

audit insert on <TABLA> by access;


Nota: al indicar “by access” hay que tener cuidado pues registrará un suceso de auditoría por cada insert, esto puede afectar al rendimiento. De ser así siempre será mejor optar por “by session” que sólo registrará un suceso de auditoría por sesión, aunque es menos exaustivo.

Sintaxis
AUDIT { sql_statement_clause | schema_object_clause | NETWORK } [ BY { SESSION | ACCESS } ] [ WHENEVER [ NOT ] SUCCESSFUL ] ; 
  • sql_statement_clause: activa la auditoría para una sentencia SQL concreta.
  • schema_object_clause: activa la auditoría para un objeto concreto de la base de datos.
  • WHENEVER SUCCESSFUL: activa la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que se completen con éxito.
  • WHENEVER NOT SUCCESSFUL: activa la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que originen error.


Noaudit

La instrucción noaudit se utiliza para detener la actividad de auditoría que se había activado previamente con la instrucción audit.

La instrucción noaudit debe tener la misma sintaxis que la instrucción audit que queramos detener.

Por ejemplo, si hemos auditado un usuario con:

audit session by alonso;

Auditará los inicios de sesión para el usuario de Oracle “alonso”, tanto los fallidos como los correctos. Para desactivar esta auditoría ejecutaremos el comando:
noaudit session by alonso;


Sintaxis

NOAUDIT { sql_statement_clause | schema_object_clause | NETWORK} [ WHENEVER [ NOT ] SUCCESSFUL ] ;  
  • sql_statement_clause: detiene la auditoria de una sentencia SQL concreta.
  • schema_object_clause: detiene la auditoría para un objeto concreto de la base de datos.
  • WHENEVER SUCCESSFUL: detiene la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que se completen con éxito.
  • WHENEVER NOT SUCCESSFUL: detiene la auditoría sólo para operaciones e instrucciones SQL en objetos de esquema que originen error.

Consultas de auditoria

  • Auditoria en inicio de sesión :
    select OS_Username Usuario_SO, Username Usuario_Oracle, Terminal ID_Terminal, DECODE (Returncode, '0', 'Conectado', '1005', 'Fallo - Null', 1017, 'Fallo', Returncode) Tipo_Suceso, TO_CHAR(Timestamp, 'DD-MM-YY HH24:MI:SS') Hora_Inicio_Sesion, TO_CHAR(Logoff_Time, 'DD-MM-YY HH24:MI:SS') Hora_Fin_Sesion from DBA_AUDIT_SESSION;
  • Auditoria por acción :
    select OS_Username Usuario_SO, Username Usuario_Oracle, Terminal ID_Terminal, Owner Propietario_Objeto, Obj_Name Nombre_Objeto, Action_Name Accion, DECODE (Returncode, '0', 'Realizado', 'Returncode') Tipo_Suceso, TO_CHAR (Timestamp, 'DD-MM-YY HH24:MI:SS') Hora from DBA_AUDIT_OBJECT;

    Descripción de tablas de auditoria

    Estructura de la tabla SYS.AUD$:

Campo Tipo de datos Tamaño Permite nulos
SESSIONID NUMBER 22 N
ENTRYID NUMBER 22 N
STATEMENT NUMBER 22 N
TIMESTAMP# DATE 7 Y
USERID VARCHAR2 30 Y
USERHOST VARCHAR2 128 Y
TERMINAL VARCHAR2 255 Y
ACTION# NUMBER 22 N
RETURNCODE NUMBER 22 N
OBJ$CREATOR VARCHAR2 30 Y
OBJ$NAME VARCHAR2 128 Y
AUTH$PRIVILEGES VARCHAR2 16 Y
AUTH$GRANTEE VARCHAR2 30 Y
NEW$OWNER VARCHAR2 30 Y
NEW$NAME VARCHAR2 128 Y
SES$ACTIONS VARCHAR2 19 Y
SES$TID NUMBER 22 Y
LOGOFF$LREAD NUMBER 22 Y
LOGOFF$PREAD NUMBER 22 Y
LOGOFF$LWRITE NUMBER 22 Y
LOGOFF$DEAD NUMBER 22 Y
LOGOFF$TIME DATE 7 Y
COMMENT$TEXT VARCHAR2 4000 Y
CLIENTID VARCHAR2 64 Y
SPARE1 VARCHAR2 255 Y
SPARE2 NUMBER 22 Y
OBJ$LABEL RAW 255 Y
SES$LABEL RAW 255 Y
PRIV$USED NUMBER 22 Y
SESSIONCPU NUMBER 22 Y
NTIMESTAMP# TIMESTAMP(6) 11 Y
PROXY$SID NUMBER 22 Y
USER$GUID VARCHAR2 32 Y
INSTANCE# NUMBER 22 Y
PROCESS# VARCHAR2 16 Y
XID RAW 8 Y
AUDITID VARCHAR2 64 Y
SCN NUMBER 22 Y
DBID NUMBER 22 Y
SQLBIND CLOB 4000 Y
SQLTEXT CLOB 4000 Y
OBJ$EDITION VARCHAR2 30 Y

RECUPERACIÓN ANTE DESASTRES – ORACLE DataGuard 11.2.0.4

Posted by josefabre | Posted in Administración, Aplicaciones, Base de Datos, Entrenamiento, Opinión, Oracle, Software Libre, Tips, Unix/Linux | Posted on 12-05-2014

Tags: ,

2

 

RECUPERACIÓN  ANTE DESASTRES

 

Guía de instalación para Oracle Data Guard
Base de datos 11g
Version 11.2.0.4

 

Índice General
1.       Introducción
2.     Arquitectura de data guard 11g
3.     Datos Generales
4.      Consejos (antes de empezar)
5.      Configurar servidor principal (Producción)
6.     Obtener los archivos de parámetros.
7.      Sincronizados los servidores con RMAN
8.      Sincronizados los servidores con Duplicate
9.      Configurar servidor secundario (Standby)
10.   Enviar archivelog’s (Switch log file)
11.   Convertir servidor secundario a principal (Switchover)
12.   Hacer permanente servidor secundario principal (Failover)   
13.   Conclusiones
1.  Introducción

 

En la mayoría de empresas se han ido implantando durante los últimos años planes de recuperación ante desastres o DR (Disaster Recovery). Estos planes comprenden un conjunto de recursos hardware, software y procedimientos que deben permitir a una empresa continuar ofreciendo sus servicios (o los considerados mínimos) en caso de que ocurran problemas graves en los sistemas informáticos.

En el caso de Oracle y para intentar minimizar este tipo de problemas, existen configuraciones de DR data guard que nos permiten mantener en ubicaciones físicamente separadas sistemas de contingencia denominados standby que podrán seguir dando servicio en caso de caída de los sistemas principales.

El concepto de Alta disponibilidad o HA (High Availability) es indispensable en una empresa por lo que DR. puede  disponer de discos, o tarjetas de red duplicados en un servidor es una solución de alta disponibilidad (HA), disponer de un segundo servidor en otra ciudad replicado con el primero es protección ante desastres (DR).

Finalmente existen las soluciones que nos aporta Oracle: las BDD Standby y el producto DataGuard (que ya viene integrado en las BDD EE) “.Solo aplicable para Enterprise Edition”

Una BDD Standby física (existen Standby “lógicas” de las que hablaremos en otra ocasión) es una copia “bit a bit” de nuestra BDD productiva, separada de ésta varias decenas, centenares o miles de kilómetros. Los cambios se trasmiten de la principal a la Standby y se aplican posteriormente en ésta.

Las trasmisiones de datos se realizan de manera comprimida y optimizada ocupando un mínimo de ancho de banda, y los datos pueden aplicarse en la standby “al momento” o con un cierto retardo, de manera que en caso de errores lógicos (modificación o borrado por error de gran cantidad de datos en la principal) se pueda ir a consultar los datos “del pasado” en la standby.


2. Arquitectura

 

3. Datos Generales
Sistema Operativo
Oracle Linux Server release 6.4  
Instaladores del software Oracle 12c 

*Para descargar los instaladores se debe crear una cuenta en Oracle http://www.oracle.com/ y descargar los  paquetes de 12.1.0.1 para Linuxhttp://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

Una vez los paquetes descargados copiar en la partición o en la partición donde se tenga espacio para instalar la base.

/u01/database/



4. Consejos

4.1. Se debe constatar que tanto la base como el sistema operativo sean iguales en los dos servidores mismo Hadware y Software.

4.2. Los dos servidores deben tener instalados los paquetes necesarios para el correcto funcionamiento del oracle consulta el siguiente link http://docs.oracle.com/cd/B28359_01/install.111/b32002/pre_install.htm#LADBI214

4.2. El primer servidor de producción contiene la base con listener el segundo solo el software de oracle y listener con los mismos parámetros que se configuro el principal

4.3. Deben tener las mismas características físicas los dos servidores

4.4. Crear archivo de variables de ambiente en el servidor de standby “.bash_profile”

Sentencias útiles para ver la versión del sistema operativo

Nombre tipo y versión de S.O.

[oracle@rfcg ~]$ lsb_release -a

Consulta para la versión del software de  Oracle

SQL> select value from v$system_parameter where name = ‘compatible’

Consulta Para ver los parámetros de configuración de la base de datos

SQL> SELECT * FROM NLS_DATABASE_PARAMETERS

        CONSULTAS ÚTILES

       – Consulta identifica si es primario o secundario

SELECT name,open_mode,database_role,db_unique_name,protection_modeFROM v$database;

         -Identificar el rol actiual del servidor

SELECT database_role FROM v$database;

5. Configurar servidor principal (Producción)

5.1. Poner la base principal en modo archivelog

Nota: Para verificar el modo actual de tu servidor principal

SQL> SELECT log_mode FROM v$database;

LOG_MODE
————
NOARCHIVELOG

Poner en modo archivelog

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;
5.2.Habilitar el registro forzado

SQL> ALTER DATABASE FORCE LOGGING;

5.3.Verificar la configuración de db_name y db_unique_name en ambos casos debe ser el nombre de la instancia de producción

SQL> show parameter db_name

NAME    TYPEVALUE
———————————— ———– ——————————
db_name     string DB11G

SQL> show parameter db_unique_name

NAME    TYPEVALUE
———————————— ———– ——————————
db_unique_name     string DB11G

5.4.Configurar el archivelog para stanby

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=’DG_CONFIG=(DB11G,DB11G_STBY)';

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2=’SERVICE=db11g_stby NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G_STBY';

SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
5.5.Configurar el passwordfile

SQL> ALTER SYSTEM SET LOG_ARCHIVE_FORMAT=’%t_%s_%r.arc’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=30;

SQL> ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;

5.6.Configurar el envio de spfile a standby

SQL> ALTER SYSTEM SET FAL_SERVER=DB11G_STBY;

SQL> ALTER SYSTEM SET DB_FILE_NAME_CONVERT=’DB11G_STBY’,’DB11G’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET LOG_FILE_NAME_CONVERT=’DB11G_STBY’,’DB11G’ SCOPE=SPFILE;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
5.7.Configurar el tnsname.ora 

Se debe agregar manual o con el utilitario netmgr el servicio de standby que se creo en el servidor secundario. 

[oracle@host ~]$ vim $ORACLE_HOME/network/admin/tnsnames.ora

/***************************************************

DGARD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = rfcg.oracle.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = dgard.oracle.com)
)
)

DGARD_STBY =
  (DESCRIPTION =    (ADDRESS_LIST =     (ADDRESS = (PROTOCOL = TCP)(HOST = rfcg2.oracle.com)(PORT = 1521)) )

    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = dgard_stby.oracle.com)
    )
  )

***************************************************/

Nota: Para probar si se tiene conexión entre los dos servidores se recomienda ejecutar el comando tnsping <nombre del servicio>

[oracle@host ~]$ tnsping DGARD_STBY

6. Obtener los archivos de parámetros

6.1. Crear el controlfile y parameterfile para standby

Ejecutar en el principal

SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/tmp/db11g_stby.ctl';

SQL>CREATE PFILE=’/tmp/initDB11G_stby.ora’ FROM SPFILE;

6.2. Cambiar en el archivo de controlfile creado para standby anteriromente

*Cambiar las lineas con -> lo que se tiene en la derecha es lo original por lo de la izquierda.

Original -> Nuevo Valor

[oracle@host ~]$ vim /tmp/initDB11G_stby.ora

/************************************************************************

dgard.__db_cache_size=503316480 -> dgard_stby.__db_cache_size=503316480
dgard.__java_pool_size=16777216 -> dgard_stby.__java_pool_size=16777216
dgard.__large_pool_size=16777216 -> dgard_stby.__large_pool_size=16777216
dgard.__oracle_base=’/u01/app/oracle’#ORACLE_BASE set from environment
->  dgard_stby.__oracle_base=’/u01/app/oracle’#ORACLE_BASE set from environment
dgard.__pga_aggregate_target=754974720 -> dgard_stby.__pga_aggregate_target=754974720
dgard.__sga_target=855638016 -> dgard_stby.__sga_target=855638016
dgard.__shared_io_pool_size=0 -> dgard_stby.__shared_io_pool_size=0
dgard.__shared_pool_size=268435456 -> dgard_stby.__shared_pool_size=268435456
dgard.__streams_pool_size=33554432 -> dgard_stby.__streams_pool_size=33554432
*.audit_file_dest=’/u01/app/oracle/admin/dgard/adump’
-> *.audit_file_dest=’/u01/app/oracle/admin/dgard_stby/adump’
*.audit_trail=’db’
*.compatible=’11.2.0.0.0′
*.control_files=’/u01/app/oracle/oradata/dgard/control01.ctl’,’/u01/app/oracle/fast_recovery_area/dgard/control02.ctl’
->
*.control_files=’/u01/app/oracle/oradata/dgard_stby/control01.ctl’,’/u01/app/oracle/fast_recovery_area/dgard_stby/control02.ctl’
*.db_block_size=8192
*.db_domain=’oracle.com’
*.db_file_name_convert=’dgard_stby’,’dgard’ ->  *.db_file_name_convert=’dgard’,’dgard_stby’
*.db_name=’dgard’
Aumentar esta Linea————> *.db_unique_name=’dgard_stby’
*.db_recovery_file_dest=’/u01/app/oracle/fast_recovery_area’
*.db_recovery_file_dest_size=4322230272
*.diagnostic_dest=’/u01/app/oracle’
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dgardXDB)’
*.fal_server=’DGARD_STBY’ -> *.fal_server=’DGARD’
*.log_archive_config=’DG_CONFIG=(dgard_stby,dgard)’ ->*.log_archive_config=’DG_CONFIG=(dgard,dgard_stby)’
*.log_archive_dest_2=’SERVICE=dgard NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dgard_stby’
-> *.log_archive_dest_2=’SERVICE=dgard NOAFFIRM ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=dgard’
*.log_archive_dest_state_2=’ENABLE’
*.log_archive_format=’%t_%s_%r.arc’
*.log_archive_max_processes=30
*.log_file_name_convert=’dgard_stby’,’dgard’ -> *.log_file_name_convert=’dgard’,’dgard_stby’
*.memory_target=1603272704
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile=’EXCLUSIVE’
*.standby_file_management=’AUTO’
*.undo_tablespace=’UNDOTBS1′

************************************************************************/

7. Sincronizados los servidores con RMAN

7.1. Sacar backup de la base primaria

Ejecutar en el principal

[oracle@host ~]$ rman target=/

RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
7.2. Crear los directorios como se tiene en el servidor de producción

Ejecutar en el secundario

[oracle@host ~]$ mkdir -p /u01/app/oracle/oradata/dbg11_stby

[oracle@host ~]$ mkdir -p /u01/app/oracle/fast_recovery_area/dbg11_stby

[oracle@host ~]$ mkdir -p /u01/app/oracle/admin/dbg11_stby/adump

7.3. Copiar los archivos de configuración de producción a standby

Ejecutar en el primario

*Controlfile

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:/tmp/db11g_stby.ctl /u01/app/oracle/oradata/dbg11_stby/control01.ctl

[oracle@host_stby ~]$ cp /u01/app/oracle/oradata/DB11G/control01.ctl /u01/app/oracle/fast_recovery_area/dbg11_stby/control02.ctl

*Archivelogs and backups

[oracle@host_stby ~]$ scp -r oracle@ol5-112-dga1:/u01/app/oracle/fast_recovery_area/DB11G/archivelog /u01/app/oracle/fast_recovery_area/dbg11_stby

[oracle@host_stby ~]$ scp -r oracle@ol5-112-dga1:/u01/app/oracle/fast_recovery_area/DB11G/backupset /u01/app/oracle/fast_recovery_area/dbg11_stby

*Parameter file.

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora

*Login password file.

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:$ORACLE_HOME/dbs/orapwDB11G $ORACLE_HOME/dbs

*Tnsname

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:$ORACLE_HOME/network/admin/tnsname.ora $ORACLE_HOME/network/admin/tnsname.ora

7.4. Levantar el listener

[oracle@host_stby ~]$ lsnrctl reload

7.5. Restaurar el backup en el servidor de standby con el spfile

[oracle@host_stby ~]$ export ORACLE_SID=DB11G

[oracle@host_stby ~]$ sqlplus / as sysdba

SQL> CREATE SPFILE FROM PFILE=’/tmp/initDB11G_stby.ora';

[oracle@host_stby ~]$ rman target=/

RMAN> STARTUP MOUNT;

RMAN> RESTORE DATABASE;

7.6. Crear los logfile

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/dgard_stby/standby_redo01.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/dgard_stby/standby_redo02.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/dgard_stby/standby_redo03.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/dgard_stby/standby_redo04.log’) SIZE 50M;

8. Sincronizados los servidores con Duplicate

8.1. Copiar los archivos de configuración de producción a standby

Ejecutar en el principal

*Controlfile

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:/tmp/db11g_stby.ctl /u01/app/oracle/oradata/dbg11_stby/control01.ctl

[oracle@host_stby ~]$ cp /u01/app/oracle/oradata/DB11G/control01.ctl /u01/app/oracle/fast_recovery_area/dbg11_stby/control02.ctl

*Parameter file.

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:/tmp/initDB11G_stby.ora /tmp/initDB11G_stby.ora

*Login password file.

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:$ORACLE_HOME/dbs/orapwDB11G $ORACLE_HOME/dbs

*Tnsname

[oracle@host_stby ~]$ scp oracle@ol5-112-dga1:$ORACLE_HOME/network/admin/tnsname.ora $ORACLE_HOME/network/admin/tnsname.ora

8.2. Crear los los redo de standby en el principal

Ejecutar en el principal

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/DB11G/standby_redo01.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/DB11G/standby_redo02.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/DB11G/standby_redo03.log’) SIZE 50M;

SQL> ALTER DATABASE ADD STANDBY LOGFILE (‘/u01/app/oracle/oradata/DB11G/standby_redo04.log’) SIZE 50M;

Ejecutar en el secundario

8.3. Levantar el listener

[oracle@host_stby ~]$ lsnrctl reload

8.3. Usar duplicate

[oracle@host_stby ~] export ORACLE_SID=DB11G

[oracle@host_stby ~] sqlplus / as sysdba

SQL> STARTUP NOMOUNT PFILE=’/tmp/initDB11G_stby.ora';

8.4. Conectarse a RMAN y ejecutar script de duplicate

Ejecutar en el principal

[oracle@host_stby ~]  rman TARGET sys/password@DB11G AUXILIARY sys/password@DB11G_STBY

RMAN > DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET db_unique_name=’DB11G_STBY’ COMMENT ‘Is standby’
SET LOG_ARCHIVE_DEST_2=’SERVICE=db11g ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DB11G’
SET FAL_SERVER=’DB11G’ COMMENT ‘Is primary’
NOFILENAMECHECK;

9. Configurar servidor secundario (Standby)

9.1. Permitir el recibimiento de archivelog.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Nota: Estas sentencias sirven para dejar abierto stanby y recibir archivelog de produccion.

Se usa 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Para cancelar y dejar de recibir archivelog

CONSEJO: Realizar tnsping a producción desde standby y viceversa a ambas instancias para saber que están conectadas
10. Enviar archivelog’s (Switch log file)

Ejecutar en el principal

10.1. Saber numero de transacción en la que se encuentra actualmente

SQL> ALTER SESSION SET nls_date_format=’DD-MON-YYYY HH24:MI:SS';

SQL> SELECT sequence#, first_time, next_time FROM   v$archived_log ORDER BY sequence#;

10.2. Dejar de escribir en archive y enviar a memoria sincronizando con standby

SQL> ALTER SYSTEM SWITCH LOGFILE;

10.3. Validar la transferencia de archive en standby

Ejecutar en el secundario

SQL> ALTER SESSION SET nls_date_format=’DD-MON-YYYY HH24:MI:SS';

SQL> SELECT sequence#, first_time, next_time, applied FROM   v$archived_log ORDER BY sequence#;

Nota: Verificar que el mismo número de secuencia este en ambos y el estado de la transacción sea  applied = YES

11. Convertir servidor secundario a principal (Switchover)

Ejecutar en el principal

CONSEJO: en otra terminal hacer “tail -f”  al alert log para verificar que todo se ejecute normalmente

11.1. Realizar principal servidor secundario

SQL> CONNECT / AS SYSDBA

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;

SQL> SHUTDOWN IMMEDIATE;

11.2. Montar servidor principal como standby

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;


11.3. Finalizar la administracion de standby como servidor secundario

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;


12. Hacer permanente servidor secundario principal (Failover)

Ejecutar en el secundario

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;

Nota: Después de ejecutar el failover no se puede regresar atrás

Conclusiones

Después de realizar esta practica usted debe ser capaz de:

– Configurar un servidor de standby ante desastres.
– Conocimientos de hacer una copia de base con duplicate.
– Conocimientos de rman backup.

Elaborado por:
José Fabre
                                                                     Oracle Certified Associate
                     jose.fabre@refundation.com

OTN Tour 2012 llegó el momento de la inscripción a nuestro evento

Posted by Paola Pullas | Posted in Administración, Aplicaciones, Base de Datos, JDeveloper, Noticias, Oracle, Oracle XE | Posted on 19-06-2012

Tags: , , , , , , , , , , ,

9

Estimados Amigos,

Se acerca el evento de tecnología Oracle más importante del año a Ecuador. Este año contaremos con la participación de 8 expositores internacionales y hasta 5 tracks de capacitación en tecnología de los cuales podrán elegir.

A continuación los detalles y costos del evento:

Fecha: 6 de Julio de 2012
Lugar: Universidad de las Américas, Campus Av. de los Granados y Colimes esq, Quito – Ecuador, Auditorio 1 y 2.
Costo del Evento: 150USD o 100USD por día. Estudiantes cuentan con el 50% de descuento si presentan el carnet de su universidad.
Pago del Evento: El pago del evento podrá hacerse mediante depósito en la cuenta corriente #02054016475 del Banco Produbanco a nombre de Refundation o realizar el pago en efectivo en nuestras oficinas ubicadas en la Checoslovaquia y Av. Eloy Alfaro, Edf. Cuarzo, Piso 5, Of. 2. Una vez que haya realizado el pago deberá enviar un correo electrónico a inscripcion@ecuoug.org con la papeleta de depósito escaneada e indicando el track de capacitación en el cual desea reservar su cupo.
Retiro de credenciales: El retiro de credenciales de acceso al evento deberá hacerse entre el día Viernes 29 de Junio y Martes 3 de Julio en las oficinas de Refundation ubicadas en la Checoslovaquia y Av. Eloy Alfaro, Edf. Cuarzo, Piso 5, Of. 2.
Acceso a tracks de capacitación por el pago de 150USD: Por el pago de 150USD tendrá acceso a:

  • Evento del 6 de Julio de 2012
  • Accceso a un track de capacitación los cuales se dictarán el 4 y 5 de Julio. Usted podrá elegir entre: Oracle DBA en 2 días, High Availability con Oracle Real Application Clusters, Disaster Recovery con Oracle Data Guard u Oracle Security.
  • Acceso al Track de CIO’s en donde se tratará temas como ITIL, Cobit, Licenciamiento de Productos Oracle y demás..
  • Acceso a almuerzo, servicio de coffe break a media mañana y media tarde y cocktail.

Agenda del Evento: Descargar de Agenda del Evento OTN LAD Tour 2012 (2005) la agenda del evento para el día 6 de Julio.

Las personas que se inscriban y realicen el pago hasta el día Lunes 25 de Junio automáticamente participarán por el sorteo de una Notebook. En su credencial de acceso constará el número para participar en el sorteo.

Day 3: How to install SQL Developer in Linux

Posted by Paola Pullas | Posted in Aplicaciones, Base de Datos, Oracle | Posted on 04-09-2010

Tags: , , , , ,

5

In this post I will show you how to install Oracle SQL Developer in a Linux box. First, you should download the SQL Developer software from http://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/index.html.

Next, if you downloaded the software without JDK included, you need to download a JDK 1.6.11 version or above from http://www.oracle.com/technetwork/java/javase/downloads/index.html

Install JDK

First install the JDK version in your Linux box in any directory. I will install the JDK in /u01/app/oracle like I show you in the next screens:

  • chmod a+x jdk-6u-linux-i586.bin
  • ./jdk-6u-linux-i586.bin

Install SQL Developer

Then install SQL Developer rpm using the next command:

  • rpm -Uhv sqldeveloper-2.1.1.64.45-1.noarch.rpm

Next, verify if the file jdk contains the JDK’s path. This file is located in $HOME/.sqldeveloper. If the JDK’s path that you installed previously isn’t registered in the jdk file, the first time that you launch the application, you should be prompted to provide the path.

Finally execute sqldeveloper with the next command:

  • sqldeveloper

Author: Paola Pullas
Do you need to buy support?: Contact me at pp@refundation.com

If you think that this tutorial helped you. Make a donation to this initiative. We appreciate your support. Also your donation can help me to buy more coffee or Red Bull.





Cambiando el IP a servidores con Oracle Application Server 10g

Posted by Paola Pullas | Posted in Aplicaciones, Oracle | Posted on 08-03-2008

3

A continuación les detallo el procedimiento para cambiar la IP a los equipos cuando se tiene instalado Oracle Application Server 10g Release 2 con una instalación de tipo Business Intelligence de por medio.

Para mi caso de ejemplo les comento que yo tengo instalado Oracle Application Server 10g – Business Intelligence en las oficinas de Refundation Consulting Group que consta de dos equipos con Red Hat Enterprise Linux 4, los componentes instalados en mi laboratorio son: Oracle Portal, Oracle Forms Services, Oracle Reports Services y Oracle Discoverer. Mayor información de cada uno de estos productos puede ser encontrada Oracle Technology Network.

En este caso le queremos cambiar la IP tanto al equipo que contiene la infraestructura como al equipo que contiene la capa media por lo que vamos a seguir el procedimiento que se detalla a continuación:

Paso 1: Bajar todos los servicios de capa media e infraestructura en el orden que se indica a continuación.

En el equipo con capa media:
1. Paramos la consola de administración:

emctl stop iasconsole

2.
Paramos los servicios de la capa media como HTTP Server, Oracle Portal, Oracle Forms Services, Oracle Reports Services, Oracle Discoverer, Oracle Containers for Java, etc.:

opmnctl stopall

En el equipo con infraestructura:
1. Paramos las consolas de administración:

emctl stop iasconsole
emctl stop dbconsole


2.
Paramos los servicios relacionados con la infraestructura como: HTTP Server, Oracle Internet Directory, Oracle Certificate Authority, etc.:

opmnctl stopall

3. Paramos la base de datos:

sqlplus / as sysdba
sql> shutdown immediate
sql> exit;

4. Paramos el listener:

lsnrctl stop

Paso 2: Cambiar la ip tanto de la máquina que contiene la infraestructura como de la máquina que contiene la capa media. En este punto hacer todas las pruebas necesarias para verificar que el cambio de IP haya sido efectivo.

Paso 3: Una vez cambiadas las IP de las máquinas proceder a registrar el cambio a nivel del Oracle Application Server utilizando el script chgiphost para lo que se debe seguir el procedimiento que se detalla a continuación:

En el equipo con infraestructura:
1. Levantamos el listener:

lsnrctl start

2. Levantamos la base de datos:

sqlplus / as sysdba
sql> startup
sql> exit;

3. Levantamos el servicio correspondiente al OPMN;

opmnctl start

4. Levantamos el servicio de Oracle Internet Directory:

opmnctl startproc ias-component=OID

5. Ejecutamos el script chgiphost:

cd $ORACLE_HOME/chgip/scripts
./chgiphost.sh -infra

6. Si el script finaliza exitosamente levantar el resto de servicios de la infraestructura:

opmnctl startall
emctl start dbconsole
emctl start iasconsole

En el equipo con capa media:
1. Ejecutamos el script chgiphost:

cd $ORACLE_HOME/chgip/scripts
./chgiphost.sh -mid

2. Levantamos los servicios de capa media:

opmnctl startall

3. Levantamos la consola de adminisración:

emctl start iasconsole

Paso 4: Una vez realizados los cambios anteriores verificar el acceso a todas las consolas y aplicaciones que residen en el Application Server.

Autor:
Paola Pullas

Actualice APEX en su instalación de Oracle XE

Posted by Paola Pullas | Posted in Aplicaciones, Noticias | Posted on 15-07-2007

3

Se ha liberado ya la versión de Oracle APEX 3.0.1 de tal manera que aquellos usuarios de Oracle Database XE que cuentan con la versión de APEX 2.1 que viene integrada con la instalación de esta base de datos pueden realizar la actualización. Esta es una buena noticia ya que podremos hacer uso de las nuevas características de APEX incluídas en las versiones 2.2 y 3.0 que permitirán hacer de XE una herramienta mucho más potente.

Se debe tomar en cuenta que al momento de realizar la actualización se perderá la habilidad para utilizar la interfaz de Oracle APEX para realizar ciertas tareas administrativas de la base de datos, por lo que tendrá que utilizar herramientas como SQL*Plus o SQL Developer en reemplazo.

Technorati Tags:

Autor:
Paola Pullas

Solución Conexión Remota Oracle XE (APEX)

Posted by Paola Pullas | Posted in Aplicaciones, Oracle XE | Posted on 09-07-2007

19

Por: Christian Pazmiño

Después de revisar algunos de los comentarios que se ha publicado en el ecuoug.org, me he dado cuenta que hay algunos problemas recurrentes y que mejor deberíamos tratarlos como un post nuevo, no solo voy a tratar este problema sino que voy a ir solucionando algunos de los problemas que están en los comentarios que mas me han llamado la atención y además que son divertidos de solucionar, con esto no estoy diciendo que todos los problemas que han tenido no los vamos a resolver, pero si hay unos que me gustan mas y que les voy a dar mayor prioridad.

Por ahora estoy en conversaciones con la Big Boss y estoy gestionando para que volvamos a subir el Foro de ECUOUG donde creo que es un mejor lugar para ir solucionando los problemas que vayamos teniendo, pero después de la mala experiencia que tuvimos con el anterior foro que se lleno de SPAM estamos aun medios temerosos. Sin mas aquí va la solución para las personas que no puede conectarse remotamente a nuestro APEX.

Oracle XE tiene unas políticas de seguridad bastante interesantes por lo que han decidido no permitir conexiones remotas por defecto, lo que debemos hacer es conectarnos vía sqlplus como SYSTEM, ya dentro de sqlplus, debemos ingresar la siguiente sentencia:

SQL> exec dbms_xdb.setListenerLocalAccess(false);

y eso es todo ahora podremos conectarnos a nuestro APEX específicamente remotamente desde un Web browser.

Por ejemplo si nuestro servidor de base de datos tiene la siguiente dirección 192.168.0.100, específicamente ingresar con la siguiente URL:

http://192.168.0.100:8080/apex

Eso es todo por ahora, más tarde seguiré subiendo las soluciones para otros problemas que he encontrado en los distintos comentarios.

ORA-00604 y ORA-12705 en JDeveloper

Posted by Paola Pullas | Posted in Aplicaciones | Posted on 08-07-2007

51

Este post lo escribo porque últimamente me ha tocado solucionar con frecuencia los errores ORA-00604: error occurred at recursive SQL level 1 y ORA-12705: invalid or unknown NLS parameter value specified, que aparecen cuando se intenta realizar la conexión desde JDeveloper 10g 10.1.3 hacia la Base de Datos Oracle 10g R2.

Pues a continuación les coloco la solución a este problema:
1. Ubicar en los directorios de instalación de Jdeveloper el archivo jdev.conf

2. Editar el archivo con un editor de texto y añadir las siguientes líneas al final del archivo:
AddVMOption -Duser.region=us
AddVMOption -Duser.language=en

Si la solución anterior no ayuda con el problema probar lo siguiente:
1. Si se está en Microsoft Windows abrir el regedit, buscar la clave NLS_LANG y eliminarla o setearla al mismo valor que el set de caracteres de la Base de Datos. No olviden antes de realizar este cambio importar el regedit para que puedan tener un respaldo en el caso de que este cambio afecte a otros programas que estén en el equipo.

2. Si no conoces el set de caracteres con el cual está configurada tu base de datos puedes consultar desde SQL*Plus a la vista del diccionario nls_database_parameters. Para darte un ejemplo el set de caracteres de mi base de datos tiene la configuración AMERICAN_AMERICA.WE8ISO8859P15 de tal manera que el NLS_LANG debería tener este valor.

Autor: Paola Pullas

Oracle JDeveloper 11g and OC4J 11g Technology Preview

Posted by Paola Pullas | Posted in Aplicaciones, Noticias | Posted on 10-05-2007

5

El día de ayer, 9 de Mayo de 2007, Oracle liberó el preview de Oracle JDeveloper 11g y Oracle Containers for Java (OC4J) 11g. Al momento yo me los estoy descargando para ver que novedades tenemos.

A continuación se detalla un listado parcial de las nuevas características de JDeveloper 11g:
• JDK release 6 and Java EE 5 support
• Visual development with Ajax and the JavaServer Faces application
• Enterprise JavaBeans (EJB) 3.0 technology enhancement
• New SOA tools integration
• Blurring the line between JavaServer Faces technology and portlets

Si ya revisaste las nuevas características comenta aquí.

El preview puedes descargarte haciendo click aquí.

Author: Paola Pullas

Oracle dona Toplink a la comunidad Open Source

Posted by Paola Pullas | Posted in Aplicaciones, Noticias | Posted on 10-03-2007

1

El día 6 de Marzo de 2007 Oracle Corporation anunció la donación de Oracle Toplink, el framework de persistencia para Java a la comunidad Open Source.

Oracle propone un proyecto para la creación de una plataforma de persistencia para Eclipse (EclipseLink), el cual será liderado por Oracle, siendo el punto de entrada para dicho proyecto la donación del código y casos de prueba de Oracle Toplink.

Como miembro de Eclipse Foundation desde 2002, Oracle ha liderado tres proyectos relacionados con: JavaServer Faces, Dali Java Persistence API (JPA) y Business Process Execution Language.

Al momento Oracle tendría dos competidores en esta línea:Hibernate y OpenJPA.

Por otro lado, Oracle continuará ofreciendo soporte y mejoras a Toplink como un producto comercial con la finalidad de satisfacer las necesidades del mercado existente, de igual manera, seguirá posicionando a JDeveloper como una alternativa a Eclipse.
Mayor información en el siguiente enlace:

http://www.oracle.com/corporate/press/2007_mar/OpenSource-TopLink.html

Autor: Paola Pullas