1. Documentación en Tahiti -> Masters Book List -> Performance Tuning Guide -> 8 I/O Configuration and Design
2. Este objetivo, aunque aparentemente sólo se específica DATAFILES, vamos a aprovecharlo para el resto de ficheros de la BD. Vamos a crear un nuevo directorio, simulando que fuera un disco diferente
# Creamos el directorio (como root) y le damos permisos mkdir -p /u02/app/oracle/oradata/OCM chown -R oracle:oinstall /u02/app/oracle chmod -R 775 /u02/app/oracle
3. Empezamos recreando los ficheros REDOLOG, haciendo striping de cada miembro de cada grupo en diferentes discos.
-- Comprobamos la configuración actual de los ficheros REDOLOG -- Veremos que tenemos tres grupos, y en cada grupo sólo tenemos un miembro SELECT * FROM V$LOG; SELECT * FROM V$LOGFILE; -- Vamos a recrear todos los grupos pero con multiplexación (dos copias por grupo) y aprovechamos para aumentar el tamaño ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/OCM/redo401.log','/u02/app/oracle/oradata/OCM/redo402.log') SIZE 200M; -- Borramos el primer grupo y lo recreamos como el anterior grupo -- En uno de los estos pasos nos dara un error (ORA-01623) por que el log está en estado CURRENT o ACTIVE. Para dejarlo INACTIVE: -- # ALTER SYSTEM SWITCH LOGFILE; -- # ALTER SYSTEM CHECKPOINT; ALTER DATABASE DROP LOGFILE GROUP 1; ALTER DATABASE ADD LOGFILE GROUP 1 ('/u01/app/oracle/oradata/OCM/redo101.log','/u02/app/oracle/oradata/OCM/redo102.log') SIZE 200M REUSE; -- El mismo procedimiento con el GRUPO 2 ALTER DATABASE DROP LOGFILE GROUP 2; ALTER DATABASE ADD LOGFILE GROUP 2 ('/u01/app/oracle/oradata/OCM/redo201.log','/u02/app/oracle/oradata/OCM/redo202.log') SIZE 200M REUSE; -- El mismo procedimiento con el GRUPO 3 ALTER DATABASE DROP LOGFILE GROUP 3; ALTER DATABASE ADD LOGFILE GROUP 3 ('/u01/app/oracle/oradata/OCM/redo301.log','/u02/app/oracle/oradata/OCM/redo302.log') SIZE 200M REUSE; -- Borramos el GRUPO 4 ALTER DATABASE DROP LOGFILE GROUP 4; -- Revisamos el nuevo tamaño (200M) y que la multiplexación es correcta (un miembro en cada disco) SELECT * FROM V$LOG; SELECT * FROM V$LOGFILE;
4. Ya hemos visto como podemos hacer copias del CONTROLFILE en este objetivo. Como ya tenemos dos copias (tres sería recomendable si tenemos tiempo extra para hacerlo) lo dejamos así. Lo importante es que cada copia esté en un DISCO DIFERENTE, para poder recuperar la BD en caso de fallo de uno de ellos.
5. Respecto al STRIPING de DATAFILES. Nuestro objetivo es repartir las I/O por los diferentes discos sin que lleguemos a saturar ninguno. Una vez que tenemos una estimación de la carga, podemos crear DATAFILES en otros discos y Oracle se encarga de distribuir la carga entre ellos.
-- Vamos a añadir un DATAFILE al TBS SYSTEM como ejemplo, pero el procedimiento manual es muy sencillo ALTER TABLESPACE SYSTEM ADD DATAFILE '/u02/app/oracle/oradata/OCM/system02.dbf' SIZE 400M;
6. Es muy muy recomendable tener los ficheros ARCHIVELOGS y demás ficheros relacionado con la recuperación en otro disco. Como estamos utilizado la FAST RESCOVERY AREA (FRA), suponemos que esta ubicación pertenece a otro disco.
-- Comprobamos la ubicación de la FRA (Contendrá BACKUPS, ARCHIVELOGS, FLASHBACK LOGS, ...) -- Debe estar en otro disco diferente al de los DATAFILES para no perder datos en caso de fallos de disco show parameter db_recovery -- En nuestro caso como tenemos configurada la FRA, el parámetro LOG_ARCHIVE_DEST_1 toma esta ubicación de forma implícita -- Comprobamos que el valor del parámetro. Estará vacio, pero se asume que contiene la ruta de "db_recovery_file_dest" show parameter log_archive_dest_1 -- Podemos comprobar la ubicación donde se están creando los ARCHIVELOGS desde la BD SELECT NAME FROM V$ARCHIVED_LOG ORDER BY COMPLETION_TIME;
7. Esta multiplexación que hemos hecho a posteriori, se puede hacer directamente cuando creamos la BD, ya sea con DBCA o manualmente. En posteriores ejercicios instalaremos una BD manualmente y haremos striping de los ficheros de BD directamente.