Describiremos los pasos reales en la migración a Oracle 11g GridInfraestructure a partir de una instalación Oracle RAC 10g, a partir de la idea de migración del post: http://www.soportedba.com/2011/12/oracle-rac-migracion-rapida-10g-11g.html
Estos pasos también servirían por ejemplo, si ocurre una catástrofe en el RAC antiguo y se pierden todos los nodos y backups (quedando sólo el acceso al almacenamiento).
Pasos básicos para el upgrade de la bbdd: http://onlineappsdba.com/index.php/2009/01/22/upgrade-oracle-database-10g-to-11g-r1-111x/
Antes
de la migración se debe “registrar” la bbdd en el RAC, para ello
simulamos la creación de una bbdd en otro grupo de discos FRA por
ejemplo, con el mismo nombre , para posteriormente cambiar directamente el spfile y los recursos asociados, aunque se podría hacer de otra forma, registrando bien los recursos ...
Se hace el switch del init de la bbdd "initdbmaq1.ora" por el antigo pfile
(cambiando varios parámetros como cluster_database=no,
compatible=11.1.0, eliminar user_dump_dest, backgroup_dump..., etc)
En el proceso de migración, el “catupgrd.sql” se obtiene el error:
TO_NUMBER(value$) != (SELECT tz_version from registry$database))
*
ERROR at line 6:
ORA-00942: table or view does not exist
Que
se evitaría habiendo lanzado los pasos previos (motor de la 10g
ejecutando el utlu112i.sql) pero como no lo hicimos, lo que se hace es
eliminar la comprobación del TZ_VERSION del script que llama el
catupgrd.sql que se llama “catupstr.sql”, parece que el proceso de
migración avanza correctamente, aunque está claro que podrá haber
corrupción en datos almacenados con Timezone o similar.
Ejecución del script upgrade principal correcta:
@?/rdbms/admin/catupgrd.sql
Tras la ejecución de los últimos scripts:
@?/rdbms/admin/utlu112s.sql
@?/rdbms/admin/catuppst.sql
@?/rdbms/admin/utlrp.sql
Todo correcto y todo compilado.
Ahora cambiamos el init para que se utilice el +DATA
create spfile=’+DATA’ from pfile;
ponemos en los initdbmaqX.ora :
SPFILE=’+DATA/DBMAQ/initdbmaq.ora’
Todo arranca y funciona correctamente.
Para deregistrar el spfile y que tenga en cuenta el grupo DATA, (en otro caso, en los arranque se sustituye automáticamente el init* por los de la preinstalación previa apuntando al FRA)
srvctl modify database -d dbmaq -p ' ' -a "DATA,FRA"
(ver http://oraganism.wordpress.com/2010/01/02/srvctl-p-option/)
Arracamos el dbconsole:
emctl start dbconsole
Aparece un error que evita podamos acceder, recreamos la key:
emctl config emkey -repos -force
Todo correcto, el acceso a los datos correcto, el acceso al EM Database Control correcto.
domingo, 11 de diciembre de 2011
miércoles, 7 de diciembre de 2011
ACFS (error “ADVM/ACFS is not supported on ...")
Mensaje de error tras instalación grid (en ejecución de root.sh)
"ADVM/ACFS is not supported on centos-release-5-6.el5.centos.1"
Para resolverlo, se cambian los ficheros "/etc/issue", "redhar-release", ....
http://ivan.kartik.sk/oracle/install_ora11gR2_elinux.html
http://brianbontrager.blogspot.com/2009/09/learning-asm-breakin-rules-or-running.html
Con esta última guia se consigue instalar ACFS para Centos, teniendo presente el tipo de instalación x86 o x86_64:
mkdir /lib/modules/2.6.18-128.el5/extra/usm
cp /u01/app/oragrid/product/11.2.0/grid/install/usm/EL5/i386/2.6.18-8/2.6.18-8.el5-i686/bin/*ko /lib/modules/2.6.18-128.el5/extra/usm
chmod 744 /lib/modules/2.6.18-128.el5/extra/usm
cd /u01/app/oragrid/product/11.2.0/grid/bin
./acfsdriverstate -orahome /u01/app/oragrid/product/11.2.0/grid version
"ACFS-9205: OS/ADVM,ACFS installed version = 2.6.18-8.el5(i386)/090715.1"
depmod
"ADVM/ACFS is not supported on centos-release-5-6.el5.centos.1"
Para resolverlo, se cambian los ficheros "/etc/issue", "redhar-release", ....
http://ivan.kartik.sk/oracle/install_ora11gR2_elinux.html
http://brianbontrager.blogspot.com/2009/09/learning-asm-breakin-rules-or-running.html
Con esta última guia se consigue instalar ACFS para Centos, teniendo presente el tipo de instalación x86 o x86_64:
mkdir /lib/modules/2.6.18-128.el5/extra/usm
cp /u01/app/oragrid/product/11.2.0/grid/install/usm/EL5/i386/2.6.18-8/2.6.18-8.el5-i686/bin/*ko /lib/modules/2.6.18-128.el5/extra/usm
chmod 744 /lib/modules/2.6.18-128.el5/extra/usm
cd /u01/app/oragrid/product/11.2.0/grid/bin
./acfsdriverstate -orahome /u01/app/oragrid/product/11.2.0/grid version
"ACFS-9205: OS/ADVM,ACFS installed version = 2.6.18-8.el5(i386)/090715.1"
depmod
Oracle RAC (migración rápida 10g a 11g)
Una forma de realizar las migraciones entre Oracle RAC 10g hacia Oracle Grid 11g rápidamente, sería:
1) Se van quitando nodos de un RAC(10g) antiguo y se reinstalan sobre la nueva arquitectura GRID (11g), el sistema debe estar dimensionado de forma que pueda funcionar correctamente con la mitad de nodos.
2) Una vez todo configurado, se apaga el RAC antiguo(antes habrá que ejecutar los scripts de comprobaciones y pre-upgrade indicados por Oracle) y se ponen visibles los discos para el GRID nuevo, se montan los Disk Groups y se arrancan las bbdd en el nuevo (startup migrate, ... y se deberán lanzar los scripts/procedimientos de migración correspondientes), con lo que se consigue un tiempo de corte mínimo.
3) El resto de nodos del RAC antiguo se van reinstalando e introduciendo en el GRID nuevo.
Sólo en el punto 2 sería necesaria la parada (tiempo de upgrade de las bbdd), pero el tiempo sería mínimo si estuviera todo preparado y probado.
Con esta técnica no existe movimiento real de datos, aunque está claro que se deberán tomar todas las medidas de seguridad oportunas (backups previos, backup de configuraciones, etc).
1) Se van quitando nodos de un RAC(10g) antiguo y se reinstalan sobre la nueva arquitectura GRID (11g), el sistema debe estar dimensionado de forma que pueda funcionar correctamente con la mitad de nodos.
2) Una vez todo configurado, se apaga el RAC antiguo(antes habrá que ejecutar los scripts de comprobaciones y pre-upgrade indicados por Oracle) y se ponen visibles los discos para el GRID nuevo, se montan los Disk Groups y se arrancan las bbdd en el nuevo (startup migrate, ... y se deberán lanzar los scripts/procedimientos de migración correspondientes), con lo que se consigue un tiempo de corte mínimo.
3) El resto de nodos del RAC antiguo se van reinstalando e introduciendo en el GRID nuevo.
Sólo en el punto 2 sería necesaria la parada (tiempo de upgrade de las bbdd), pero el tiempo sería mínimo si estuviera todo preparado y probado.
Con esta técnica no existe movimiento real de datos, aunque está claro que se deberán tomar todas las medidas de seguridad oportunas (backups previos, backup de configuraciones, etc).
ASM (comandos amdu y kfed)
Extraído de: http://asmsupportguy.blogspot.com/2011/09/amdu-asm-metadata-dump-utility.html
amdu - ASM Metadata Dump Utility (>=11g)
Comando muy interesante para el análisis de la metadata de discos ASM e incluso extraer los ficheros (datafiles, controlfiles, ...) contenidos en ellos, sin requerir que el Disk Group esté montado o la instancia ASM operativa.
- Extracción del fichero de control del Disk Group DATA :
amdu -diskstring="ORCL:*" -extract DATA.276 -output control.276 -noreport -nodir
- Extracción de un datafile:
amdu -diskstring="ORCL:*" -extract DATA.267 -output NSA_TN_DATA.267 -noreport -nodir
Para saber los nombres de los datafiles, se pueden utilizar comandos ASM (asmcmd) previos, que requieren del montaje de los Disk Groups y disponibilidad de la instancia ASM o se puede utilizar comandos "kfed":
...
for (( i=0; i<256; i++ ))
do
kfed read /dev/oracleasm/disks/DISK2 aun=8 blkn=$i | grep -1 NSA
done
...
Extraído de: http://asmsupportguy.blogspot.com/2010/04/kfed-asm-metadata-editor.html
kfed - ASM Metadata Editor (>=10g)
Comando muy interesante para leer y modificar la metadata de discos ASM, no requiere que el Disk Group esté montado o la instancia ASM operativa.
cd $ORACLE_HOME/rdbms/lib
make -f ins* ikfed
- Comprobación de que la cabecera del disco asm está bien:
kfed read /dev/oracleasm/disks/DISK4
Si se observa kfbh.type=KFBTYP_INVALID , puede indicar que la cabecera del disco asm está dañada.
amdu - ASM Metadata Dump Utility (>=11g)
Comando muy interesante para el análisis de la metadata de discos ASM e incluso extraer los ficheros (datafiles, controlfiles, ...) contenidos en ellos, sin requerir que el Disk Group esté montado o la instancia ASM operativa.
- Extracción del fichero de control del Disk Group DATA :
amdu -diskstring="ORCL:*" -extract DATA.276 -output control.276 -noreport -nodir
- Extracción de un datafile:
amdu -diskstring="ORCL:*" -extract DATA.267 -output NSA_TN_DATA.267 -noreport -nodir
Para saber los nombres de los datafiles, se pueden utilizar comandos ASM (asmcmd) previos, que requieren del montaje de los Disk Groups y disponibilidad de la instancia ASM o se puede utilizar comandos "kfed":
...
for (( i=0; i<256; i++ ))
do
kfed read /dev/oracleasm/disks/DISK2 aun=8 blkn=$i | grep -1 NSA
done
...
Extraído de: http://asmsupportguy.blogspot.com/2010/04/kfed-asm-metadata-editor.html
kfed - ASM Metadata Editor (>=10g)
Comando muy interesante para leer y modificar la metadata de discos ASM, no requiere que el Disk Group esté montado o la instancia ASM operativa.
cd $ORACLE_HOME/rdbms/lib
make -f ins* ikfed
- Comprobación de que la cabecera del disco asm está bien:
kfed read /dev/oracleasm/disks/DISK4
Si se observa kfbh.type=KFBTYP_INVALID , puede indicar que la cabecera del disco asm está dañada.
RedHat / Centos (comando yum)
-- Para la actualización de nuestros linux RedHat / Centos
cd /etc/yum.repos.d
mv ULN-Base.repo ULN-Base.repo.disabled
wget http://public-yum.oracle.com/public-yum-el4.repo
(modificamos el .repo para habilitar la release que nos convenga)
yum clean all
yum update glibc\*
yum update yum\* rpm\* python\*
yum clean all
yum update
reboot
Otras opciones, por ejemplo, la instalación de oracle-validated (para cambios automáticos de parámetros y demás para ejecución de software Oracle)
yum --enablerepo=el4_u7_base install oracle-validated
Si tenemos algún problema con un kernel parcheado, podemos volver a los anteriores editanto el /etc/grub.conf y eligiendo como kernel default de arranque el antiguo 2.6.9.42 u otro.
cd /etc/yum.repos.d
mv ULN-Base.repo ULN-Base.repo.disabled
wget http://public-yum.oracle.com/public-yum-el4.repo
(modificamos el .repo para habilitar la release que nos convenga)
yum clean all
yum update glibc\*
yum update yum\* rpm\* python\*
yum clean all
yum update
reboot
Otras opciones, por ejemplo, la instalación de oracle-validated (para cambios automáticos de parámetros y demás para ejecución de software Oracle)
yum --enablerepo=el4_u7_base install oracle-validated
Si tenemos algún problema con un kernel parcheado, podemos volver a los anteriores editanto el /etc/grub.conf y eligiendo como kernel default de arranque el antiguo 2.6.9.42 u otro.
LVM (Ampliación de espacio en volumen)
-- Ampliación online de espacio en nodo CentOS Virtualizado (vmware) en volumen local "/"
Se amplia el disco virtualizado en 10G más (a través de la interfaz de gestión vmware), y después se aplican comandos típicos de LVM:
vgdisplay --verbose
fdisk /dev/sda (n, 3, intro, intro, t, 8e (partición Linux VM))
partprobe /dev/sda (para crear el dispositivo /dev/sda3)
pvcreate /dev/sda3
vgextend VolGroup00 /dev/sda3
lvextend -L +10G /dev/VolGroup00/LogVol00
ext2online /dev/VolGroup00/LogVol00
Se amplia el disco virtualizado en 10G más (a través de la interfaz de gestión vmware), y después se aplican comandos típicos de LVM:
vgdisplay --verbose
fdisk /dev/sda (n, 3, intro, intro, t, 8e (partición Linux VM))
partprobe /dev/sda (para crear el dispositivo /dev/sda3)
pvcreate /dev/sda3
vgextend VolGroup00 /dev/sda3
lvextend -L +10G /dev/VolGroup00/LogVol00
ext2online /dev/VolGroup00/LogVol00
OEM Grid Control (Despliegue manual de agente)
-- En una instalación virtualizada(vmware ESX) de Oracle RAC 10g (10.2.0.4, almacenamiento iscsi), tenemos un nodo que no tiene el agente oracle instalado:
Instalación de Agente en linux2 (no estaba instalado):
Nos llevamos el directorio agent10g de $ORACLE_HOME/.. hasta linux2 y cambiamos .../config/emd.properties, cambiando la línea linux1 por linux2.
Con esto, al cabo de un tiempo, el Grid detecta el nodo correctamente y se empieza a monitorizar correctamete.
Instalación de Agente en linux2 (no estaba instalado):
Nos llevamos el directorio agent10g de $ORACLE_HOME/.. hasta linux2 y cambiamos .../config/emd.properties, cambiando la línea linux1 por linux2.
Con esto, al cabo de un tiempo, el Grid detecta el nodo correctamente y se empieza a monitorizar correctamete.
Oracle RAC 10g (Error: "no route to host")
-- En una instalación virtualizada(vmware ESX) de Oracle RAC 10g (10.2.0.4, almacenamiento iscsi) tenemos el error "no route to host" de forma aleatoria en los arranques de los nodos, lo que provoca la inaccesibilidad de los mismos, se lista las acciones correctivas para solucionar el problema en esta instalación en particular:
Linux2 no arranca, errores:
iscsi-sfnet:linux2: Connect failed with rc -113: No route to host
iscsi-sfnet:linux2: establish_session failed. Could not connect to target
iscsi-sfnet:linux2: Waiting 1 seconds before next login attempt
Arrancamos en Single User (-S en el grub), cambiamos el permiso de ejecución al fichero /etc/init.d/iscsi y arrancamos normalemnte, consiguiendo acceso.
Comprobamos no hace ping a openfiler1-priv ni openfiler1, se observa ruta 0.0.0.0, la eliminamos:
route del -net 0.0.0.0 (sin exito)
Se reinicia net:
/etc/init.d/network restart
Conectividad recuperada, pero se observan líneas relacionadas con iptables (aunque el servicio está parado), se prueba a eliminar completamente el servicio:
service iptables save
service iptables stop
chkconfig iptables off
rpm -qa|grep iptables
rpm -e -nodeps iptables-x...
Sigue fallando tras otros reinicios.
Finalmente se encuentra el problema, corresponde con la carga de vmware-tools que es posterior al script de S10network:
S19vmware-tools
Se elimina la carga de vmware-tools (rm /etc/rc3.d/S19vmware-tools) y parece que ya no aparece el error "no route to host".
vmware-tools se sigue cargando en el rc2.d, pero no afecta porque lo importante era el "orden" de arranque, que lo último fuera el S10network
Linux2 no arranca, errores:
iscsi-sfnet:linux2: Connect failed with rc -113: No route to host
iscsi-sfnet:linux2: establish_session failed. Could not connect to target
iscsi-sfnet:linux2: Waiting 1 seconds before next login attempt
Arrancamos en Single User (-S en el grub), cambiamos el permiso de ejecución al fichero /etc/init.d/iscsi y arrancamos normalemnte, consiguiendo acceso.
Comprobamos no hace ping a openfiler1-priv ni openfiler1, se observa ruta 0.0.0.0, la eliminamos:
route del -net 0.0.0.0 (sin exito)
Se reinicia net:
/etc/init.d/network restart
Conectividad recuperada, pero se observan líneas relacionadas con iptables (aunque el servicio está parado), se prueba a eliminar completamente el servicio:
service iptables save
service iptables stop
chkconfig iptables off
rpm -qa|grep iptables
rpm -e -nodeps iptables-x...
Sigue fallando tras otros reinicios.
Finalmente se encuentra el problema, corresponde con la carga de vmware-tools que es posterior al script de S10network:
S19vmware-tools
Se elimina la carga de vmware-tools (rm /etc/rc3.d/S19vmware-tools) y parece que ya no aparece el error "no route to host".
vmware-tools se sigue cargando en el rc2.d, pero no afecta porque lo importante era el "orden" de arranque, que lo último fuera el S10network
Suscribirse a:
Entradas (Atom)