MERCADOS FINANCIEROS

viernes, 22 de junio de 2012

Grid Control

Administración de Grid Control

Introducción
Grid Control se compone de una serie de servicios, cada uno de los cuales está instalado en su propio HOME y que pueden y deben ser manejados separadamente. El objetivo de este manual es presentar de manera concreta los comandos necesarios para levantar, detener y monitorear todos estos servicios. Las partes correspondientes a levantar y detener los servicios deben ejecutarse en el orden indicado.


Variables de ambiente
Es recomendable definir las siguientes variables de ambiente:

# Variables de ambiente para Grid Control
OMS_HOME=/opt/oracle/OracleHomes/oms10g
export OMS_HOME
AGENT_HOME=/opt/oracle/OracleHomes/agent10g
export AGENT_HOME
ORACLE_HOME=/opt/oracle/OracleHomes/db10g
export ORACLE_HOME
ORACLE_SID=emrep
export ORACLE_SID
PATH=$PATH:$OMS_HOME/bin:$AGENT_HOME/bin:$ORACLE_HOME/bin:$OMS_HOME/opmn/bin
export PATH
En este caso se asume que la instalación de Grid Control se hizo en el directorio /opt/oracle, en caso de encontrarse en una ubicación diferente, realizar los cambios necesarios en las variables de ambiente.


Levantar todos los servicios

1. Levantar el listener:

$ $ORACLE_HOME/bin/lsnrctl start
2. Levantar la base de datos:

$ $ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> startup
SQL> quit
3. Levantar OMS (Oracle Management Service):

$ $OMS_HOME/bin/emctl start oms
4. Levantar todos los componentes de Application Server (web cache, http server):

$ $OMS_HOME/opmn/bin/opmnctl startall
5. Levantar el agente:

$ $AGENT_HOME/bin/emctl start agent
6. (Opcional) Levantar el Application Server Control Console:

$ $OMS_HOME/bin/emctl start iasconsole


Detener todos los servicios

1. Detener el OMS:

$ $OMS_HOME/bin/emctl stop oms
2. Detener, si está arriba, el Application Server Control Console:

$ $OMS_HOME/bin/emctl stop iasconsole
3. Detener todos los componentes del Application Server (http server, web cache, etc.):

$ $OMS_HOME/opmn/bin/opmnctl stopall
4. Detener el agente:

$ $AGENT_HOME/bin/emctl stop agent
5. Detener la base de datos

$ $ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
SQL> quit
6. Detener el listener:

$ $ORACLE_HOME/bin/lsnrctl stop


Monitorear los servicios
Agente:

$AGENT_HOME/bin/emctl status agent
OMS (Oracle Management Service):

$ $OMS_HOME/bin/emctl status oms
Componentes de Application Server:

$ $OMS_HOME/opmn/bin/opmnctl status


Detener OCSSD.BIN
El proceso $ORACLE_HOME/bin/ocssd.bin se levanta automáticamente como parte de la instalación de RDBMS incluida en Grid Control. Dicho proceso no requiere administración alguna, sin embargo, de ser necesario detenerlo (generalmente durante la aplicación de parches), el proceso correcto para hacerlo es (con el usuario root):

# /etc/init.d/init.cssd stop


$AGENT_HOME/sysman/emd/state
export AGENT_HOME=/opt/oracle/product/agent10g/
echo $AGENT_HOME
rm –Rf $AGENT_HOME/sysman/emd/upload/*.*
rm –Rf $AGENT_HOME/sysman/emd/state/*.*
$ ./emctl clearstate agent
$ ./emctl unsecure agent
$ ./emctl start agent
$ ./emctl upload agent
$ ./emctl secure agent


OTROS COMANDOS


This document will detail the steps required to stop and start Oracle Enterprise Manager 11g Grid Control and all its components. For information on installing Oracle Enterprise Manager 11g Grid Control see the post Install Oracle Enterprise Manager Grid Control 11gR1 on Linux.



In this document I will be making references to the OMS_HOME and AGENT_HOME. If you do not happen to know what those locations are you can find them in the /etc/oratab file.

1
2
3
4
[oracle@gc bin]$ grep -E 'oms|agent' /etc/oratab
*:/u02/app/oracle/product/weblogic/oms11g:N
*:/u02/app/oracle/product/weblogic/agent11g:N
[oracle@gc bin]$

So in this example the OMS_HOME would be /u02/app/oracle/product/weblogic/oms11g and AGENT_HOME would be /u02/app/oracle/product/weblogic/agent11g.

NOTE: The Oracle Enterprise Manger 11g Grid Control install process puts a script called gcstartup in /etc/init.d that will stop and start the Oracle Management Service and Agent on OS startup/shutdown. It does not start or stop the repository database. If you would like to stop the automated startup/shutdown of Grid Control services place comments in front of the OMS and AGENT home directories in the /etc/oratab file or remove the script /etc/init.d/gcstartup.

Stopping Oracle Enterprise Manager 11g Grid Control

Stop the Oracle Management Service

From the OMS_HOME directory run the following to stop the OMS and WebTier services.

1
2
3
4
5
6
7
8
9
10
11
OMS_HOME/bin/emctl stop oms –all
[oracle@gc ~]$ /u02/app/oracle/product/weblogic/oms11g/bin/emctl stop oms -all
Oracle Enterprise Manager 11g Release 1 Grid Control
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
Stopping WebTier...
WebTier Successfully Stopped
Stopping Oracle Management Server...
Oracle Management Server Successfully Stopped
Oracle Management Server is Down
[oracle@gc ~]$

Note if you do not include the –all flag the HTTP services for the WebLogic Server will not be shutdown.

Stop the Oracle Management Agent

From the AGENT_HOME directory run the following to stop the Agent.

1
2
3
4
5
6
7
AGENT_HOME/bin/emctl stop agent
[oracle@gc ~]$ /u02/app/oracle/product/weblogic/agent11g/bin/emctl stop agent
Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
Stopping agent ... stopped.
[oracle@gc ~]$

Stop the repository database

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[oracle@gc ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Tue May 11 11:41:21 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@gc ~]$

Stop the Listener

1
2
3
4
5
6
7
8
9
[oracle@gc ~]$ lsnrctl stop
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 11-MAY-2010 11:42:03
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=gc)(PORT=1521)))
The command completed successfully
[oracle@gc ~]$

That is it. Oracle Enterprise Manager 11g Grid Control and all associated services are now shutdown.

Starting Oracle Enterprise Manager 11g Grid Control


Start the Listener

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
[oracle@gc ~]$ lsnrctl start
LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 11-MAY-2010 12:58:01
Copyright (c) 1991, 2009, Oracle. All rights reserved.
Starting /u02/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.1.0 - Production
System parameter file is /u02/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Log messages written to /u02/app/oracle/diag/tnslsnr/gc/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=gc.localdomain)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=gc)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.1.0 - Production
Start Date 11-MAY-2010 12:58:01
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u02/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Listener Log File /u02/app/oracle/diag/tnslsnr/gc/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=gc.localdomain)(PORT=1521)))
The listener supports no services
The command completed successfully
[oracle@gc ~]$

Start the repository database

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[oracle@gc ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.1.0 Production on Tue May 11 12:58:49 2010
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 1272213504 bytes
Fixed Size 1336260 bytes
Variable Size 805309500 bytes
Database Buffers 452984832 bytes
Redo Buffers 12582912 bytes
Database mounted.
Database opened.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@gc ~]$

Start the Oracle Management Service

From the OMS_HOME directory run the following to start the OMS and WebTier services

1
2
3
4
5
6
7
8
9
10
11
OMS_HOME/bin/emctl start oms
[oracle@gc ~]$ /u02/app/oracle/product/weblogic/oms11g/bin/emctl start oms
Oracle Enterprise Manager 11g Release 1 Grid Control
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
Starting WebTier...
WebTier Successfully Started
Starting Oracle Management Server...
Oracle Management Server Successfully Started
Oracle Management Server is Up
[oracle@gc ~]$

Start the Oracle Management Agent

From the AGENT_HOME directory run the following to start the Agent.

1
2
3
4
5
6
7
AGENT_HOME/bin/emctl start agent
[oracle@gc ~]$ /u02/app/oracle/product/weblogic/agent11g/bin/emctl start agent
Oracle Enterprise Manager 11g Release 1 Grid Control 11.1.0.1.0
Copyright (c) 1996, 2010 Oracle Corporation. All rights reserved.
Starting agent ........ started.
[oracle@gc ~]$

miércoles, 20 de junio de 2012

Keywords and Parameters

Syntax Element Description
%a Specifies the activation ID of the database.
%c Specifies the copy number of the backup piece within a set of duplexed backup pieces. If you did not duplex a backup, then this variable is 1 for backup sets and 0 for proxy copies. If one of these commands is enabled, then the variable shows the copy number. The maximum value for %c is 256.
%d Specifies the name of the database.
%D Specifies the current day of the month from the Gregorian calendar in format DD.
%e Specifies the archived log sequence number.
%f Specifies the absolute file number.
%F Combines the DBID, day, month, year, and sequence into a unique and repeatable generated name. This variable translates into c-IIIIIIIIII-YYYYMMDD-QQ, where:
  • IIIIIIIIII stands for the DBID. The DBID is printed in decimal so that it can be easily associated with the target database.
  • YYYYMMDD is a time stamp in the Gregorian calendar of the day the backup is generated
  • QQ is the sequence in hexadecimal number that starts with 00 and has a maximum of 'FF' (256)
%h Specifies the archived redo log thread number.
%I Specifies the DBID.
%M Specifies the month in the Gregorian calendar in format MM.
%N Specifies the tablespace name.
%n Specifies the name of the database, padded on the right with x characters to a total length of eight characters. For example, if the prod1 is the database name, then the padded name is prod1xxx.
%p Specifies the piece number within the backup set. This value starts at 1 for each backup set and is incremented by 1 as each backup piece is created. Note: If you specify PROXY, then the %p variable must be included in the FORMAT string either explicitly or implicitly within %U.
%s Specifies the backup set number. This number is a counter in the control file that is incremented for each backup set. The counter value starts at 1 and is unique for the lifetime of the control file. If you restore a backup control file, then duplicate values can result. Also, CREATE CONTROLFILE initializes the counter back to 1.
%t Specifies the backup set time stamp, which is a 4-byte value derived as the number of seconds elapsed since a fixed reference time. The combination of %s and %t can be used to form a unique name for the backup set.
%T Specifies the year, month, and day in the Gregorian calendar in this format: YYYYMMDD.
%u Specifies an 8-character name constituted by compressed representations of the backup set or image copy number and the time the backup set or image copy was created.
%U Specifies a system-generated unique filename (default). The meaning of %U is different for image copies and backup pieces. For a backup piece, %U specifies a convenient shorthand for %u_%p_%c that guarantees uniqueness in generated backup filenames. If you do not specify a format when making a backup, then RMAN uses %U by default.
For an image copy of a datafile, %U means the following:
data-D-%d_id-%I_TS-%N_FNO-%f_%u
For an image copy of an archived redo velog, %U means the following:
arch-D_%d-id-%I_S-%e_T-%h_A-%a_%u
For an image copy of a control file, %U means the following:
cf-D_%d-id-%I_%u
%Y Specifies the year in this format: YYYY.
%% Specifies the literal '%' character. For example, %%Y translates to the string %Y.

Example

Specifying an ASM Disk Group: Example This example copies the database to ASM disk group disk1:
BACKUP AS COPY DATABASE FORMAT '+disk1'; 

Specifying a Format for Datafile Copies: Example This example creates copies of three datafiles with tag 'LATESTCOPY' to directory /copies:
# Create copies of 3 datafiles with tag 'LATESTCOPY' to directory /copies
BACKUP AS COPY 
  FROM TAG 'LATESCOPY' 
  COPY OF DATAFILE 4, 6, 14 
  FORMAT '/copies/Datafile%f_Database%d';

Creating a Database Copy for Use as a Standby Database: Example This example creates an image copy of the database to instantiate a physical standby in /stby:
# Create an image copy of the database to instantiate physical standby in /stby 
BACKUP AS COPY 
  DATABASE 
  FORMAT '/stby/standby_file_%f_of_db_%I';

viernes, 15 de junio de 2012

CREATE TABLESPACE TEMPORAL 11G

CREATE TEMPORARY TABLESPACE temp1
TEMPFILE 'I:\oracle\vdm\SAPDATA1\TEMP_1\temp1.temp1' SIZE 5 G
EXTENT MANAGEMENT LOCAL

miércoles, 6 de junio de 2012

Raid 5 Linux

Historia
La tecnología RAID fue definida por primera vez en 1987 por un grupo de informáticos de la Universidad de California, Berkeley. Este grupo estudió la posibilidad de usar dos o más discos que aparecieran como un único dispositivo para el sistema.
En 1988, los niveles RAID 1 a 5 fueron definidos formalmente por David A. Patterson, Garth A. Gibson y Randy H. Katz en el ensayo "Un Caso para Conjuntos de Discos Redundantes Económicos (RAID)" (A Case for Redundant Arrays of Inexpensive Disks (RAID)), publicado en la Conferencia SIGMOD de 1988 (págs. 109-116) PDF original. El término «RAID» se usó por vez primera en este ensayo, que dio origen a toda la industria de los conjuntos de discos.
[editar]
¿Para que sirve?
Así pues una RAID sirve para crear un único volumen lógico, el cual físicamente esté compuesto por varios discos físicos. Dependiendo de que modo de RAID utilicemos, ésto nos servirá para conseguir simplemente un volumen de capacidad mayor, o para conseguir un volumen con mayor seguridad contra fallos de hardware de los discos que lo componen gracias al almacenamiento redundante de estos.
Hay que tener en cuenta que cuando hablamos de Software RAID, siempre que hablamos de discos debemos entender que hablamos de particiones.
[editar]
Modos básicos de RAID
[editar]
Modo Lineal (Linear mode)
Dos o más discos se combinan en un único dispositivo físico. Los discos se «adjuntan» unos a otros de tal manera que las escrituras en el dispositivo RAID primero llenarán el disco 0, a continuación el disco 1 y así sucesivamente. Los discos no tienen porqué ser del mismo tamaño. De hecho, los tamaños no importan para nada aquí. Se trata de una simple concatenación de discos
No existe redundancia en este nivel. Si un disco falla perderá toda su información con toda probabilidad. Sin embargo, puede tener suerte y recuperar algunos datos, ya que el sistema de ficheros simplemente habrá perdido un gran puñado de datos consecutivos.
El rendimiento de las lecturas y las escrituras no se incrementará para lecturas/escrituras individuales. Pero si varios usuarios usan el dispositivo, puede tener la suerte de que un usuario use efectivamente el primer disco y el otro usuario acceda a ficheros que por casualidad residan en el segundo disco. Si esto ocurre, verá un aumento en el rendimiento.
[editar]
RAID0 (Striped)
También llamado modo striping o de distribución por bandas. Como el modo lineal salvo que las lecturas y escrituras se realizan en paralelo en los dispositivos. Éstos deben tener aproximadamente el mismo tamaño. Puesto que todos los accesos se realizan en paralelo, los discos se llenan por igual. Si un dispositivo es mucho mayor que los otros demás, el espacio extra se utilizará en el dispositivo RAID durante las escrituras en el extremo superior, aunque sólo se accederá a este disco más grande. Naturalmente, esto perjudica el rendimiento.
Como en el modo lineal, tampoco hay redundancia en este nivel. A diferencia del modo lineal, no será capaz de recuperar ningún dato si un disco falla. Si elimina un disco de un grupo RAID-0, el dispositivo RAID no perderá simplemente un bloque consecutivo de datos, sino que se llenará con pequeños agujeros por todo el dispositivo.
El rendimiento de las lecturas y las escrituras se incrementará, ya que las lecturas y las escrituras se realizan en paralelo sobre los dispositivos. Normalmente, ésta es la razón principal para usar RAID-0.Si los buses a los discos son suficientemente rápidos, puede obtener casi N*rendimiento de cada disco MiB/seg.
[editar]
RAID1 (Mirrored)
Este es el primer modo que realmente tiene redundancia. RAID-1 se puede usar en dos discos idénticos. Este modo mantiene en un disco un duplicado exacto de la información del otro disco.
Si uno falla, los datos permanecerán intactos, puesto que tendremos el otro disco.
Normalmente, el rendimiento de las lecturas es la suma de los rendimientos de los discos, mientras que el rendimiento de las escrituras es el mismo que el de un único dispositivo o, tal vez, incluso menos. Las lecturas se pueden hacer en paralelo pero, cuando se escribe, la CPU debe transferir 2 veces la cantidad de datos que normalmente transferiría (se deben enviar 2 copias idénticas de todos los datos, una a cada disco).
[editar]
RAID3 y RAID4
Este nivel de RAID no se usa con mucha frecuencia. Se puede usar sobre 3 o más discos. En lugar de duplicar completamente la información, guarda información de paridad en un único disco y escribe datos a los otros discos de forma parecida a un RAID-0. Ya que uno de los discos se reserva para información de paridad, el tamaño del array será (N-1)*S, donde S es el tamaño del disco más pequeño del array. Como en un RAID1, los discos deben ser del mismo tamaño, o de lo contrario tendrá que aceptar que el valor de S en la fórmula (N-1)*S anterior será el tamaño del disco más pequeño del array.
Si un disco falla, y no es el de paridad, se puede usar la información de paridad para reconstruir todos los datos. Si dos discos fallan, se perderá toda la información.
La razón por la que estos niveles no se usan con mucha frecuencia es que la información de paridad se guarda en un único disco. Esta información se debe actualizar cada vez que se escribe en uno de los otros discos. Por eso, el disco de paridad se convertirá en un cuello de botella si no es mucho más rápido que los otros discos.
[editar]
RAID5
Este es quizás el modo RAID más útil cuando uno desea combinar un mayor número de discos físicos y todavía conservar redundancia. RAID5 se puede usar sobre 3 o más discos. El tamaño del dispositivo RAID5 resultante será (N-1)*S, tal y como sucede con RAID4. La gran diferencia entre RAID5 y RAID4 es que la información de paridad se distribuye uniformemente entre los discos participantes, evitando el problema del cuello de botella del RAID4.
Si uno de los discos falla, todos los datos permanecerán intactos, gracias a la información de paridad. Si dos discos fallan simultáneamente, todos los datos se perderán. RAID5 puede sobrevivir a un fallo de disco, pero no a dos o más.
El rendimiento de lectura de RAID5 es equiparable al de RAID0 con el mismo numero de discos. Exceptuando los bloques de paridad, los cuales pueden causar un ligero relentimiento en las escrituras (en las lecturas no se usan los bloques de paridad de no ser que algún disco falle).
[editar]
RAID6
La idea es la misma que RAID5, solo que se agrega un segundo algoritmo de paridad a parte del XOR normal, por tanto permite la perdida de 2 discos fisicos, el tamaño del RAID6 resultante será (N-2)*S.
Mas información sobre los sistemas básicos de RAID (English) (Español)

[editar]
Otros modos de RAID
Existen multitud de modos de RAID basados en la convención de diferentes RAIDs, es decir se utiliza un conjunto de RAIDs en un determinado sistema para crear una nueva RAID en -normalmente- otro sistema. Algunos de éstos sistemas son: RAID01, RAID10, RAID03, RAID30, RAID50, RAID51 (también llamada RAID53), RAID60, y RAID 100.
Mas información sobre Otros modos de RAID

[editar]
Paquete mdadm
[editar]
mdadm para crear RAIDs por software
Para la creación y administración de una RAID por software necesitaremos el paquete mdadm.
La antigua colección de utilidades para RAID de los paquetes raidtools y raidtools2 se ha dejado de usar actualmente puesto que dependía de un fichero de configuración (/etc/raidtab) difícil de mantener, y sus funciones eran limitadas. Desde agosto de 2001, existe la herramienta mdadm (multiple devices admin), éste paquete nos permite gestionar las RAIDs por software de una manera mucho mas simple y robusta. Actualmente se ha convertido en un estándar.

[editar]
Instalar mdadm en Ubuntu
En principio el paquete mdadm viene instalado por defecto en Ubuntu.
Asimismo si no disponéis del paquete instalado podéis instalarlo con el Gestor de paquetes Synaptic o bien con el siguiente comando:
$ sudo apt-get install mdadm
[editar]
cargar el módulo raid
Para que ubuntu pueda trabajar con las RAID puede ser necesario cargar primero el módulo correspondiente.
$ sudo modprobe raid1
o
$ sudo modprobe raid0
si se quiere un RAID0, o los dos si quieres usar ambos tipos de RAID.
[editar]
Crear una RAID
En el caso ejemplo que voy a exponer crearé una RAID5 con 4 discos. Asimismo este procedimiento se puede seguir mas o menos de manera análoga para crear cualquier tipo de RAID.
[editar]
Particionamiento
Debemos tener en cuenta, que puesto que vamos a crear una Software RAID, vamos a utilizar particiones en lugar de discos. Sin perjuicio que cada disco contenga una sola partición con la totalidad del tamaño del disco, como de hecho es indicado.
Así pues primeramente debemos preparar las particiones que vamos a utilizar para crear la RAID.
Para esto podemos utilizar cualquier herramienta de particionamiento. En nuestro caso vamos a utilizar GParted, una herramienta gráfica de fácil uso. Puesto que Ubuntu no la lleva instalada por defecto la instalaremos mediante el Gestor de paquetes Synaptic, o bien con apt-get mediante comandos:
$ sudo apt-get install gparted
Una vez instalado GParted, procedemos a crear una partición para la totalidad de cada uno de los discos idénticos de los que disponemos para crear la RAID. Debemos crear una partición sin formato, puesto que el formato de la RAID lo daremos cuando esta esté construida. A parte del formato debemos indicar que se tratará de un disco para crear una RAID. Esto lo podemos hacer de manera fácil con GParted, seleccionando la partición e yendo a Menú Partición>gestionar señaladores y marcando el señalador "RAID", tal y como muestran las imágenes.


GParted con partición sin formato y con señalador RAID

Marcar la partición como RAID no es vital para el funcionamiento de la RAID, asimismo es la manera más correcta de hacerlo y nos ayudará a distinguir las particiones en un futuro. Con fdisk veremos este hecho marcado como "Autodetección Linux raid" (Linux raid autodetect). Una vez acabado el proceso podemos ver con fdisk -l un listado de las particiones como el siguiente (esta en Català puesto a que mi sistema está en este idioma):
$ sudo fdisk -l

Disc /dev/sdb: 200.0 GiB, 200049647616 octets
255 capçals, 63 sectors/pista, 24321 cilindres
Unitats = cilindres de 16065 * 512 = 8225280 octets

Dispositiu Arrenc. Comença Acaba Blocs Id Sistema
/dev/sdb1 1 24321 195358401 fd Autodetecció Linux raid

Disc /dev/sdc: 200.0 GiB, 200049647616 octets
255 capçals, 63 sectors/pista, 24321 cilindres
Unitats = cilindres de 16065 * 512 = 8225280 octets

Dispositiu Arrenc. Comença Acaba Blocs Id Sistema
/dev/sdc1 1 24321 195358401 fd Autodetecció Linux raid

Disc /dev/sdd: 200.0 GiB, 200049647616 octets
255 capçals, 63 sectors/pista, 24321 cilindres
Unitats = cilindres de 16065 * 512 = 8225280 octets

Dispositiu Arrenc. Comença Acaba Blocs Id Sistema
/dev/sdd1 1 24321 195358401 fd Autodetecció Linux raid

Disc /dev/sde: 200.0 GiB, 200049647616 octets
255 capçals, 63 sectors/pista, 24321 cilindres
Unitats = cilindres de 16065 * 512 = 8225280 octets

Dispositiu Arrenc. Comença Acaba Blocs Id Sistema
/dev/sde1 1 24321 195358401 fd Autodetecció Linux raid
Podemos observar que la columna Id muestra el valor "fd" esto es debido a que lo hemos marcado como "Autodetección Linux raid" (Linux raid autodetect).
[editar]
Creación de la RAID
Primeramente antes de crear la RAID podemos ver en el fichero /proc/mdstat si al algún otro array:
$ cat /proc/mdstat
Personalities :
Event: 0
unused devices:
Vemos que no aparece ningún array.
Proseguimos a la creación del md en el que crearemos la RAID. Para ello utilizaremos el comando mknod como se muestra en la siguiente orden:
$ sudo mknod /dev/md0 b 9 0
Si ya tuviéramos algún otro array llamado md0, podemos crear un md diferente: md1, md2, ...
Procedemos ahora a crear finalmente la RAID:
$ sudo mdadm --create /dev/md0 --level=raid5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
Continue creating array? yes
mdadm: array /dev/md0 started.
La raid hecho esto empezará a crearse.
Detalles del comando mdadm --create /dev/md0 --level=raid5 --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 :
En --create /dev/md0 le indicaremos el md al que vamos a asignar el array. Si hemos escogido otro lo deberemos cambiar aquí.
En --level=raid5 indicaremos el tipo de raid que queremos que sea. Los valores validos aquí son: linear, raid0, 0, stripe, raid1, 1, mirror, raid4, 4, raid5, 5, raid6, 6, multipath, mp, fautly. Como vemos algunos de ellos son sinónimos, por lo que para una RAID5 podemos introducir "raid5" o bien "5".
Como vemos debemos indicarle las PARTICIONES (no los discos) con las que hacer la RAID, así como el numero de particiones: --raid-devices=4 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
otros modificadores útiles (no utilizados en el ejemplo):
--verbose nos explica mas cosas sobre lo que pasa.
--chunk= especifica cada segmento en kibibytes. Por defecto es 64. Ej: --chunk=32. Antes de decidir el tamaño del segmento es recomendable que consultes el apartado de Factores de optimización del sistema de archivos en una RAID de este mismo documento.
--parity= Establece el algoritmo de paridad para RAID5. Las opciones son: left-asymmetric, left-symmetric, right-asymmetric, right-symmetric (la, ra, ls, rs en sus versiones reducidas). Por defecto es left-symmetric. Ej: --parity=right-asymmetric. Este modificador tiene otras opciones avanzadas.
Para mas información sobre otros modificadores del comando mdadm consultad una pagina man.

Una vez hemos lanzado la orden de creación de la RAID, empezarán a trabajar los discos como locos: están creando la RAID. Este proceso puede durar varias horas dependiendo de la capacidad de los discos y la potencia del ordenador/discos.
Podemos visualizar en cualquier momento el estado de éste proceso en el fichero /proc/mdstat:
$ cat /proc/mdstat
Personalities : [raid5] [raid4]
md0 : active raid5 sdb1[0] sde1[3] sdd1[2] sdc1[1]
586075008 blocks [4/3] [UUU_]
[>....................] resync = 0.7% (4103401/586075008) finish=177.6min speed=97640K/sec
[4/3] [UUU_] nos indica el numero de discos que esta activo y correcto en este momento. No nos tenemos que preocupar porque durante éste periodo de creación de la RAID nos marque que hay alguno incorrecto. Cuando finalice el proceso éste indicador deberá mostrarnos que todos los discos están correctos.
Una vez ha terminado el proceso de construcción de la raid podemos ver de nuevo en el fichero /proc/mdstat el estado de nuestro array:
$ cat /proc/mdstat
Personalities : [raid5] [raid4]
md0 : active raid5 sdb1[0] sde1[3] sdd1[2] sdc1[1]
586075008 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices:
Perfecto!
Una vez creada la RAID solo debemos montarla y formatearla con el sistema de ficheros que deseemos.
[editar]
Formatear la RAID
Para formatear la RAID utilizaremos el comando mkfs:
Con ReiserFS
mkfs.reiserfs /dev/md0
En mi caso he utilizado el sistema de archivos ReiserFS, pero podemos utilizar cualquier otro como ext3:
Con ext3
mkfs.ext3 /dev/md0

[editar]
Montar la RAID
Para montar la RAID añadimos la siguiente línea al fichero /etc/fstab
/dev/md0 /punto_de_montaje sistema_de_archivos defaults,user 0 0
Recuerda que debes tener creada la carpeta /punto_de_montaje (la ruta que quieras), con los permisos correspondientes a los usuarios que quieras que accedan a la RAID. Recuerda también que debes especificar que sistema de archivos es la RAID cambiando sistema_de_archivos por reiserfs, ext3... según hayas escogido.
Para montar la raid bastara luego con hacer:
$ sudo mount /punto_de_montaje
O bien reiniciar y que Ubuntu la monte automáticamente en el inicio del sistema.

[editar]
Monitorización del estado una RAID y sus discos
Estado actual de los discos y unidades RAID
cat /proc/mdstat
$ cat /proc/mdstat
Personalities : [raid5] [raid4]
md0 : active raid5 sdb1[0] sde1[3] sdd1[2] sdc1[1]
586075008 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices:

Mas detalles sobre las unidades RAID
mdadm --query /dev/md0
$ sudo mdadm --query /dev/md0
/dev/md0: 558.92GiB raid5 4 devices, 0 spares. Use mdadm --detail for more detail.
mdadm --detail /dev/md0
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Sat Jan 20 17:27:56 2007
Raid Level : raid5
Array Size : 586075008 (558.92 GiB 600.14 GB)
Device Size : 195358336 (186.31 GiB 200.05 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent

Update Time : Sun Jan 21 22:23:05 2007
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0

Layout : left-symmetric
Chunk Size : 64K

UUID : d65ce83c:150ba8ab:cfc213b0:81723f7b
Events : 0.3084

Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
2 8 49 2 active sync /dev/sdd1
3 8 65 3 active sync /dev/sde1

Mas detalles de los discos
mdadm --query /dev/sdb1
$ sudo mdadm --query /dev/sdb1
/dev/sdb1: is not an md array
/dev/sdb1: device 0 in 4 device active raid5 /dev/md0. Use mdadm --examine for more detail.

mdadm --examine /dev/sdb1
$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
Magic : a92b4efc
Version : 00.90.00
UUID : d65ce83c:150ba8ab:cfc213b0:81723f7b
Creation Time : Sat Jan 20 17:27:56 2007
Raid Level : raid5
Device Size : 195358336 (186.31 GiB 200.05 GB)
Array Size : 586075008 (558.92 GiB 600.14 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0

Update Time : Sun Jan 21 22:23:05 2007
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Checksum : 7cd3d7e7 - correct
Events : 0.3084

Layout : left-symmetric
Chunk Size : 64K

Number Major Minor RaidDevice State
this 0 8 17 0 active sync /dev/sdb1

0 0 8 17 0 active sync /dev/sdb1
1 1 8 33 1 active sync /dev/sdc1
2 2 8 49 2 active sync /dev/sdd1
3 3 8 65 3 active sync /dev/sde1


[editar]
Administración de una RAID y sus discos
Establecer un disco como faulty/failed:
$ sudo mdadm --fail /dev/md0 /dev/sdb1

Quitar un disco fallido de una RAID:
$ sudo mdadm --remove /dev/md0 /dev/sdb1
Limpiar cualquier información previa de un disco RAID (Ej. al reutilizar un disco de otra raid antigua)
$ sudo mdadm --zero-superblock /dev/sdb1
Añadir un disco a la RAID
$ sudo mdadm --add /dev/md0 /dev/sdb1
Añadir soporte "bitmap" a un RAID
$ sudo mdadm --grow /dev/mdX --bitmap=internal
Quitar el soporte de "bitmap" a un RAID
$ sudo mdadm --grow /dev/mdX --bitmap=none
[editar]
Factores de optimización del sistema de archivos en una RAID
Hay diversos factores que pueden influir fuertemente en el rendimiento de una RAID de manera realmente muy importante.
He leído muy diversa información sobre algunos de estos aspectos, quedándome algunos mas claros que otros. Seguidamente apunto algunos de los factores que he encontrado. Asimismo si alguien tiene mayor conocimiento sobre alguno estaría muy interesante que lo complementara, o si es el caso lo corrigiera.
El sector (chunk) que elijamos para crear la RAID.: En un sistema con paridad (RAID4, RAID5 ...) para cada bloque que se escriba se deberá calcular el bloque de paridad. Esto incrementara o disminuirá el uso de procesador para estas tareas, pero por lo contrario -dependiendo del tipo de archivos que tengamos- nos hará perder o ahorrar espacio de disco.
El bloque (block) del sistema de archivos.: La repartición de los bloques en cada sector puede causar que haya unos discos con mucha mas carga de actividad que otros. Esto puede influir negativamente en el desgaste de los discos.
El propio sistema de archivos.: Los sistemas de archivos utilizan unos registros de transacciones que dependiendo del sistema de archivos comporta una u otra carga al procesador, se comporta de manera diferente en una RAID que en un disco normal y puede influir significativamente en el rendimiento.

Raid 1 en Linux

shian:~# fdisk /dev/hdb
Command (m for help): p

Disk /dev/hdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-2080, default 1):INTRO
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-2080, default 2080):INTRO
Using default value 2080

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): fd
Changed system type of partition 1 to fd (Linux raid autodetect)

Command (m for help): p

Disk /dev/hdb: 1073 MB, 1073741824 bytes
16 heads, 63 sectors/track, 2080 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 2080 1048288+ fd Linux raid autodetect

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
• Repetimos los pasos para /dev/hdc.
• Creamos el raid 1 con las dos particiones que acabamos de crear. En las opciones indicamos que el tipo de raid será 1 (mirror), que deseamos utilizar dos discos y que el nuevo dispositivo raid será /dev/md0.
shian:~# mdadm --create /dev/md0 --verbose --level=1 --raid-devices=2 /dev/hdb1 /dev/hdc1
mdadm: size set to 1048192K
mdadm: array /dev/md0 started.

NOTA: Si ya hemos usado el disco anteriormente para otro raid, es necesario reiniciar el superbloque para que se borre la información existente, puesto que sino, la creación puede fallar:
shian:~# mdadm --zero-superblock /dev/sdXX
• El raid 1 se está creando en segundo plano. En función del tamaño de los discos tardará más o menos. Se puede ver el estado en el archivo /proc/mdstat:
shian:~# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus1/target0/lun0/part1[1] ide/host0/bus0/target1/lun0/part1[0]
1048192 blocks [2/2] [UU]
[===========>.........] resync = 58.2% (611196/1048192) finish=0.0min speed=101866K/sec
unused devices:
• El porcentaje va subiendo hasta que finalmente el dispositivo está listo:
shian:~# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus1/target0/lun0/part1[1] ide/host0/bus0/target1/lun0/part1[0]
1048192 blocks [2/2] [UU]

unused devices:
• A partir de este momento para cualquier manipulación que deseemos hacer del raid debemos utilizar /dev/md0 y no /dev/hdb1 ni /dev/hdc1.
• Formateamos el raid
shian:~# mkfs.ext3 /dev/md0
mke2fs 1.37 (21-Mar-2005)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262048 blocks
13102 blocks (5.00%) reserved for the super user
First data block=0
8 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 22 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
• Creamos el punto de montaje, añadimos la entrada correspondiente para que el raid se monte cuando se arranca la máquina y lo montamos:
shian:~# mkdir /mnt/raid

shian:~# echo "/dev/md0 /mnt/raid ext3 defaults 0 1" >> /etc/fstab

shian:~# mount /mnt/raid

shian:~# df -h /dev/md0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 1008M 17M 941M 2% /mnt/raid
• Aquí ya habríamos terminado la instalación del raid y podríamos utilizarlo, aunque tal y como está configurado y montado sólo tendría permisos el usuario root.
A partir de aquí, lo que yo hice inicialmente fue simular que un disco duro se estropeaba y al arrancar la máquina quería montar el raid sólo con el otro disco y utilizarlo normalmente. Además, después de simular con la máquina virtual que añadía un nuevo disco duro, quería añadirlo al raid para volver a tener de nuevo la redundancia. Después de leer muchos tutoriales y foros no había manera de que funcionase. Si reiniciaba la máquina sin un disco del raid, éste no se montaba y no podía acceder a los datos. Además, el dispositivo /dev/md0 no era reconocido, por lo que era como si el raid no existiese!. Finalmente, encontré en un pequeño tutorial la solución a mis problemas.
• Es necesario indicarle al sistema operativo cómo acceder a ese dispositivo raid para que sea capaz de utilizarlo. Esto que puede parecer tan obvio no venía en ningún tutorial ni en ninguna ayuda de las que consulté.
shian:/# cd /etc/mdadm
shian:/etc/mdadm# cp mdadm.conf mdadm.conf.`date +%y%m%d`
shian:/etc/mdadm# echo "DEVICE partitions" > mdadm.conf
shian:/etc/mdadm# mdadm --detail --scan >> mdadm.conf
shian:/etc/mdadm#
shian:/etc/mdadm# cat mdadm.conf
DEVICE partitions
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=a48e6816:ea6e7f37:6cc50cdb:6fead399
devices=/dev/hdb1,/dev/hdc1
• Ahora ya podemos reiniciar la máquina y el raid arrancará y se montará automáticamente en el arranque.
• Podemos probar a parar el dispositivo y a levantarlo de nuevo:
shian:/etc/mdadm# umount /mnt/raid
shian:/etc/mdadm# mdadm --stop /dev/md0
shian:/etc/mdadm# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
unused devices:

shian:/etc/mdadm# mdadm --assemble /dev/md0 /dev/hdb1 /dev/hdc1
mdadm: /dev/md0 has been started with 2 drives.
shian:/etc/mdadm# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus0/target1/lun0/part1[0] ide/host0/bus1/target0/lun0/part1[1]
1048192 blocks [2/2] [UU]

unused devices:

Ahora sí, vamos a probar si realmente el podemos recuperar la información y el sistema funciona correctamente en caso de caída de un dispositivo. Además, veremos cómo reemplazar el disco defectuoso y recuperar de nuevo el raid 1 con los dos discos.
• Creamos un archivo aleatorio de 25MB en el raid montando previamente de nuevo el raid:
shian:/# mount /dev/md0 /mnt/raid
shian:/# dd if=/dev/urandom of=/mnt/raid/random1 count=51200
51200+0 records in
51200+0 records out
26214400 bytes transferred in 7.829523 seconds (3348148 bytes/sec)
• Calculamos su CRC y lo apuntamos. Posteriormente nos servirá para comprobar que todo es correcto:
shian:/# cksum /mnt/raid/random1
1652310020 26214400 /mnt/raid/random1
• Vamos a simular un fallo en uno de los dispositivos. Para ello apagamos el sistema, desconectamos uno de los discos duros (en este caso /dev/hdb) y arrancamos de nuevo.
• Una vez arrancado de nuevo el sistema, si examinamos con detalle los mensajes de arranque encontraremos algo como lo siguiente. Como se puede ver el sistema ha detectado un disco falla y al no haber un disco de repuesto (spare) levanta el raid en modo degradado con un sólo disco. Podremos seguir utilizando el raid con total normalidad pero si este disco también fallase, perderíamos irremediablemente todos los datos.
md: bind
md: ide/host0/bus1/target0/lun0/part1's event counter: 00000006
md0: former device hdb1 is unavailable, removing from array!
md: raid1 personality registered as nr 3
md0: max total readahead window set to 124k
md0: 1 data-disks, max readahead per data-disk: 124k
raid1: device ide/host0/bus1/target0/lun0/part1 operational as mirror 1
raid1: md0, not all disks are operational -- trying to recover array
raid1: raid set md0 active with 1 out of 2 mirrors
md: updating md0 RAID superblock on device
md: ide/host0/bus1/target0/lun0/part1 [events: 00000007]<6>(write) ide/host0/bus1/target0/lun0/part1's sb offset: 1048192
md: recovery thread got woken up ...
md0: no spare disk to reconstruct array! -- continuing in degraded mode
md: recovery thread finished ...
• En el archivo /proc/mdstat podemos ver el estado del raid. Ahora mismo se encuentra funcionando sólo con un dispositivo de dos posibles y nos indica que el que ha fallado es el primero de ellos:
shian:~# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus1/target0/lun0/part1[1]
1048192 blocks [2/1] [_U]

unused devices:
• No obstante el raid está montado y el filesystem es accesible:
shian:~# df -h /dev/md0
Filesystem Size Used Avail Use% Mounted on
/dev/md0 1008M 42M 916M 5% /mnt/raid
• Ahora marcamos el disco /dev/hdb1 como fallo para proceder a cambiarlo:
shian:~# mdadm --manage /dev/md0 --fail /dev/hdb1
mdadm: set /dev/hdb1 faulty in /dev/md0

Apagamos la máquina y cambiamos el disco duro defectuoso por uno nuevo. En el caso de VMware basta con crear un nuevo dispositivo de tipo disco duro. Además, este disco duro nuevo que añadimos va a ser de mayor tamaño que el anterior. Idealmente en un raid 1 los dos discos duros deben tener el mismo tamaño, pero linux nos proporciona la suficiente flexibilidad para que esto no sea así.
• En el arranque de la máquina vemos que el raid sigue arrancando pero en modo degradado. Lo que vamos a hacer es crear la tabla de particiones del nuevo disco duro exáctamente igual que la del disco duro que aún funciona y que forma parte del raid:
shian:~# sfdisk -d /dev/hdc | sfdisk /dev/hdb
Checking that no-one is using this disk right now ...
OK

Disk /dev/hdb: 4161 cylinders, 16 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
/dev/hdb: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

Device Boot Start End #sectors Id System
/dev/hdb1 63 2096639 2096577 fd Linux raid autodetect
/dev/hdb2 0 - 0 0 Empty
/dev/hdb3 0 - 0 0 Empty
/dev/hdb4 0 - 0 0 Empty
Warning: no primary partition is marked bootable (active)
This does not matter for LILO, but the DOS MBR will not boot this disk.
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)
• Como este nuevo disco duro es mayor que el anterior, podemos crear una partición /dev/hdb2 y formatearla para utilizarla sin problemas.
shian:~# fdisk /dev/hdb

The number of cylinders for this disk is set to 4161.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (2081-4161, default 2081):INTRO
Using default value 2081
Last cylinder or +size or +sizeM or +sizeK (2081-4161, default 4161):INTRO
Using default value 4161

Command (m for help): p

Disk /dev/hdb: 2147 MB, 2147483648 bytes
16 heads, 63 sectors/track, 4161 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 2080 1048288+ fd Linux raid autodetect
/dev/hdb2 2081 4161 1048824 83 Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

shian:~# mkfs.ext3 /dev/hdb2
mke2fs 1.37 (21-Mar-2005)
warning: 62 blocks unused.

Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131328 inodes, 262144 blocks
13110 blocks (5.00%) reserved for the super user
First data block=0
8 block groups
32768 blocks per group, 32768 fragments per group
16416 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

shian:~# mkdir /mnt/tmp

shian:~# mount /dev/hdb2 /mnt/tmp
• Ahora vamos a reconstruir el raid:
shian:~# mdadm --manage /dev/md0 --add /dev/hdb1
mdadm: hot added /dev/hdb1
• En este instante el raid 1 se está reconstruyendo. Toda la información del disco existente (/dev/hdc1) se está escribiendo en el nuevo disco (/dev/hdb1) para reconstruir el mirror y tener de nuevo la redundancia. Podemos comprobar el estado en el archivo /proc/mdstat:
shian:~# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus0/target1/lun0/part1[2] ide/host0/bus1/target0/lun0/part1[1]
1048192 blocks [2/1] [_U]
[=======>.............] recovery = 39.5% (415488/1048192) finish=0.1min speed=69248K/sec
unused devices:
• Finalmente, después de un tiempo tenemos el raid recuperado:
shian:~# cat /proc/mdstat
Personalities : [raid1]
read_ahead 1024 sectors
md0 : active raid1 ide/host0/bus0/target1/lun0/part1[0] ide/host0/bus1/target0/lun0/part1[1]
1048192 blocks [2/2] [UU]

unused devices:
• Si no nos fiamos de que todo esté correcto (yo tengo que verlo para creerlo), podemos hacer lo siguiente para comprobar que la recuperación se ha realizado satisfactoriamente. Lo que vamos a hacer es desmontar el raid, montar únicamente el nuevo dispositivo /dev/hdb1 y comprobar el CRC del archivo que generamos anteriormente para comprobar que la recuperación ha sido correcta.
shian:~# umount /mnt/raid
shian:~# mount /dev/hdb1 /mnt/raid
shian:~# cksum /mnt/raid/random1
1652310020 26214400 /mnt/raid/random1
• Y listo!. El raid se ha recuperado correctamente y toda nuestra información está a salvo. Es importante dejarlo todo como estaba antes de utilizarlo puesto que ahora mismo en /mnt/raid se encuentra montado de manera temporal sólo un dispositivo del raid y no éste completo. Si ahora hiciéramos algún cambio, creásemos archivos,... perderíamos todos esos datos en cuanto montásemos de nuevo el raid. Mejor lo dejamos todo como estaba:
shian:~# umount /mnt/raid/
shian:~# mount /mnt/raid/
shian:~# df -h /mnt/raid/
Filesystem Size Used Avail Use% Mounted on
/dev/md0 1008M 42M 916M 5% /mnt/raid
• Si ahora reiniciamos la máquina vemos que el raid arranca correctamente con los dos discos de nuevo:
md: ide/host0/bus0/target1/lun0/part1's event counter: 0000000c
md: ide/host0/bus1/target0/lun0/part1's event counter: 0000000c
md: raid1 personality registered as nr 3
md0: max total readahead window set to 124k
md0: 1 data-disks, max readahead per data-disk: 124k
raid1: device ide/host0/bus0/target1/lun0/part1 operational as mirror 0
raid1: device ide/host0/bus1/target0/lun0/part1 operational as mirror 1
raid1: raid set md0 active with 2 out of 2 mirrors
md: updating md0 RAID superblock on device
md: ide/host0/bus0/target1/lun0/part1 [events: 0000000d]<6>(write) ide/host0/bus0/target1/lun0/part1's sb offset: 1048192
md: ide/host0/bus1/target0/lun0/part1 [events: 0000000d]<6>(write) ide/host0/bus1/target0/lun0/part1's sb offset: 1048192

lunes, 4 de junio de 2012

DGMGRL

[oracle@11gPrimary dbs]$ dgmgrl

DGMGRL for Linux: Version 11.1.0.6.0 - Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
1.) Creating Data Guard Broker configuration for the primary database. Next, I’ll use the CREATE CONFIGURATION command to initialize a Data Guard Broker configuration named MAA_orcl, and confirm its creation with the SHOW CONFIGURATION command:

DGMGRL> CREATE CONFIGURATION 'MAA_orcl' AS
> PRIMARY DATABASE IS primary_db
> CONNECT IDENTIFIER IS orcl;

Configuration "MAA_orcl" created with primary database "primary_db"

DGMGRL> show configuration

Configuration
Name: MAA_orcl
Enabled: NO
Protection Mode: MaxPerformance
Databases:
primary_db - Primary database

Fast-Start Failover: DISABLED

Current status for "MAA_orcl":
DISABLED
2.) Adding a standby database to the Data Guard Broker configuration. To add a standby database to the current configuration, I’ll use the ADD DATABASE command. Note that I could add up to eight additional standby databases to the configuration using DGMGRL:

DGMGRL> ADD DATABASE 'stdby_db' AS
> CONNECT IDENTIFIER IS stdby;

Database "stdby_db" added
I’ll then use DGMGRL’s SHOW CONFIGURATION and SHOW DATABASE commands to confirm the configuration before I enable it:

DGMGRL> show configuration verbose;

Configuration
Name: MAA_orcl
Enabled: NO
Protection Mode: MaxPerformance
Databases:
primary_db - Primary database
stdby_db - Physical standby database

Fast-Start Failover: DISABLED

Current status for "MAA_orcl":
DISABLED

DGMGRL> show database stdby_db

Database
Name: stdby_db
Role: PHYSICAL STANDBY
Enabled: NO
Intended State: OFFLINE
Instance(s):
orcl

Current status for "stdby_db":
DISABLED
4.) Enabling the Data Guard Broker configuration. Lastly, I’ll issue the ENABLE CONFIGURATION command to activate the configuration and then confirm the successful activation of the primary and standby databases via the SHOW DATABASE command:

DGMGRL> enable configuration;

Enabled.

DGMGRL> show database primary_db;

Database
Name: primary_db
Role: PRIMARY
Enabled: YES
Intended State: TRANSPORT-ON
Instance(s):
orcl

Current status for "primary_db":
SUCCESS

DGMGRL> show database stdby_db;

Database
Name: stdby_db
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: APPLY-ON
Instance(s):
orcl

Current status for "stdby_db":
SUCCESS
One of the beautiful things about Data Guard Broker is that it automatically creates and issues all necessary ALTER SYSTEM commands to enable the required Data Guard configurations on each database in the configuration. I’ve showed the results of enabling the Data Guard Broker configuration from the primary and standby databases’ alert logs in Listing 2.3.

Performing a Switchover between Primary and Standby Databases
If you’ve ever performed a switchover operation between a primary and a standby database without Data Guard Broker, I’m sure you’ll agree that it’s a tedious, manually-intensive process that involves several distinct steps which must be performed carefully and in precise order to insure a successful role transition. Here’s a brief summary of the steps required:

1.) Check the status of the primary database. Column V$DATABASE.SWITCHOVER_STATUS on the primary database must reflect the proper state of the primary database. Either a value of TO_STANDBY or SESSIONS_ACTIVE indicates that a switchover is possible; otherwise, redo transport services haven’t been configured properly.

2.) Start the switchover process on the primary database. Next, the standby database has to be prepared to handle switchover by issuing the appropriate switchover command from SQL*Plus. During this process, the primary database is prepared to assume the standby role, and its control file is backed up to make sure it could be reconstructed in case a failure occurs.

-- If no sessions are active ...
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
-- ... but if sessions are active:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
3.) Shut down, then mount, the original primary database. Once the role transition is complete on the original primary (and soon to become the standby) database, it’s time to shut it down and mount it.

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4.) Check that the target database’s status is ready for switchover. The target standby database must be ready to accept its new primary role. Column V$DATABASE.SWITCHOVER_STATUS on this database must contain a value of either TO­_PRIMARY or SESSIONS_ACTIVE to indicate that a switchover is possible; otherwise, redo transport services haven’t been configured properly.

5.) Switch the target database to its new primary role. Depending on the result from the previous step, the appropriate command needs to be issued on the (soon to be) primary database from SQL*Plus:

-- If no sessions are active ...
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
-- ... but if sessions are active:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
6.) Open the new primary database. It’s time to activate the new primary database from SQL*Plus:

SQL> ALTER DATABASE OPEN;
7.) Make the original primary database into the standby database. To complete the role transition, the original primary database must be enabled to accept its new standby role.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE
DISCONNECT FROM SESSION;
In this relatively simple example of a role transition, notice that I haven’t discussed what to do if there’s a failure at any point during this process. Frankly, I’d much rather have a lot more insurance should the process fail at any point … and that’s where Data Guard Broker comes in.

Example: Using Data Guard Broker to Perform a Switchover
Data Guard Broker makes extremely short work of role transitions like a switchover. Once I’ve connected to DGMGRL as the SYS user on the primary database server, all I need to do is issue one simple command, SWITCHOVER TO :

[oracle@11gPrimary dbs]$ dgmgrl
DGMGRL for Linux: Version 11.1.0.6.0 - Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.

DGMGRL> SWITCHOVER TO stdby_db;

Performing switchover NOW, please wait...
New primary database "stdby_db" is opening...
Operation requires shutdown of instance "orcl" on database "primary_db"
Shutting down instance "orcl"...
ORA-1109: database not open
Database dismounted.
ORACLE instance shut down.

Operation requires startup of instance "orcl" on database "stdby_db"
Starting instance "orcl"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "stdby_db"
I’ve showed the results of this switchover operation from the perspective of the primary and standby databases’ alert logs in Listing 2.4.

Example: Using Data Guard Broker to Perform a Switchback
Data Guard Broker also makes it simple to revert the original primary and standby database back to their original roles. Once again, I’ll connect to DGMGRL as the SYS user on the original primary database server and just issue the SWITCHOVER TO command to revert to the original Data Guard configuration:

[oracle@11gPrimary dbs]$ dgmgrl
DGMGRL for Linux: Version 11.1.0.6.0 - Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.

DGMGRL> SWITCHOVER TO primary_db;

Performing switchover NOW, please wait...
New primary database "stdby_db" is opening...
Operation requires shutdown of instance "orcl" on database "stdby_db"
Shutting down instance "orcl"...
ORA-1109: database not open
Database dismounted.
ORACLE instance shut down.

Operation requires startup of instance "orcl" on database "primary_db"
Starting instance "orcl"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "primary_db"

Oracle Data Guard Broker configuration example

Oracle Data Guard Broker configuration example

The official Oracle Data Guard Broker docs docs are, of course, the best source for accurate and complete information about how to set up Oracle Data Guard with Oracle Data Guard Broker. They are, however, not always the most useful source, since they generally sacrifice readability for completeness.

This doc should be useful to people setting up a Data Guard Broker with DGMGRL. Managing Data Guard through the Broker is much simpler than managing it manually. DGMGRL is allegedly not as simple as managing Data Guard through Orcle Enterprise Manager Grid Control; however, Grid Control is an extra-cost option that not all of us have.

This procedure makes a number of assumptions that you have made life easy on yourself: you’re using Oracle 11g; you’ve configured a db_recovery_file_dest; your primary and standby databases will be on separate machines with identical directory structures; etc.

Special thanks go out to Chris Ruel of Perpetual Technologies in Indianapolis for his “Oracle 11g Data Guard” presentation, which provided the starting material for this. I have pared away some parts and fleshed out others, but I never would have figured the core of the material out without his help.

I am a beginner at this, and this procedure almost certainly contains steps that are not optimal, and perhaps completely unnecessary. All I can say for certain is that this is one path that got me going successfully.

To begin, assume that you have a primary database server, prodserv.myco.com, hosting a production database, PROD. You have a standby server, stbyserv.myco.com, and intend to put a standby Oracle database on it, STBY. Oracle 11g + is installed on both machines.
1.
On stbyserv, create $ORACLE_HOME/dbs/initSTBY.ora with just one parameter:


db_name = PROD

(On Windows, all references to $ORACLE_HOME/dbs should be understood as %ORACLE_HOME%\database.)

2.
On prodserv:

SQL> CREATE PFILE FROM SPFILE;
Add these parameters to $ORACLE_HOME/dbs/initPROD.ora:

*.db_unique_name='PROD'
*.dg_broker_start=TRUE
*.fal_client='PROD'
*.fal_server='STBY'
*.log_archive_config='dg_config=(STBY,PROD)'
*.log_archive_dest_10='location=USE_DB_RECOVERY_FILE_DEST, valid_for=(ALL_LOGFILES, ALL_ROLES)'
*.log_archive_dest_2='service="STBY", db_unique_name="STBY", valid_for=(online_logfile,primary_role)'
*.standby_file_management='AUTO'
3.
These new parameters must be incorporated into PROD‘s SPFILE, and the instance must be restarted from the SPFILE:

SQL> shutdown immediate;
SQL> !rm $ORACLE_HOME/dbs/spfilePROD.ora
SQL> startup;
SQL> create spfile from pfile;
SQL> shutdown immediate;
SQL> startup;
4.
Edit $ORACLE_HOME/network/admin files.

On prodserv, add to listener.ora:

(SID_DESC =
(GLOBAL_DBNAME = stby_DGMGRL)
(ORACLE_HOME = {oracle home directory here})
(SID_NAME = STBY)
(SERVICE_NAME = STBY)
)
On stbyserv, add to listener.ora:

(SID_DESC =
(GLOBAL_DBNAME = stby.myco.com)
(ORACLE_HOME = {oracle home directory here})
(SID_NAME = STBY)
)
(SID_DESC =
(GLOBAL_DBNAME = prod_DGMGRL)
(ORACLE_HOME = {oracle home directory here})
(SID_NAME = PROD)
(SERVICE_NAME = PROD)
)
(Note that each machine contains a _DGMGRL entry for the database hosted on the other machine)

tnsnames.ora should have these entries on both machines:

PROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prodserv.myco.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = prod.myco.com)
)
)
STBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = stbyserv.myco.com)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = stby.myco.com)
)
)
Run lsnrctl reload on both machines. Verify that you can tnsping prod and tnsping stby from both machines.

5.
Under *nix, copy $ORACLE_HOME/dbs/orapwPROD from PROD to $ORACLE_HOME/dbs/orapwSTBY on stbyserv.

Under Windows, on stbyserv:

oradim -new -sid stby -intpwd mypassword
6.
SQL> connect sys@stby as sysdba
SQL> startup nomount;
7.
PROD should have standby logfiles - one more than its number of online redo logfiles, I believe.

SQL> connect sys@prod as sysdba
SQL> select type, count(*) from v$logfile group by type;
SQL> alter database add standby logfile;
SQL> alter database add standby logfile;
SQL> alter database add standby logfile;
SQL> alter database add standby logfile;
8.
RMAN> connect target sys@prod
RMAN> backup database plus archivelog;
9.
Copy the {flash recovery area}/PROD/BACKUPSET/{today} directory from prodserv to stbyserv. Copy it to exactly the same place in the directory structure. Do not change prod to stby in the path.

On stbyserv:

mkdir {oradata directory}/PROD
Again, do not rename PROD to STBY in the directory structure.

10.
RMAN> connect target sys@prod auxiliary sys@stby
RMAN> run {
allocate channel prmy1 type disk;
allocate auxiliary channel stby1 type disk;
duplicate target database
For standby
from active database spfile
set db_unique_name = 'STBY'
set fal_client = 'STBY'
set fal_server = 'PROD'
set standby_file_management = 'AUTO'
set log_archive_config = 'dg_config=(PROD,STBY)'
set log_archive_dest_1 = 'service=PROD ASYNC valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=PROD'
dorecover nofilenamecheck;
}
11.
SQL> connect sys@stby as sysdba;
SQL> recover managed standby database disconnect;
SQL> recover managed standby database cancel;
SQL> alter database open read only;
SQL> recover managed standby database using current logfile disconnect;
12.
DGMGRL> connect sys@prod
DGMGRL> create configuration 'standby_config' as
> primary database is 'PROD'
> connect identifier is 'PROD';

DGMGRL> show configuration;
DGMGRL> add database 'STBY' as
> connect identifier is stby;
DGMGRL> enable configuration;
DGMGRL> enable database stby;
13.
Finally ready!

DGMGRL> connect sys@prod
DGMGRL> switchover to 'STBY';

CONFIGURACION DATAGUARD BROKER

Configurando Dataguard Broker


July 28, 20091 Comment

Oracle nos ofrece esta herramienta para poder hacer pasaje automatico en caso de tener un switch o un fail, y su uso una vez configurado es tan sencillo como conectarse a la consola del administrador con el comando dgmgrl o desde el Entrerprise Manager con solo haciendo un click.

Yo en este caso voy a disponibilizar el modo de configuración desde la linea de comandos ya que me parece super práctico y nos sirve para conocer un poco más el modo en que trabaja.

Es importante saber que tanto desde la consola del GRID CONTROL o desde comandos hay que hacer una configuración previa que incluye:
■Configuración de Listener en primaria y secundaria.
■Configuración de Parametros de la base.
■Creación de los archivos de configuración del broker. (Debemos ser sysdba)
■En el caso de trabajar con una base que esta en RAC, hay que hacer la configuración con srvctl. (En este caso yo voy a presentarlo en una instancia en RAC y serán informados de ello para que sepan que el modo es el mismo para la single instance, menos este paso.)

CONFIGURANDO LISTENERS

Comenzaremos configurando los listeners, tanto en nuestra base primaria como en nuestra standby.
Es muy importante este paso ya que si el broker no ve el servicio no podrá hacer ninguna operación de switcheo.
# listener.ora.saturno01 Network Configuration File: /u01/app/oracle/product/10.2.0/db_mbpro/network/admin/listener.ora.saturno01
# Generated by Oracle configuration tools.

MBPRO_SATURNO01 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = saturno01-vip.danahomelinux.com)(PORT = 1526)
(IP = FIRST))
(ADDRESS = (PROTOCOL = TCP)(HOST = saturno01.danahomelinux.com)(PORT = 1526)
(IP = FIRST))
)
)

SID_LIST_MBPRO_SATURNO01 =
(SID_LIST =
(SID_DESC =
(SID_NAME = PLSExtProc)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_mbpro)
(PROGRAM = extproc)
)
(SID_DESC =
(GLOBAL_DBNAME = MBPRO_DGMGRL.danahomelinux.com)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_mbpro)
(SID_NAME = MBPRO1)
)
)
Una vez realizada la tarea, procedemos a relodear el listener, y luego con un status service vemos si los cambios fueron impactados.
lsnrctl status MBPRO_SATURNO01
lsnrctl service MBPRO_SATURNO01
Ahora procedemos a realizar la misma tarea en nuestra base secundaria.

CONFIGURANDO LA BASE

Ahora que configuramos los listeners (y los parametros con el comando srvctl en el caso de estar trabajando con una base en RAC) procedemos a crear los archivos fisicos de la configuración del broker y activar el feature en la base misma poniendo el parametro dg_broker_start=start, donde si tenemos una terminal abierta podremos ver en el alert.log que se activa un proceso nuevo que en DMON.
Primero creamos en un path en el SO que sea seguro y luego en la base pasamos esos mismos párametros.
SQL> sho parameter broker

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1 string
dg_broker_config_file2 string
dg_broker_start boolean FALSE

SQL> alter system set dg_broker_config_file1='/u06/dgbroker/dr1_MBPRO.dat'
scope=both sid='*';

System altered.

SQL> alter system set dg_broker_config_file2='/u07/dgbroker/dr2_MBPRO.dat'
scope=both sid='*';

System altered.

SQL> sho parameter broker

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1 string /u06/dgbroker/dr1_MBPRO.dat
dg_broker_config_file2 string /u07/dgbroker/dr2_MBPRO.dat
dg_broker_start boolean FALSE

SQL> alter system set dg_broker_start=true scope=both sid='*';
System altered.
Ingresamos a la consola del DGBROKER y luego nos conectamos con el usuario administrador.
Desde aqui vamos a decirle a broker como se llamará la primaria, la secundaria, y que roles tendra cada una. Esto nos servirá en el futuro para switchear, pasar por fail, o mantenimiento mismo.
[oracle@saturno bin]$ dgmgrl
DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/PASSXXXX
Connected.
Creamos la configuración
DGMGRL> CREATE CONFIGURATION 'DR_MBPRO' AS
> PRIMARY DATABASE IS 'MBPRO'
> CONNECT IDENTIFIER IS MBPRO;
Configuration "DR_MBPRO" created with primary database "MBPRO"
DGMGRL>
DGMGRL> ADD DATABASE 'MBPRODG' AS
> CONNECT IDENTIFIER IS MBPRODG
> MAINTAINED AS PHYSICAL;
Database "MBPRODG" added
DGMGRL>

Ahora podemos ver configuracion que armamos y nos va a decir que esta en modo deshabilitado.
DGMGRL> show configuration;

Configuration
Name: DR_MBPRO
Enabled: NO
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
MBPRO - Primary database
MBPRODG - Physical standby database

Current status for "DR_MBPRO":
DISABLED
Habilitamos esa configuracion para que pueda ser leida por la instancia primaria y secundaria.
DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration;

Configuration
Name: DR_MBPRO
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
MBPRO - Primary database
MBPRODG - Physical standby database

Current status for "DR_MBPRO":
SUCCESS
Vemos la configuracion de la primaria.
DGMGRL> show database verbose "MBPRO";

Database
Name: MBPRO
Role: PRIMARY
Enabled: YES
Intended State: ONLINE
Instance(s):
MBPRO

Properties:
InitialConnectIdentifier = 'MBPRO'
ObserverConnectIdentifier = ''
LogXptMode = 'ARCH'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'MANUAL'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '2'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '+PRUEBAS_DG1/MBPRO, +PRUEBAS_DG1/MBPRO'
LogFileNameConvert = '+PRUEBAS_DG1/MBPRODG, +PRUEBAS_DG1/MBPRO'
FastStartFailoverTarget = '+PRUEBAS_DG1/MBPRODG, +PRUEBAS_DG1/MBPRO'
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'saturno.danahomelinux.com'
SidName = 'MBPRO'
LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=saturno.danahomelinux.com)(PORT=1529))'
StandbyArchiveLocation = '?/dbs/arch'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
LatestLog = '(monitor)'
TopWaitEvents = '(monitor)'

Current status for "MBPRO":
SUCCESS
Ahora la de la secundaria.
DGMGRL> show database verbose "MBPRODG";

Database
Name: MBPRODG
Role: PHYSICAL STANDBY
Enabled: YES
Intended State: ONLINE
Instance(s):
MBPRODG

Properties:
InitialConnectIdentifier = 'MBPROdg'
ObserverConnectIdentifier = ''
LogXptMode = 'ARCH'
Dependency = ''
DelayMins = '0'
Binding = 'OPTIONAL'
MaxFailure = '0'
MaxConnections = '1'
ReopenSecs = '300'
NetTimeout = '180'
LogShipping = 'ON'
PreferredApplyInstance = ''
ApplyInstanceTimeout = '0'
ApplyParallel = 'AUTO'
StandbyFileManagement = 'AUTO'
ArchiveLagTarget = '0'
LogArchiveMaxProcesses = '2'
LogArchiveMinSucceedDest = '1'
DbFileNameConvert = '+PRUEBAS_DG1/MBPRO, +PRUEBAS_DG1/MBPRODG'
LogFileNameConvert = '+PRUEBAS_DG1/MBPRO, +PRUEBAS_DG1/MBPRODG'
FastStartFailoverTarget = ''
StatusReport = '(monitor)'
InconsistentProperties = '(monitor)'
InconsistentLogXptProps = '(monitor)'
SendQEntries = '(monitor)'
LogXptStatus = '(monitor)'
RecvQEntries = '(monitor)'
HostName = 'saturnoco.danahomelinux.com'
SidName = 'MBPRODG'
LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=saturnoco.danahomelinux.com)(PORT=1529))'
StandbyArchiveLocation = 'dgsby_MBPRODG'
AlternateLocation = ''
LogArchiveTrace = '0'
LogArchiveFormat = '%t_%s_%r.dbf'
LatestLog = '(monitor)'
TopWaitEvents = '(monitor)'

Current status for "MBPRODG":
SUCCESS

DGMGRL>
Ya estamos listos para hacer nuestro switch over.

Ahora que tenemos configurados los listener, servicios de RAC y parametros de la base, podriamos realizar el primer pasaje de base, un cambio de roles.
Si somos los sufientemente curiosos, para este primer paso, podemos abrir los alert y podemos ir mirando que es lo que trancurre y no encontraremos con que:
■El broker hace los mismos pasos que nosotro hariámos a mano.
■El broker pone los párametros que tiene en el listener y los coloca, asi que cualquier modificiación que hicieramos sobre estos siempre se van a impactar en la base.
■Podemos hacer una consulta en la v$archive_dest antes de arracar, para verificar que hay conectividad y no tenemos problemas de red.
■En el caso que la base no tuviese la suficiente memoria por algún proceso enorme o si se encontrara con problemas, el broker comienza el proceso, y si es preciso lo aborta dejando la base intacta al momento de arrancar, sobre su rol antes de comenzar el pasaje. Además de ello no arroja los errores con el log de por qué la base no pudo pasar.
■En el caso de que en un pasaje perdemos el sitio primario, y previamente hubiesemos arrancado el switch, no podrá retornar, pero como buenos DBA’s al mirar el log sabriamos como seguir el switch a mano, ya que en el alert muestra los comandos ejecutados, y con nuestro procedimiento de switch over manual, podriámos verificar que paso faltó y continuar. La experiencia sobre el caso, me dice que esto es cierto y no una mera suposición.
[oracle@saturno01 dbs]$ dgmgrl
DGMGRL for Linux: Version 10.2.0.4.0 - 64bit Production

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

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/xxxxxxx
Connected.
DGMGRL> switchover to "MBPRODG";
Performing switchover NOW, please wait...
Operation requires shutdown of instance "MBPRO" on database "MBPROD"
Shutting down instance "MBPRO"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires shutdown of instance "MBPRODG" on database "MBPRODG"
Shutting down instance "MBPRODG1"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "MBPRO" on database "MBPRO"
Starting instance "MBPRO"...
ORACLE instance started.
Database mounted.
Operation requires startup of instance "MBPRODG" on database "MBPRODG"
Starting instance "MBPRODG1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "MBPRODG"

DGMGRL>