Categories: Base de datos, Oracle 10g, Oracle 11g, Oracle11gR2, Oracle 12c

Retención de los snapshots e información de las DBA_HIST



Esta consultando información desde la tabla DBA_HIST_SEG_STAT y sólo encontre información de la última semana, pero la verdad esto no me sirve de mucho y quiero que el período a consultar sea un poco mayor...

¿A qué se debe que tenga tan poca retención? He aquí la explicación




La información que se visualiza en las DBA_HIST se carga cuando se están generando los Snapshots del AWR y se elimina cuando estos últimos se purgan, o sea, dependen directamente del intervalo de tiempo en donde se recogen estos Snapshots de AWR y se mantienen en línea el tiempo de retención seteado para los Snaps de AWR.


Para saber que seteo nosotros poseemos en nuestras bases de datos podemos ejecutar la siguiente consulta

select
extract( day from snap_interval) *24*60+
extract( hour from snap_interval) *60+
extract( minute from snap_interval ) "Intervalo entre Snaps",
extract( day from retention) *24*60+
extract( hour from retention) *60+
extract( minute from retention ) "Periodo de retencion seg" ,
extract( day from retention) "Periodo de retencion dias"
from dba_hist_wr_control;



Cuyo resultado se visualizaría de la siguiente forma

Intervalo entre Snaps Periodo de retencion seg Periodo de retencion dias
--------------------- ------------------------ -------------------------
15 86400 60



¿Cuál es el mejor período de retención e intervalo para tomar los Snapshots?

Aquí todo depende, ¿de qué depende? Pues del tamaño de nuestro tablespace SYSAUX, de que tanta carga tenga nuestra base de datos, etc, etc.

Pero podemos imaginarnos el tamaño que podría necesitar, para ello consultamos nuestro AWR dentro del tablespace SYSAUX, para ello ejecutamos la siguiente consulta

SQL> r
1 SELECT occupant_name, schema_name, move_procedure,
2 space_usage_kbytes
3 FROM v$sysaux_occupants
4* ORDER BY 1



El dato que nos interesa , aparecería de la siguiente forma

OCCUPANT_NAME SCHEMA_NAME MOVE_PROCEDURE SPACE_USAGE_KBYTES
------------------------------ -------------------- ----------------------------------- ------------------
SM/AWR SYS 10432448



Aquí podemos apreciar claramente cuanto es lo que usan nuestros snapshots para el período de tiempo de retención

Otra forma de obtener los datos que necesitamos , ejecutando el siguiente comando desde SQL*Plus

@?/rdbms/admin/awrinfo.sql



Dentro del reporte que se obtiene , podemos ver el intervalo en que se toman los snapshots y el período de retención, para ello buscamos el punto (6)

(6) AWR Control Settings - interval, retention



También podemos buscar el tamaño calculado para nuestros snapshots , con lo cual podemos saber de una manera óptima cuanto es el tamaño en Gb o en MB que necesitamos si queremos ampliar nuestro período de retención para los snapshors del AWR.

Dentro de la salida del awrinfo.sql , existe un punto llamado

*************************************
(2) Size estimates for AWR snapshots
*************************************
|
| Estimates based on 60 mins snapshot INTERVAL:
| AWR size/day 27.7 MB (1,182 K/snap * 24 snaps/day)
| AWR size/wk 193.9 MB (size_per_day * 7) per instance
|
| Estimates based on 4 snaps in past 24 hours:
| AWR size/day 4.6 MB (1,182 K/snap and 4 snaps in past 24 hours)
| AWR size/wk 32.3 MB (size_per_day * 7) per instance
|



Donde podemos ver claramente cuanto pesan nuestros Snaps por día.

Una vez que hemos realizado los cálculos necesarios para chequear el tamaño del tablespace SYSAUX , procedemos a cambiar el intervalo de retención y el intervalo de captura de nuestros snapshots de AWR, para ello ejecutamos el siguiente package

execute dbms_workload_repository.modify_snapshot_settings (
interval => xx,
retention => xxxxx );



Donde le indicamos el intervalo para sacar snapshots en minutos y el período de retención en segundos, ejemplo :

Para sacar los snapshots cada 60 minutos con una retención de 69 días

1 begin
2 dbms_workload_repository.modify_snapshot_settings (interval => 60,retention => 100000 );
3* end;
SQL> /

PL/SQL procedure successfully completed.


Una vez modificado podemos consultar nuevamente el seteo

SQL> select
2 extract( day from snap_interval) *24*60+
3 extract( hour from snap_interval) *60+
4 extract( minute from snap_interval ) "Intervalo entre Snaps",
5 extract( day from retention) *24*60+
6 extract( hour from retention) *60+
7 extract( minute from retention ) "Periodo de retencion seg" ,
8 extract( day from retention) "Periodo de retencion dias"
9 from dba_hist_wr_control;

Intervalo entre Snaps Periodo de retencion seg Periodo de retencion dias
--------------------- ------------------------ -------------------------
60 100000 69

Espero les sirva...

by Ligarius
06.05.13. 14:21:52. 688 words, 4634 views. Categories: Base de datos, Tuning / Performance ,

Cosas sobre sys.col_usage$



La tabla sys.col_usage$ almacena de forma automática a través del proceso SMON , la cantidad de veces que alguna columna se ocupa en una claúsula WHERE de una sentencia SQL, si esto lo miramos con un poco de altura de miras, no solamente veremos que es información estadística que se almacena para siempre y por siempre, he acá algunas cosas para tener en cuenta



Desde está información por ejemplo nosotros podríamos chequear cual es el mejor índice o cuales son los índices necesarios en una tabla de acuerdo a los filtros que tenga..

La estructura de la tabla

SQL> desc sys.col_usage$
Name Null? Type
----------------------------------------- -------- -----------------------
OBJ# NUMBER
INTCOL# NUMBER
EQUALITY_PREDS NUMBER
EQUIJOIN_PREDS NUMBER
NONEQUIJOIN_PREDS NUMBER
RANGE_PREDS NUMBER
LIKE_PREDS NUMBER
NULL_PREDS NUMBER
TIMESTAMP DATE



La explicación de sus columnas

OBJ# : Es el id del objeto (tabla principal) , este id lo podemos ubicar en DBA_OBJECTS.OBJECT_ID

INTCOL# : Es el id de la columna, se puede obtener su nombre desde DBA_TAB_COLUMNS.COLUMN_ID

EQUALITY_PREDS : Es la cantidad de filtros en el where del tipo
ej : where campo1 = -literal-

EQUIJOIN_PREDS : Es la cantidad de filtros en el where del tipo
ej : where tabla1.campo1 = tabla2.campo1

NONEQUIJOIN_PREDS : Es la cantidad de filtros en el where del tipo
ej : where tabla1.campo1 =! tabla2.campo1

RANGE_PREDS : Es cuando el campo es utilizado dentro de una claúsula BETWEEN

LIKE_PREDS : Es cuando el campo es utilizado dentro de una claúsula LIKE

NULL_PREDS : Es cuando se consulta por si el campo es nulo o no nulo
ej : where tabla1.campo1 is null

TIMESTAMP : Es la fecha en que se produjo la última utilización de fitros (where) para un objeto en partícular.



Una forma más amistosa de chequear los datos de la tabla SYS.COL_USAGE$ es mediante la siguiente consulta, que entrega los nombres de los objetos y claro, el nombre de la columna de forma inmediata

select oo.name owner,
o.name,
c.name column_name,
u.equality_preds,
u.equijoin_preds,
u.nonequijoin_preds,
u.range_preds,
u.like_preds,
u.null_preds,
u.timestamp
from sys.col_usage$ u ,
sys.obj$ o ,
sys.user$ oo,
sys.col$ c
where o.obj# = u.obj#
and oo.user# = o.owner#
and c.obj# = u.obj#
and c.col# = u.intcol#
AND o.name = 'nombre del objeto a consultar'



Esta tabla también tiene la gracia que a partir de ahí Oracle puede generar los histogramas cuando se ocupa el package DBMS_STATS con el parámetro METHOD_OPT => 'FOR all COLUMNS SIZE auto', o sea, le indicamos a él que calcule la cantidad de buckets para nuestro histograma (de 1 a 256)

Si hacemos lo siguiente

- Generamos una tabla
- Cargamos datos en la tabla
- Generamos histogramas

No estaría correcto, ya que los histogramas no se van a generar con información fidedigna , a menos que haya información en la SYS.COL_USAGE$ y solamente habrá información en esa tabla si comenzamos a utilizar filtros en la consultas que ocupan esa tabla

A partir de Oracle10g la información se carga a esta tabla cuando se produce una toma de estadísticas o se puede hacer ejecutando la siguiente instrucción

exec dbms_stats.flush_database_monitoring_info;



La carga de está información se realiza con una frecuencia de minutos , quizás podríamos decir unos 15 , o cuando se hace alguna actualización o inserción , como podemos apreciar de distintas fuentes está tabla SYS.COL_USAGE$ se actualiza

by Ligarius
04.03.13. 07:32:11. 610 words, 3563 views. Categories: Base de datos, Tuning / Performance ,

Eliminando un nodo desde RAC 11gr2



Antes de hablar del post, les comento algo importante :yes: , ayer ví la película "The Pact - 2012" y la verdad, encontré la perfección...se las presento (Caity Lotz)




Con respecto al post, les dejo un documento detallado de como eliminar un nodo en un RAC , las versiones que se utilizan

Linux x86 de 64 bits
Oracle 11gr2 (11.2.0.3) 64 bits
3 nodos


Aparece el paso a paso , los pantallazos y salidas de todos los comandos .
Borrar un nodo en un RAC 11gr2

Links relacionados
Add node to RAC 11gr2

Espero les sirva


by Ligarius
25.02.13. 16:28:31. 90 words, 5091 views. Categories: Instalación, Oracle11gR2, Real Application Cluster ,

Graficar información de crecimiento de tablespaces



Siempre estamos pensando el como obtenemos información de crecimiento de un tablespaces, algo así como para saber mes a mes o semana a semana como ha crecido .


Pues bien, existe una forma muy útil que les paso a comentar...


Lo primero que debemos tener en cuenta es desde que fecha a que fecha queremos generar la información , para ello ocupamos la información de los Snapshots que ha producido nuestra base de datos mediante la siguiente consulta.

select instance_number , snap_id ,
to_char(begin_interval_time,'dd-mm-yyyy hh24:mi:ss') "Intervalo inicio",
to_char(end_interval_time,'dd-mm-yyyy hh24:mi:ss') "Intervalo termino" ,
snap_level
from dba_hist_snapshot
order by snap_id asc


Desde acá debemos obtener los snap_id de inicio y término , para el caso de ejemplo que desarrollamos pues tomaremos el mes completo de Noviembre del 2012.

Además de lo anterior, incorporamos el número del tablespaces, está información la podemos obtener desde la siguiente consulta

select ts# , name from v$tablespace


Ejecutamos la siguiente consulta que trae los datos que necesitamos para saber el crecimiento semana a semana de nuestro tablespaces..

select max(vt.NAME) "Nombre tablespace" ,
to_char(to_date(tb.rtime,'mm-dd-yyyy hh24:mi:ss'),'yyyy-ww') "Fecha de la muestra",
max(round(tb.tablespace_size * dt.block_size/1024/1024/1024,2)) "Tamaño GB",
max(round(tb.tablespace_usedsize * dt.block_size/1024/1024/1024,2)) "Tamaño usado GB"
from SYS.WRH$_TABLESPACE_SPACE_USAGE tb ,
v$tablespace vt ,
dba_tablespaces dt
where vt.TS# = tb.tablespace_id
and vt.NAME = dt.tablespace_name
and vt.ts# = 0
and tb.snap_id <= 123450
and tb.snap_id >= 103947
group by to_char(to_date(tb.rtime,'mm-dd-yyyy hh24:mi:ss'),'yyyy-ww')
order by 3


Ciertas cosas a tener en cuenta :

- Los datos que aparecen en la tabla SYS.WRH$_TABLESPACE_SPACE_USAGE relacionados a espacios , son presentados como número de bloques, por ende hay que realizar la multiplicación con el tamaño del bloque que le corresponde a cada tablespaces.

- En la consulta realizamos el filtro por el número del tablespace, específicamente el campo vt.ts#

- La tabla SYS.WRH$_TABLESPACE_SPACE_USAGE forma parte de la vista dba_hist_tbspc_space_usage , la información de la vista es similar a la información de la tabla , pero tiene otros filtros asociados a los snap_id

- La información del tamaño del tablespace y de su tamaño utilizado se expresa por semanas


Una vez ejecutada la consulta obtenemos los datos para poder armar un gráfico..


Y el gráfico, una vez construído con Excel o hasta con Open Office :) , quedaría así...


Se puede apreciar que por cada semana , se ve en el gráfico el tamaño del tablespace versus el tamaño realmente utilizado, con ello podemos analizar si llevamos a cabo una asignación de espacio, quizás sea conveniente verificar los niveles de fragmentación, también reasignar espacio para tablespaces con mucho espacio libre , etc , etc...

Para tomar medidas hay que estar informado :>>

by Ligarius
20.12.12. 11:14:44. 509 words, 5372 views. Categories: Base de datos ,

ORA-12541: TNS:no listener en Switchover con DGMGRL



A continuación les mostraré un error que sucede con demasiada frecuencia al momento de hacer un Switchover en un Dataguard construído en Oracle 11g y que cuesta un poco encontrarlo

Y que aparece como un terrible ORA-12541: TNS:no listener




Para hacer un seguimiento al error, llevamos a cabo los siguientes


Nos conectamos desde cualquier nodo (Standby o primario) al DGMGRL

[oracle@nodo1-dg] $ dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/oracle1
Connected.



Mostramos la configuración generada y verificamos cual es nuestra Standby y nuestra base primaria

DGMGRL> show configuration

Configuration - conf_dgprod

Protection Mode: MaxPerformance
Databases:
prod2 - Primary database
prod - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS



Procedemos a realizar el Switchover

DGMGRL> switchover to prod;
Performing switchover NOW, please wait...
New primary database "prod" is opening...
Operation requires shutdown of instance "prod" on database "prod2"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod2"
Starting instance "prod"...
Unable to connect to database
ORA-12541: TNS:no listener

Failed.
Warning: You are no longer connected to ORACLE.

Please complete the following steps to finish switchover:
start up and mount instance "prod" of database "prod2"

DGMGRL> quit



Y dentro del Switchover aparece el mensaje

ORA-12541: TNS:no listener

Acá vienen los cuestionamientos y preguntas, ya que si hacemos la conexión mediante TCP/IP con los string de conexión, no existen inconvenientes...entonces debemos buscar el error por otro lado



Por lo pronto, subimos la base de datos Standby que no se pudo hacer a través del Switchover

[oracle@nodo1-dg] $ sqlplus sys/oracle1@PROD2 as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Sep 26 16:50:45 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SQL> startup force nomount
ORACLE instance started.

Total System Global Area 1071333376 bytes
Fixed Size 1349732 bytes
Variable Size 226494364 bytes
Database Buffers 838860800 bytes
Redo Buffers 4628480 bytes
SQL> alter database mount standby database;

Database altered.

SQL> quit



Chequeamos la configuración para ver si ambas bases están disponibles

DGMGRL> show configuration

Configuration - conf_dgprod

Protection Mode: MaxPerformance
Databases:
prod - Primary database
prod2 - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS



Ahora vemos un detalle más acabado de la configuración , quizás podemos ver si por aquí está nuestro error

DGMGRL> show database verbose 'prod';

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS



De hecho, hay algo que nos debería llamar la atención, que es la configuración de este parámetro StaticConnectIdentifier

StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'



En este parámetro aparece un puerto que no corresponde al puerto que tenemos realmente nuestro listener, ya que estamos escuchando por el puerto 1530


Por ende , procedemos a cambiar ese parámetro dentro de la configuración del DGMGRL

DGMGRL> edit database 'prod' set property 'StaticConnectIdentifier'='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
> ;
Property "StaticConnectIdentifier" updated
DGMGRL>



Mostramos nuevamente la la configuración en detalle de nuestras bases de datos configuradas en el DGMGRL

DGMGRL> show database verbose 'prod';

Database - prod

Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = ''
LogFileNameConvert = ''
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo1-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS

DGMGRL>



Chequemos lo mismo en el nodo2

DGMGRL> connect sys/oracle1
Connected.
DGMGRL>
DGMGRL> show database verbose 'prod2';

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod2'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '/u02, /u03'
LogFileNameConvert = '/u02, /u03'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS



Y vemos que también tiene problemas en el puerto del listener que está configurado


Editamos la propiedad StaticConnectIdentifier y le cambiamos el puerto

DGMGRL> edit database 'prod2' set property 'StaticConnectIdentifier'='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))';
Property "StaticConnectIdentifier" updated
DGMGRL>



Mostramos la configuración en detalle

DGMGRL> show database verbose 'prod2'

Database - prod2

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: OFF
Instance(s):
prod

Properties:
DGConnectIdentifier = 'prod2'
ObserverConnectIdentifier = ''
LogXptMode = 'ASYNC'
DelayMins = '0'
Binding = 'optional'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '30'
RedoCompression = 'DISABLE'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '4'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '/u02, /u03'
LogFileNameConvert = '/u02, /u03'
FastStartFailoverTarget = ''
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
SidName = 'prod'
StaticConnectIdentifier = '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=nodo2-dg.oracleyyo.com)(PORT=1530))(CONNECT_DATA=(SERVICE_NAME=prod2_DGMGRL)(INSTANCE_NAME=prod)(SERVER=DEDICATED)))'
StandbyArchiveLocation = 'USE_DB_RECOVERY_FILE_DEST'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = 'arc_%t_%s_%r.arc'
TopWaitEvents = '(monitor)'

Database Status:
SUCCESS

DGMGRL>



Y vemos que ya han sido cambiado los datos, después de esto realizamos nuevamente el Switchover de ida y vuelta, sin ningún problema

DGMGRL> switchover to prod2;
Performing switchover NOW, please wait...
New primary database "prod2" is opening...
Operation requires shutdown of instance "prod" on database "prod"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod"
Starting instance "prod"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prod2"


DGMGRL> switchover to prod;
Performing switchover NOW, please wait...
New primary database "prod" is opening...
Operation requires shutdown of instance "prod" on database "prod2"
Shutting down instance "prod"...
ORACLE instance shut down.
Operation requires startup of instance "prod" on database "prod2"
Starting instance "prod"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "prod"
DGMGRL>


Asunto arreglado :>>

by Ligarius
17.10.12. 10:01:31. 1344 words, 8644 views. Categories: Base de datos, StandBy - Data Guard ,

<< 1 ... 4 5 6 7 8 9 10 11 12 13 14 ... 27 >>