Bueno utilizamos IBM SDDPCM el cual, es un módulo de control de ruta de acceso cargable diseñado para soportar el entorno de configuración multipath en el servidor de almacenamiento IBM. Cuando se configuran los dispositivos aceptados como dispositivos capaces MPIO, SDDPCM es cargado y se hace parte del controlador del dispositivo de AIX MPIO con el modulo de SDDPCM mejora la disponibilidad de datos y equilibrio de carga de E/S.
• SDDPCM gestiona las rutas de acceso para proporcionar:
• Alta disponibilidad y equilibrio de carga de almacenamiento E/S.
• Recuperación tras fallos de ruta de acceso protección automática.
• Descarga concurrente de código interno bajo licencia.
• Prevención de un único punto anomalía causada por adaptador de bus de host, cable de canal de Fibra o interfaz principal adaptador en almacenamiento aceptado.
Nota referencia : Doc ID: 294869.1 Oracle ASM and Multi-Pathing Technologies
• IBM MPIO (Multi-Path I/O)
MPIO driver es soportado con IBM Total Storage ESS, DS6000 y solamente DS8000 series Y con IBM SVC (SAN Volume Controler).
La papita para crear los discos es la siguiente:
Una vez identificado el Multi-Pathing, se deben configurar los atributos apropiados para cada dispositivo utilizado en la configuración de ASM. Esta configuración de discos es solamente para AIX 5L.
1.- Propiedad : reserve_policy=no_reserve
2.- Se debe remover el PVID asignado a los discos.
Con esto ya no existirán problemas de configuración y preparación de los discos.
ASM
En Oracle 10g existen dos tipos de instancias: base de datos y ASM. La instancia ASM, es generalmente llamada +ASM1, Es iniciada con el parámetro del init.ora INSTANCE_TYPE=ASM. Este parámetro, cuando es configurado, Oracle es señalizado con las rutinas para iniciar una instancia ASM y no una instancia de base datos estándar. A diferencia de una base de datos estándar, la instancia ASM no contiene archivos físicos; como por ejemplo log files, control files ó datafiles, y solo requiere unos pocos parámetros en el init.ora. Una instancia ASM inicia los procesos backgrounds básicos, mas algunos nuevos que son específicos para la operación de ASM. La clausula STARTUP para una instancia ASM es similar a la instancia de base de datos. Por ejemplo, RESTRICT previene conectarse a la instancia de base de datos impide que se conecten a la instancia ASM. NOMOUNT Inicia la instancia ASM sin montar ningún Diskgroup. La opción MOUNT simplemente monta todos los grupos de discos definidos.
Instalando ASM
En casos donde una sola instancia ASM maneja una sola instancia de base de datos, esta puede ser suficiente mantener un solo ORACLE_HOME para ASM y la base de datos. Sin embargo, para sistemas que tiene una instancia ASM manejando el almacenamiento para varias instancias de base de datos y requieren una alta disponibilidad, es recomendable que la instancia ASM sea instalada separada en un ORACLE_HOME (ASM_HOME) distinto. Al instalar ASM en un ORACLE_HOME separado, entonces el listener puede ser iniciado desde este ASM_HOME.
En Oracle Database 10g Release 2, Oracle Universal installer (OUI) y DBCA han sido mejorados para permitir utilizar de una mejor manera, crear e instalar una instancia ASM en un ORACLE_HOME separado.
Las nuevas opciones de OUI son las siguientes:
• Instalar y configurar una instancia ASM, sin crear una base de datos.
• Instalar y configurar una base de datos que use ASM para manejar el almacenamiento
• Instalar y configurar ASM en un sistema que ya tiene bases de datos corriendo. (Mejora la disponibilidad)
Parámetros de una instancia ASM
Creando una Instancia ASM
Una vez configurado los dispositivos se puede crear la instancia ASM.
1. Ejecutar como root el siguiente comando
/oracle/product/10.2.0./bin/localconfig add
2. Iniciar DBCA para crear la instancia ASM con el usuario Oracle
/oracle/product/10.2.0./bin/dbca
Migrando una Base de Datos a ASM
Seleccionar la opción “Configure Automatic Storage Management
Crear un nuevo Diskgroup, presionado el botón “Create New”
Esta opción permite crear los grupos de discos y realizar la asignación de los dispositivos creados para esta finalidad. Es necesario asignar un nombre al Diskgroup para identificar cada uno de ellos. Para redundancia en caso de fallas, ha sido configurada como externa, dejando al almacenamiento manejar el espejado de cada uno de los dispositivos raw asignados a cada Diskgroup en ASM.
Oracle recomienda tener dos grupos de discos ASM para Datafiles y otro Diskgroup para almacenar el Flash Recovery Area, Control files, Online Redo Logs, Archive logs, copias de Datafiles, copia de Control Files y el archivo de Parámetros de la instancia. La vista V$RECOVERY_FILE_DEST, permite observar cuanto espacio fue asignado, utilizado y disponible en el Flash Recovery Area.
Con RMAN podemos catalogar esta área con el comando: “catalog recovery área NOPROMPT”. Este último se puede respaldar perfectamente con RMAN utilizando el comando “BACKUP RECOVERY AREA”
Presionar el botón “Finish” para terminar el proceso de creación de Diskgroups.
Que son los Diskgroups?
• Una capa de filesystem ASM es implícita al ser creado con un Diskgroup. El filesystem es transparente a los usuarios y solo accesible mediante la interconexión de base de datos, y la herramienta de comandos ASMCMD.
• Un archivo de base de datos creado dentro de un ASM diskgroup tiene sus extensiones de archivos (no confundir con los extents de la base de datos) distribuido igualmente a través de todos los discos en línea en el diskgroup, que proporciona una carga de I/O.
La creación de un diskgroup envuelve la validación de los discos que van a ser agregados. Estos discos deben tener los siguientes atributos:
• No pueden estar en uso por otro diskgroup
• No debe tener un header ASM pre-existente
• No puede tener un Oracle file header (desde un Oracle raw device datafile)
Este chequeo y validación previene que ASM no destruya cualquier dispositivo de datos utilizado. Discos con un status de header valido, que incluya candidato, provisionado, son los únicos autorizados para formar parte de un diskgroup.
Migrando a un nuevo almacenamiento ASM con RMAN
Es necesario realizar un respaldo full de la base de datos que se necesita duplicar al nuevo almacenamiento ASM. Existen dos formas que pueden eventualmente servir para cumplir este propósito. Lo más importante es tener este nuevo clon actualizado desde el sitio origen en el caso que se necesite crear una base de datos Standby. Lo otro es crear un clon recuperando la base de datos a un SCN especifico y tener un duplicado parcial. En fin, existen varias formas de hacer la migración al nuevo almacenamiento ASM.
En RMAN:
1.- Restaurar el controlfile al nuevo almacenamiento ASM
Connect / target
rman> restore controlfile to ‘+DATOS’
2.- Duplicar y Recuperar una base de datos al nuevo almacenamiento ASM
rman target /
set dbid=123456789
run
{
allocate channel c1 type disk;
allocate channel c2 type disk;
set newname for datafile 1 to '+DATOS';
set newname for datafile 2 to '+DATOS';
set newname for datafile 3 to '+DATOS';
.
.
.
set until time "to_date('01-01-2009 18:00:00','dd-mm-yyyy hh24:mi:ss')";
restore database;
switch datafile all
recover database;
}
Una vez realizados estos pasos ya pueden tener su base de datos en ASM.
Saludos.
Alberto Silva G.
1 comment:
cotosilva.blogspot.com is very informative. The article is very professionally written. I enjoy reading cotosilva.blogspot.com every day.
payday cash advances
cash advance
Post a Comment