Administración Oracle

Un afectuoso saludos de navidad y que el próximo año este lleno de paz, amor, éxito, optimismo y fe.

Saludo Navideño Oracle.Xgodoy.Com

Por alguna razón puede que se requiera modificar el nombre de la base de datos, modificando un par de parámetros y recreando el controlfile puede ser una tarea entre paréntesis fácil pero esto no asegura el cambio íntegro ya que solo cambia el DBNAME pero no el DBID, el DBID es interno y único identificador de la base de datos. Por ejemplo, se requiere restaurar una base de datos en el mismo servidor de origen (algo así como una copia de la base de datos), se ve algo fácil, solo bastaría con levantar una instancia con otro nombre, restaurar la base de datos sobre esa instancia y recrear el controlfile, pero las dos base de datos seguirían con el mismo DBID, algunos de los problemas con esto son por ejemplo los backups con RMAN ya que este identifica a las bases de datos con el DBID. Otro caso práctico es restaurar una copia de nuestra base de datos en el mismo servidor donde se encuentra nuestro DATAGUARD, simplemente nuestro DATAGUARD tendrá muchos problemas al encontrarse dos bases de datos en el mismo servidor con el mismo DBID (aunque las instancias tengan distinto nombre). La solución para estos casos es una utilidad llamada DBNEWID, fácil de utilizar pero con consideraciones no documentadas explícitamente, en el siguiente artículo realizaremos un par de ejemplos sobre cómo utilizar el DBNEWID y las consideraciones que se deben tener en cuenta.

Cambiando solo el DBNAME

Se cuenta con una base de datos llamada jimydb, cambiaremos solo el nombre de esta a TESTDB:

Lo primero es crear un archivo de init:

cp $ORACLE_HOME/dbs/initjimydb.ora $ORACLE_HOME/dbs/initTESTDB.ora

Modificamos el parámetro db_name en el init y todo parámetro que haga referencia al nombre de la instancia o la base de datos. Luego es necesario agregar al listener.ora, tnsnames.ora y /etc/oratab la instancia TESTDB.

Ahora a renombrar la base de datos.

La base de datos debe están en modo MOUNT:

[oracle@SERVER dbs]$ . oraenv
ORACLE_SID = [jimydb] ? jimydb
[oracle@SERVER dbs]$sqlplus / as sysdba

SQL> shutdown immediate
SQL>startup mount

Luego de sede ejecutar el utilitario DBNEWID con un usuario con privilegios sysdba de la siguiente forma:

nid TARGET=SYS/password@jimydb DBNAME=TESTDB SETNAME=YES

Preguntará si deseas cambiar el nombre de la base de datos, le damos “Y”:

La salida es algo por el estilo:

DBNEWID: Release 10.2.0.3.0 – Production on Wed Jul 8 16:57:36 2009
 
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
 
Connected to database JIMYDB (DBID=3309000021)
 
Connected to server version 10.2.0
 
Control Files in database:
    /u02/oradata/jimydb/control01.ctl
    /u02/oradata/jimydb/control02.ctl
    /u02/oradata/jimydb/control03.ctl
 
Change database name of database JIMYDB to TESTDB? (Y/[N]) => Y
 
Proceeding with operation
Changing database name from JIMYDB to TESTDB
    Control File /u02/oradata/jimydb/control01.ctl – modified
    Control File /u02/oradata/jimydb/control02.ctl – modified
    Control File /u02/oradata/jimydb/control03.ctl – modified
    Datafile /u02/oradata/jimydb/system01.dbf – wrote new name
    Datafile /u02/oradata/jimydb/undotbs01.dbf – wrote new name
    Datafile /u02/oradata/jimydb/sysaux01.dbf – wrote new name
    Datafile /u02/oradata/jimydb/users01.dbf – wrote new name
    Datafile /u02/oradata/jimydb/testdat.dbf – wrote new name
    Datafile /u02/oradata/jimydb/testdat2.dbf – wrote new name
    Datafile /u02/oradata/jimydb/temp01.dbf – wrote new name
    Control File /u02/oradata/jimydb/control01.ctl – wrote new name
    Control File /u02/oradata/jimydb/control02.ctl – wrote new name
    Control File /u02/oradata/jimydb/control03.ctl – wrote new name
    Instance shut down
 
Database name changed to TESTDB.
Modify parameter file and generate a new password file before restarting.
Succesfully changed database name.DBNEWID – Completed succesfully.

Se puede apreciar la modificación del controlfile y como marca los datafiles. Termina la correcta ejecución bajando la base de datos. Luego y ya que el archivo initTESTDB.ora ya esta creado nos ambientamos como TESTDB y levantamos la base de datos:

[oracle@SERVER dbs]$ . oraenv
ORACLE_SID = [jimydb] ? TESTDB
[oracle@SERVER dbs]$ sqlplus / as sysdba

SQL> startup

Verificamos parámetros y nombre de la base de datos:

SQL> sho parameters name
NAME                                 TYPE        VALUE
- – - – - – - – - – - – - – – - – - – - – - – - – - – - – -
db_file_name_convert                 string
db_name                              string      TESTDB
db_unique_name                       string      TESTDB
global_names                         boolean     FALSE
instance_name                        string      TESTDB
lock_name_space                      string
log_file_name_convert                string
service_names                        string      TESTDB

SQL> select DBID, NAME, DB_UNIQUE_NAME from v$database;
      DBID NAME      DB_UNIQUE_NAME
- – - – - – - – - – - – - – - – - – - – - – - – -
3309000021 TESTDB    TESTDB

Listo!, por ultimo creamos un nuevo archivo de password y verificamos los procesos oracle:

[oracle@SERVER dbs]$ orapwd file=/u01/app/oracle/db/dbs/orapwTESTDB password=password entries=10;
[oracle@SERVER dbs]$ ps -fea |grep ora_
oracle    1108     1  0 23:21 ?        00:00:00 ora_pmon_TESTDB
oracle    1110     1  0 23:21 ?        00:00:00 ora_psp0_TESTDB
oracle    1112     1  0 23:21 ?        00:00:00 ora_mman_TESTDB
oracle    1114     1  0 23:21 ?        00:00:00 ora_dbw0_TESTDB
oracle    1116     1  0 23:21 ?        00:00:00 ora_lgwr_TESTDB
oracle    1118     1  0 23:21 ?        00:00:00 ora_ckpt_TESTDB
oracle    1120     1  0 23:21 ?        00:00:00 ora_smon_TESTDB
oracle    1122     1  0 23:21 ?        00:00:00 ora_reco_TESTDB
oracle    1124     1  0 23:21 ?        00:00:00 ora_cjq0_TESTDB
oracle    1126     1  0 23:21 ?        00:00:00 ora_mmon_TESTDB
oracle    1128     1  0 23:21 ?        00:00:00 ora_mmnl_TESTDB
oracle    1134     1  0 23:21 ?        00:00:01 ora_j000_TESTDB
oracle    1136     1  0 23:21 ?        00:00:00 ora_j001_TESTDB

Cambiando el DBNAME y DBID

Actualmente la base de datos se llama TESTDB, la renombraremos a PRUEBADB y además cambiaremos el DBID de esta:

Primero identificaremos el nombre actual y DBID de la base de datos:

SQL> select DBID, NAME, DB_UNIQUE_NAME from v$database;
      DBID NAME      DB_UNIQUE_NAME
- – - – - – - – - – - – - – - – - – - – - – - – -
3309000021 TESTDB    TESTDB

Crear un archivo de init:

cp $ORACLE_HOME/dbs/initTESTDB.ora $ORACLE_HOME/dbs/initPRUEBADB.ora

Modificamos el parámetro db_name en el init y todo parámetro que haga referencia al nombre de la instancia o la base de datos. Luego es necesario agregar al listener.ora, tnsnames.ora y /etc/oratab la instancia PRUEBADB.

La base de datos debe están en modo MOUNT:

[oracle@SERVER dbs]$ . oraenv
ORACLE_SID = [TESTDB] ? TESTDB
[oracle@SERVER dbs]$sqlplus / as sysdba

SQL> shutdown immediate
SQL> startup mount

Luego de sede ejecutar el utilitario DBNEWID con un usuario con privilegios sysdba de la siguiente forma:

nid TARGET=SYS/password@TESTDB DBNAME=PRUEBADB

Preguntará si deseas cambiar el nombre de la base de datos, le damos “Y”:

La salida es algo por el estilo:

DBNEWID: Release 10.2.0.3.0 – Production on Wed Jul 8 23:40:07 2009
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to database TESTDB (DBID=3309000021)
Connected to server version 10.2.0
Control Files in database:
    /u02/oradata/jimydb/control01.ctl
    /u02/oradata/jimydb/control02.ctl
    /u02/oradata/jimydb/control03.ctl
Change database ID and database name TESTDB to PRUEBADB? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 3309000021 to 455356631
Changing database name from TESTDB to PRUEBADB
    Control File /u02/oradata/jimydb/control01.ctl – modified
    Control File /u02/oradata/jimydb/control02.ctl – modified
    Control File /u02/oradata/jimydb/control03.ctl – modified
    Datafile /u02/oradata/jimydb/system01.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/undotbs01.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/sysaux01.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/users01.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/testdat.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/testdat2.dbf – dbid changed, wrote new name
    Datafile /u02/oradata/jimydb/temp01.dbf – dbid changed, wrote new name
    Control File /u02/oradata/jimydb/control01.ctl – dbid changed, wrote new name
    Control File /u02/oradata/jimydb/control02.ctl – dbid changed, wrote new name
    Control File /u02/oradata/jimydb/control03.ctl – dbid changed, wrote new name
    Instance shut down
Database name changed to PRUEBADB.
Modify parameter file and generate a new password file before restarting.
Database ID for database PRUEBADB changed to 455356631.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID – Completed succesfully.

Se puede apreciar la modificación del controlfile y como marca los datafiles. A diferencia del proceso anterior el utilitario avisa el cambio de DBID. Termina la correcta ejecución bajando la base de datos.

Luego y ya que el archivo initPRUEBADB.ora ya esta creado nos ambientamos como PRUEBADB y levantamos la base de datos:

[oracle@SERVER dbs]$ . oraenv
ORACLE_SID = [TESTDB] ? PRUEBADB
[oracle@SERVER dbs]$ sqlplus / as sysdba

SQL> startup mount
SQL> alter database open resetlogs;

Verificamos parámetros y nombre de la base de datos:

SQL> sho parameters name
NAME                                 TYPE        VALUE
- – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – - – -
db_file_name_convert                 string
db_name                              string      PRUEBADB
db_unique_name                       string      PRUEBADB
global_names                         boolean     FALSE
instance_name                        string      PRUEBADB
lock_name_space                      string
log_file_name_convert                string
service_names                        string      PRUEBADB

SQL> select DBID, NAME, DB_UNIQUE_NAME from v$database;
      DBID NAME      DB_UNIQUE_NAME
- – - – - – - – - – - – - – - – - – - – - – - – -
455356631  PRUEBADB  PRUEBADB

Listo!, por ultimo creamos un nuevo archivo de password y verificamos los procesos oracle:

[oracle@SERVER dbs]$ orapwd file=/u01/app/oracle/db/dbs/orapwPRUEBADB password=password entries=10;
[oracle@SERVER dbs]$ ps -fea |grep ora_
oracle    1208     1  0 23:25 ?        00:00:00 ora_pmon_PRUEBADB
oracle    1210     1  0 23:25 ?        00:00:00 ora_psp0_PRUEBADB
oracle    1212     1  0 23:25 ?        00:00:00 ora_mman_PRUEBADB
oracle    1214     1  0 23:25 ?        00:00:00 ora_dbw0_PRUEBADB
oracle    1216     1  0 23:25 ?        00:00:00 ora_lgwr_PRUEBADB
oracle    1218     1  0 23:25 ?        00:00:00 ora_ckpt_PRUEBADB
oracle    1220     1  0 23:25 ?        00:00:00 ora_smon_PRUEBADB
oracle    1222     1  0 23:25 ?        00:00:00 ora_reco_PRUEBADB
oracle    1224     1  0 23:25 ?        00:00:00 ora_cjq0_PRUEBADB
oracle    1226     1  0 23:25 ?        00:00:00 ora_mmon_PRUEBADB
oracle    1228     1  0 23:25 ?        00:00:00 ora_mmnl_PRUEBADB
oracle    1234     1  0 23:25 ?        00:00:01 ora_j000_PRUEBADB

Consideraciones

Al cambiar el nombre y el DBID de la base de datos, todos los backup vía RMAM y los archivelogs que existan no servirá más ya que después de cambiar el DBID se debe abrir la base de datos con la opción RESETLOGS lo que resetea la secuencia de los redologs a 1. Luego, inmediatamente después de realizar el cambio de DBID se debe realizar un backup full de la base de datos.

Si de desea cambiar el DBID de una base de datos recientemente restaurada (sin abrir aun), es necesario crear un tablespace temporal, si un tablespace temporal no existe el DBID fallará y no se podrá revertir el cambio, luego la base de datos quedará inservible y la documentación al respecto dice que es necesario entre muchos pasos recrear el controlfile (BUG 5861994). Del problema descrito conozco casos de éxito donde se ha logrado salvar la base de datos, pero el proceso es muy engorroso y lo mejor es evitar esos casos.

Referencias Metalink:

DOC ID 552053.1: NID Fails if Tempfiles Do Not Exist
DOC ID 224266.1: How to Change the DBID and the DBNAME by using NID

Saludos!
Jimy Godoy Maureira

CLOUG Noviembre 2009

El 16 de noviembre de 2009 de realizó el segundo evento del Grupo De Usuarios Oracle Chile – CLOUG, este evento contó con la presencia de un gran exponente de Oracle a nivel mundial, el Sr. Tom Kyte de ASK TOM, los expositores fueron:

• Francisco Muñoz (Chile), organizador del evento junto a Juan Puga. Las presentaciones de Francisco fueron:
           o Tips and Best Practices for DBA
           o Logging or NoLogging: That’s the question!
• Juan Camilo Ruiz (Colombia), presentando:
           o Creating SOA Composite Applications with ADF and SOA Suite 11g.
• Tom Kyte, presentando:
           o All about binding.
           o Reorganizing Objects
           o Top 10, no 11, new features of Oracle database 11g realese 2.
           o All about metadata; why telling the database about your schema matters.

Excelente presentación, un poco agotadora, fueron casi 9 horas seguidas de presentaciones.

Cuando estén disponibles las diapositivas del evento, subiré la documentación.

Si la base de datos se encuentra en modo archivelog, es necesario determinar una política de respaldo y eliminación de estos, si los archivelog no son borrados, el espacio configurado para estos puede volverse insuficiente generando incluso que la base de datos se “congele” debido a que no puede generar un archivelog.

Un error (WARNING) típico que se puede apreciar en el alertlog es:

ORA-19815: WARNING: db_recovery_file_dest_size of 85899345920 bytes is 100.00% used, and has 0 remaining bytes available.
Mon Mar 30 01:11:02 2009
**********************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
**********************************************************************

En este caso, el WARNING se convierte en un error grave, no hay espacio suficiente (“100.00% used”) configurado para la generación de archivelog, luego comienzan errores como:

Mon Mar 30 01:11:02 2009
Errors in file /u01/app/oracle/db/admin/jimydb/bdump/caefdb2_arc0_10217.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 97741824 bytes disk space from 85899345920 limit
ARC0: Error 19809 Creating archive log file to ‘/u02′
ARCH: Archival stopped, error occurred. Will continue retrying
Mon Mar 30 01:11:02 2009
ORACLE Instance jimydb – Archival Error
Mon Mar 30 01:11:02 2009
ORA-16038: log 11 sequence# 54433 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 11 thread 2: ‘/u02/jimydb/onlinelog/group_11.315.681334097′
ORA-00312: online log 11 thread 2: ‘/u02/jimydb/onlinelog/group_11.789.681334099′

Como se puede observar el error es grave, la base de datos ya no puede escribir archivelogs, el error indica que no se puede escribir en el directorio /u02, realmente esto no significa que el directorio no tenga espacio disponible (aunque podría ser causa del error), realmente el error es que se han almacenado archivelog ocupando más espacio que los permitidos por el parametro db_recovery_file_dest_size, para este caso se ha excedido el límite de 80 GB:

SQL> sho parameters db_recovery_file_dest_size
NAME                                 TYPE       VALUE
db_recovery_file_dest_size           big integer 80G
SQL>

Una salida rápida es el aumento del valor de este parámetro (si el espacio físico y real lo permite):

SQL> alter system set db_recovery_file_dest_size = 90G scope=both;
System altered.
SQL> sho parameters db_recovery_file_dest_size
NAME                                 TYPE       VALUE
db_recovery_file_dest_size           big integer 90G
SQL>

Listo!, la base de datos comienza a operar nuevamente, la acción inmediata tras esta alteración es eliminar los archivelog (previo respaldo) .

Lo importante es ser proactivo y no esperar a que se congele la base de datos, la siguiente query ayuda a monitorear el espacio disponible en el directorio db_recovery_file_dest  según lo configurado en db_recovery_file_dest_size:

SELECT
  NAME AS “Directorio Raiz Recovery Dest”,
  space_limit
    / 1024
    / 1024 AS “Max Espacio Configurado [MB]“,
  TRUNC(space_used
          / 1024
          / 1024,2) AS “Espacio Utilizado [MB]“,
  number_of_files AS “Cantidad De Archivos”,
  TRUNC(space_used
          * 100
          / space_limit,2) AS “% Utilizado Recovery Dest”
FROM
  v$recovery_file_dest;

Resultado:

El resultado muestra:

Directorio Raiz Recovery Dest: Directorio donde se generan los archivelog. Se puede revisar con “show parameters db_recovery_file_dest” .

Max Espacio Configurado [MB]: Espacio configurado el parametro db_recovery_file_dest_size y que significa el máximo espacio asignado para archivelog.

Espacio Utilizado [MB]: Espacio utilizado del directorio db_recovery_file_dest.

Cantidad De Archivos: Cantidad de archivelog que actualmente residen es el directorio db_recovery_file_dest.

% Utilizado Recovery Dest: Porcentaje del espacio total utilizado por archivelog en el directorio db_recovery_file_dest.

Descargar Articulo Completo Formato PDF

Saludos!
Jimy Godoy