Abf leccion 09

Jaime Amigo P. © 2006, Santiago - Chile
Instituto Profesional DuocUC
Escuela de Ingeniería
Redo Log File

2
Objetivos
Después de completar esta lección, usted deberá saber
lo siguiente:
• Explicar el propósito de los archivos de redo log
• Conocer la estructura de los archivos de redo log
• Control de log switches y checkpoints
• Multiplexar y mantener archivos de redo log
• Manejar archivos de redo log con OMF

3
Usando archivos de Redo Log
Los archivos de Redo Log registran todos los cambios hechos
en los datos y proveen mecanismos de recuperación de un
sistema ante una falla.
• Los archivos de redo log estan organizados dentro de
grupos
• Una base de datos Oracle requiere al menos de 2 grupos
• Cada redo log esta dentro de un grupo llamado member
(asociado fíisicamente a un archivo en disco)
Propósito de los Archivos de Redo Log
Los archivos de redo log proveen información de las transacciones ante un evento de falla de la base de datos.
Cada transacción es escrita sincrónicamente en los archivos de redo log con el propósito de proveer un
mecanismo de recuperación en caso de falla (con excepciones como cargas o lecturas hechas con la opcion
NOLOGGING). Esto incluye transacciones que no han sido comiteadas, información del segmento de undo, y
sentencias de administración de schemas y objetos. Los archivos de redo log son usados en situaciones como
falla de una instancia para recuperar los datos comiteados que no han sido escritos a los datafiles. Los archivos
de redo log son usados solo para recuperación.
Obteniendo información de Redo Log
El comando archive log list nos muestra si la base de datos está en modo archivelog o noarchivelog y si el
archivado automático está funcionando
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /archive1/expl1
Oldest online log sequence 2029
Next log sequence to archive 2031
Current log sequence 2031

4
Estructura de Archivos de Redo Log
Estructura de Archivos de Redo Log
El DBA puede setear la base de datos Oracle para mantener copias de archivos de
redo log y asi evitar tener un único punto de falla en una base de datos.
Grupos de Redo Log Online
•Es un conjunto de copias idénticas de archivos de redo log online
•El proceso LGWR escribe concurrentemente la misma información en todos los
miembros de redo log del grupo
•El Oracle Server necesita un mínimo de 2 grupos de archivos de redo log online para
la normal operación de la base de datos

5
Miembros Redo Log Online
•Cada archivo de redo log online en un grupo es llamado miembro
•Cada miembro en un grupo tiene idéntico número de secuencia de logs y del mismo
tamaño. El número de secuencia de logs es asignado cada vez que el Oracle Server
comienza a escribir un grupo de log e identifica cada archivo de redolog de forma
única. El número de secuencia de log es almacenado en el archivo de control y en la
cabecera de todos los datafiles.
Creando un archivo de redo log inicial
El seteo inicial de los grupos de redolog online y miembros son creados durante la
creación de la base de datos.
Los siguientes parámetros limitan el número de archivos de redo log online:
•El MAXLOGFILES en el comando CREATE DATABASE específica el máximo absoluto
de grupos de redo logs online
•El máximo y el valor por defecto para MAXLOGFILES depende en tu sistema operativo
•El parámetro MAXLOGMEMBERS usado en el comando CREATE DATABASE determina
el número máximo de miembros por grupo. El máximo y el valor por defecto de
MAXLOGMEMBERS depende de tu sistema operativo

6
¿Cómo trabajan los Redo Log?
• Los redo log son usado de manera clicica
• Cuando un archivo de redo log esta lleno, LGWR
continua con el siguiente grupo de log
– Este proceso se llama LOG SWITCH
– También ocurren operaciones de checkpoint
– Esta información es escrita al archivo de control
¿Cómo trabajan los Redo Log?
El Oracle Server secuencialmente registra todos los cambios hechos en la base de datos al buffer de
redo log. Las entradas a los redo son escritas desde el buffer de redo log a uno de los grupos de redo
logs llamado grupo actual de redo log online (current online redo log group) por el proceso LGWR. El
LGWR escribe bajo las siguientes situaciones:
- Cuando se hacen commits a transacciones
- Cuando el buffer de redo log se llena (become one-third full)
- Cuando hay mas de 1 MB de registros modificados en el buffer de redo log
- Antes que el proceso DBWn escriba los bloques modificados en el database buffer cache a los
datafiles
Los redo logs son usados de manera ciclica. Cada grupo de archivos de redo log esta identificado por un
número de secuencia que es sobreescrito cada vez que el log es reusado
Log Switches
LGWR escribe secuencialmente a los archivos de redolog online. Cuando el grupo de redo log actual se
llena, LGWR comienza a escribir en el siguiente grupo. Este proceso es llamado LOG SWITCH.
Cuando el último archivo de redo log online se llena, LGWR retorna al primer grupo de redo log y
comienza a escribir nuevamente

7
Checkpoints
Consiste en escribir a disco los buffers modificados en en la SGA, asegurándose que
se escriban en los datafiles y no solo en los redo log files. Esto asegura consistencia
en la BD.
Durante un checkpoint:
- Los buffers sucios de la base de datos son escritos a los datafiles por el
procesos DBWn. El número de buffers que esta siendo escrito por DBWn esta
determinado por el parametro FAST_START_MTTR_TARGET
- El proceso Checkpoint CKPT actualiza las cabezaras (headers) de todos los
datafiles y archivos de control, reflejando que esto a sido completado exitosamente
Checkpoints pueden ocurrir para todos los datafiles de una base de datos o para
datafiles específicos.
Un checkpoint ocurre por ejemplo, en las siguientes situaciones:
-En cada log switch
-Cuando una instancia ha sido bajada con la opción normal, transactional o immediate
-Cuando es forzado por un seteo del parámetro FAST_START_MTTR_TARGET
-Cuando se cumple un tiempo desde el último checkpoint indicado en el parámetro
LOG_CHECKPOINT_TIMEOUT
-Cuando se alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL
-Cuando manualmente es requerido por un DBA (ALTER SYSTEM CHECKPOINT)
-Cuando se ejecuta un ALTER TABLESPACE [OFFLINE NORMAL | READ ONLY |
BEGIN BACKUP], esto causa un checkpoint sobre un datafile específico
La información de cada checkpoint es registrada en el archvo alertSID.log si el
parámetro de inicialización LOG_CHECKPOINTS_TO_ALERT esta seteado en TRUE.
El valor por defecto es FALSE y no registra los log de checkpoint

8
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN
FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ----------
--------------------
1 1 1576 52428800 1 NO CURRENT 234960305
12/19/05 08:26:09
2 1 1572 52428800 1 YES INACTIVE 211974124
04/04/05 11:56:21
3 1 1573 52428800 1 YES INACTIVE 225420507
04/15/05 18:23:39
4 1 1574 52428800 1 YES INACTIVE 225423060
04/19/05 16:40:06
5 1 1575 52428800 1 YES INACTIVE 225425126
04/25/05 10:24:35
5 rows selected.
SVRMGR> alter system switch logfile;
Statement processed.
SVRMGR> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHAN
FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ----------
--------------------
1 1 1576 52428800 1 NO INACTIVE 234960305
12/19/05 08:26:09
2 1 1577 52428800 1 NO CURRENT 235000655
04/25/06 01:49:34
3 1 1573 52428800 1 YES INACTIVE 225420507
04/15/05 18:23:39
4 1 1574 52428800 1 YES INACTIVE 225423060
04/19/05 16:40:06
5 1 1575 52428800 1 YES INACTIVE 225425126
04/25/05 10:24:35
5 rows selected.

9
Agregando Grupos de Redo Log
Online
Agregando Grupos de Redo Log
En algunos casos es preciso agregar grupos de log adicionales. Por ejemplo, agregar
grupos se puede resolver problemas de disponibilidad. Para crear un nuevo grupo de
archivos de redo log online, se utiliza el siguiente comando:
ALTER DATABASE [database]
ADD LOGFILE [GROUP integer] filespec
[, [GROUP integer] filespec ] ... ]
Usted específica el nombre y ubicación del miembro en filespec. El valor del
parámetro GROUP puede ser seleccionado de cada grupo de archivo de redo log. Si
se omite este parámetro, el Oracle Server genera este valor automáticamente

10
Agregando Miembros Redo Log Online
Agregando Miembros Redo Log Online
Se puede agregar nuevos miembros a los grupos existentes usando el comando
ALTER DATABASE ADD LOGFILE MEMBER:
ADD LOGFILE MEMBER
[ ‘filename’ [REUSE] [, ‘filename’ [REUSE]] ...
TO {GROUP integer | (‘filename’ [, ‘filename’] ...) }
] ...
Use el path completo para identificar el nombre del miembro del archivo de log, de otra
forma los archivos son creados en el directorio por defecto el servidor de base de
datos
Si el archivo ya existe, este debe tener el mismo tamaño y se debe especificar la
opción REUSE. Se puede identificar el grupo TARGET especificando uno o mas
miembros del grupo o especificando el número del grupo

11
Borrando Grupos Redo Log Online
Borrando Grupos Redo Log Online
Incrementar o decrementar el tamaño de los grupos de redo log online, agregar nuevos
grupos (con el nuevo tamaño) y borrar los viejos
Una entrada en el grupo de redo log online puede ser borrada con el comando ALTER
DATABASE DROP LOGFILE:
DROP LOGFILE {GROUP integer| (‘filename’ [, ‘filename’] ...)}
[, {GROUP integer| (‘filename’ [, ‘filename’] ...)} ] ...
Restricciones
•Una instancia requiere de al menos 2 grupos de redo log online
•Un grupo activo o actual (current) no puede ser borrado
•Cuando un grupo de redo log online es borrado, el sistema operativo no borra el
archivo

12
Borrando Miembros Redo Log Online
Borrando Miembros de Redo Log Online
Uno puede desear borrar un miembro de un redo log online porque este puede estar
inválido. Usar el comando ALTER DATABASE DROP LOGFILE para borrar uno o
más miembros de redo log online.
ALTER DATABASE [database] DROP LOGFILE MEMBER ‘filename’ [, ‘filename’] ...
Restricciones
• Si el miembro que se desea borrar es el último del grupo, no se puede eliminar dicho
miembro
• Si el grupo esta CURRENT, primero debes forzar un Log Switch antes de borrar el
miembro
• Si la base de datos esta corriendo en modo ARCHIVELOG y el grupo de log file que esta
siendo usado no esta archivado, entonces el miembro no puede ser borrado
• Cuando un miembro de redo log online es borrado, el archivo del sistema operativo no es
borrado

13
Limpiando, Reubicando o Renombrando
Archivos de Redo Log Online
• Limpiando archivos de redo log online
ALTER DATABASE CLEAR LOGFILE
‘$HOME/oradata/u01/log2a.rdo’
• Para reubicar o renombrar archivos de redo log
online se necesita agregar nuevos miembros y borrar
los miembros viejos
Limpiando, Reubicando o Renombrando Archivos de redo Log Online
Si el archivo de redo log esta corrupto en todos los miembros, el DBA debe resolver
este problema reinicializando estos archivos de redo log usando el comando
ALTER DATABASE CLEAR LOGFILE:
ALTER DATABA [database]
CLEAR [UNARCHIVED] LOGFILE
{GROUP integer | (‘filename’ [,’filename’] ...)}
[,{GROUP integer | (‘filename’ [,’filename’] ...)}] ...
Usar este comando es equivalente a agregar o borrar un archivo de redo log online.
Pero se puede usar este comando solo si hay 2 grupos de log con un archivo cada
uno y cuando el grupo es limpiado esta disponible pero no ARCHIVED

14
Restricciones
Se puede limpiar un grupo de archivos de redo log online que este archivado o no. Sin
embargo, cuando no esta archivado se debe incluir la palabra clave UNARCHIVED.
Esto hace inutilizable el backup si el archivo de redo log online es necesario para la
recuperación.
Reubicando y renombrando archivos de redo log
La ubicación de los archivos de redo log puede ser modificada agregando nuevos
archivos de log y borrando los viejos. Otro método es a través de ALTER DATABASE
RENAME FILE pero requiere colocar la base de datos en modo MOUNT. Esto es
mucho mas fácil que estar agregando y borrando archivos.

15
Configuración de Redo Log Online
Número de Archivos de Redo Log Online
Para determinar el número apropiado de archivos de redo log para una instancia de
base de datos, se deben testear varias configuraciones.
En algunos casos, una instancia puede necesitar solo 2 grupos. En otras situaciones,
se pueden requerir grupos adicionales para garantizar que los grupos estén siempre
disponibles para LGWR. Por ejemplo, si los mensajes de LGWR en los archivos de
trazas o archivos de alertas indican que LGWR frecuentemente esta esperando para
un grupo porque un checkpoint no se ha completado o un grupo no ha sido archivado,
es preciso agregar mas grupos.
Si bien es posible tener grupos multiplexados de diferentes números de miembros, es
recomendable construir una configuración simétrica. Una configuración asimétrica
debería ser solo el resultado temporal de una situación inusual como falla en un disco.

16
Ubicación de los archivos de redo log online
Cuando se multiplexan los archivos de redo log online, se colocan los miembros de
estos en diferentes discos físicos. Para hacer esto a menudo un miembro esta
disponible y otro no, no es necesario bajar la instancia.
Separe los archivos de archive log y redo log en diferentes discos para reducir la
contención entre los procesos ARCn y LGWR.
Los datafile y archivos de redo deben ser colocados en diferentes discos para reducir
la contención de LGWR y DBWn y así, reducir el riesgo de pérdida de datafiles y
archivos de redo log ante un evento de falla de medios.
Tamaño de archivos de redo log
El tamaño mínimo de un archivo de redo log es 50 KB y el máximo tamaño esta dado
por el Sistema Operativo. Miembros de diferentes grupos pueden tener diferentes
tamaños, sin embargo, no hay beneficios de tener esta configuración.
Grupos de diferentes tamaños podrian ser requeridos como resultado temporal si se
desea cambiar el tamaño de los miembros de los grupos de redo log online. En este
caso, se deben crear un nuevos grupos con diferentes tamaños y borrar los antiguos.
Las siguientes situaciones pueden influir en la configuración de los archivos de redo
log:
•Número de log switches y checkpoint
•Número y cantidad de entradas de redo
•Cantidad de espacio en el medio de almacenamiento; por ejemplo: sobre una cinta si
ARCHIVING esta habilitada

17
Manejando Archivos Redo Log con OMF
• Un grupo puede ser agregado sin especificación de
archivos
– ALTER DATABASE ADD LOGFILE;
• Si un grupo es borrado, todos los archivos
correspondientes a OMF son borrados a nivel de
sistema operativo
– ALTER DATABASE DROP LOGFILE GROUP 3;
Manejando Archivos Redo Log con OMF
Agregar un grupo
Para crear un nuevo grupo de archivos de redo log online, el DBA debe utilizar el
comando ALTER DATABASE ADD LOGFILE. El comando ha sido modificado y no se
requiere la especificación de archivo. En el ejemplo se agrega un nuevo archivo de log
dentro de un miembro en la ubicación DB_CREATE_ONLINE_LOG_DEST_1 y el
miembro en la ubicación DB_CREATE_ONLINE_LOG_DEST_2
Los nombres son únicos para los miembros generados automáticamente
Borrar un grupo
La claúsula GROUP se usa para eliminar un archivo de log. En el ejemplo, el archivo
asociado al sistema operativo dentro de cada miembro de OMF es borrado
automáticamente
Archived Redo Log y OMF
No pueden archivarse archivos de redo log con OMF. La ubicación de archivos de
redolog para archiving debe ser especificada dentro del parámetro
LOG_ARCHIVE_DEST_n

18
Obteniendo Información de Grupos y
Miembros
La información de grupos y miembros se obtiene
consultando el diccionario de datos
• V$LOG
• V$LOGFILE
Obteniendo información de grupos y miembros
V$LOG
La siguiente consulta retorna información de los archivos de redo log online desde el
archivo de control
SQL> SELECT group#, sequence#, bytes, members, status FROM V$LOG;
Los siguientes items son los valores comúnmente desplegados para la columna
STATUS:
•UNUSED: indica que el grupo de redo log online nunca a sido escrito. Es el estado de un
archivo recientemente agregado
•CURRENT: indica que el grupo de redo log online esta CURRENT (EN USO) o ACTIVO
•ACTIVE: indica que el grupo de redo log online esta ACTIVE pero no EN USO
(CURRENT). Es necesario para recuperación ante fallas. Puede estar o no en modo
ARCHIVED

19
•CLEARING: indica que el log esta siendo recreado como un log vacío después de un
ALTER DATABASE CLEAR LOGFILE. Después que el log ha sido limpiado, el estado
cambia a UNUSED
•CLEARING_CURRENT: El log actual esta siendo limpiado.
V$LOGFILE
Vista dinámica de rendimiento para obtener los nombres de todos los miembros de un
grupo,
SQL> SELECT member FROM V$LOGFILE;
El valor de la columna STATUS puede ser uno de los siguientes:
•INVALID: indica que el archivo esta inaccesible
•STALE: indica que el contenido del archivo esta incompleto
•DELETED: indica que el archivo no esta largamente usado (IS NO LONGER USED)
•Blanco indica que el archivo esta en uso

20
Archivado de Redo Log
Cuando los archivos de redo log online se llenan, pueden
ser archivados
• Existen 2 ventajas del archivado de redo log:
– Recuperación : Un backup de BD junto con el
archivado online de los redo log puede garantizar
la recuperación de todas las transacciones
“comiteadas”
– Respaldo : Puede ser ejecutado mientras la
BD esta abierta
• Por defecto una BD es creada en modo
NOARCHIVELOG
Una de las decisiones más importantes de un DBA esta en determinar si una BD
trabajara en modo ARCHIVELOG o en modo NOARCHIVELOG
NOARCHIVELOG
En este modo, los archivos de redo log online son sobrescritos cada vez que el archivo
se llena y ocurre un log switch. LGWR no sobreescribe un grupo hasta que el
checkpoint para el grupo se completa.
ARCHIVELOG
Si la base de datos esta corriendo en este modo, los grupos inactivos y llenos son
archivados. Todos los cambios realizados en la BD son registrados en los archivos de
redo log online, el DBA puede usar los respaldos físicos y los archivos de redo log para
recuperar la base de datos sin perder la información comiteada.

21
Hay dos formas en la que los archivos de redo log son archivados:
•Manualmente
•Automáticamente : Metodo recomendado
El parámetro de inicialización LOG_ARCHIVE_START indica si el archivado será
automático o manual cuando suba la instancia. Puede tener dos valores:
•TRUE indica que el archivado es automático. ARCn inicia el archivado de los
grupos de logs llenos después de cada log switch
•FALSE valor por defecto, indica que el DBA respalda manualmente los archivos
de redo llenos. El DBA debe ejecutar manualmente por comandos cada vez que desee archivar
el archivo de redo log online. Todos o algún archivo de redo log puede ser archivado
manualmente.

22
• El archivado de redo log es ejecutado por ARCn (Archiver)
o manualmente a través de sentencias SQL
• Una entrada en el archivo de control registra el nombre del
log archivado, número de secuencia y otros datos de
interes
• Los archivos de redo log no pueden ser reusados hasta
que un checkpoint se ejecuta y el proceso ARCn respalde
dicho archivo en los Archive Redo Log
• El archivo de redo log puede ser multiplexado
• Los archivos de archive de redo log debe ser mantenidos
por el DBA
• Mayores informaciones hay en V$LOGHIST y
V$ARCHIVED_LOG
Información de los log archivados puede ser obtenida desde V$LOGHIST y
V$ARCHIVED_LOG
SQL> select * from v$loghist

23
Parámetros de Redo Log
FAST_START_MTTR_TARGET
Parámetro expresado en segundos, que determina el tiempo deseado para que ocurra la recuperación
de una instancia , es decir, permite controlar el tiempo en que tarda en volver a levantarla. Si este valor
es muy pequeño, de modo que no pueda completarse la recuperación en dicho instante de tiempo,
entonces el TARGET_MTTR (tiempo efectivo para la recuperación) equivale al tiempo mínimo que el
sistema permite para la recuperación de la instancia. Por el contrario si el valor es muy grande, tanto que
ni en el peor de los casos la recuperación puede tardarse dicha cantidad de tiempo, entonces el
TARGET_MTTR toma el valor estimado para la recuperación.
Este parámetro toma por defecto el valor 0, lo que significa que dicho parámetro no será tomado en
cuenta en la recuperación. El máximo valor que puede tomar es 3600, que equivale a 1 hora.
Cuando se utiliza este parámetro, es conveniente deshabilitar los parámetros
LOG_CHECKPOINT_TIMEOUT y LOG_CHECKPOINT_INTERVAL.
Para ver este parámetro:
SELECT TARGET_MTTR FROM V$INSTANCE_RECOVERY;
Para modificar este parámetro:
ALTER SYSTEM SET FAST_START_MTTR_TARGET=<nuevo valor>;
Permite especificar el tiempo máximo que puede transcurrir entre el próximo checkpoint y la escritura del
último bloque en el redo log. Es decir, limita el tiempo que puede permanecer un bloque sucio en el
cache antes de ser escrito a disco.
En el caso en que el número de actualizaciones es significativo es conveniente que el valor que tome
este parámetro sea pequeño de modo que dichas actualizaciones sean llevadas a almacenamiento
seguro rápidamente, pero en los casos en que no hay gran cantidad de actualizaciones lo más
conveniente es que este valor sea grande de modo que el número de escrituras de disco sea menor,
dado que no habrá que reflejar muchos cambios.
Este parámetro toma por defecto el valor 1800, que corresponde a 30 minutos entre cada checkpoint.
SELECT LOG_CHKPT_TIMEOUT_REDO_BLKS FROM V$INSTANCE_RECOVERY;
ALTER SYSTEM SET LOG_CHECKPOINT_TIMEOUT=<nuevo valor>;

24
LOG_CHECKPOINT_INTERVAL
Permite especificar el número máximo de bloques que pueden existir entre el próximo checkpoint y la
escritura del último bloque en el redo log, esto es, limita el número de bloques que pueden existir entre el
checkpoint y el final de la bitácora.
Este parámetro toma por defecto el valor 0 lo cual indica que este parámetro será ignorado.
Al igual que para el parámetro LOG_CHECKPOIN_TIMEOUT si el número de actualizaciones es
considerable es conveniente que el número de bloques entre cada checkpoint sea bajo, mientras que si
el número de actualizaciones es bajo seria conveniente que el número de bloques fuera alto. Sin
embargo para ambos casos puede haber desperdicio en cuanto al rendimiento ya que no se sabe
cuántos bloques pueden ser afectados por las actualizaciones.
SELECT LOG_CHKPT_INTERVAL_REDO_BLKS FROM V$INSTANCE_RECOVERY
ALTER SYSTEM SET LOG_CHECKPOINT_INTERVAL = <valor en número de bloques>
LOG_ARCHIVE_START
Parámetro que indica a la base de datos que lleve una bitácora en disco de los archivos de redo log
LOG_CHECKPOINT_TO_ALERT
Parámetro que permite monitorear la actividad del checkpoint en una base de datos. Por defecto el valor
es FALSE. Esta información queda registrada en los archivos de Alertas de las base de datos.
DB_CREATE_ONLINE_LOG_DEST_n
Parámetro que define el destino por defecto de los archivos de redo log.
LOG_ARCHIVE_DEST_n
Parámetro que define el destino por defecto de los archivos de archive redo log.

25
QUICK REFERENCE
ALTER SYSTEM SWITCH LOGFILE
ALTER SYSTEM CHECKPOINT
ARCHIVE LOG LIST
ALTER DATABASE ADD LOGGILE
ALTER DATABASE ADD LOGFILE MEMBER
ALTER DATABASE RENAME FILE
ALTER DATABASE DROP LOGFILE
ALTER DATABASE DROP LOGFILE MEMBER
ALTER DATABASE CLEAR LOGFILE
Comandos
NingunaVistas del diccionario de datos
V$THREAD
V$LOG
V$LOGFILE
V$DATABASE, V$LOGHIST, V$ARCHIVED_LOG
Vistas dinámicas de
rendimiento
LOG_CHECKPOINT_INTERVAL
FAST_START_MTTR_TARGET
Parámetros dinámicos de
inicialización
LOG_CHECKPOINTS_TO_ALERT
UTL_FILE_DIR
Parámetro de inicialización
ReferenciaContexto

Abf leccion 09

Más contenido relacionado

La actualidad más candente (19)

Destacado (20)

Similar a Abf leccion 09 (20)

Más de victdiazm (20)

Abf leccion 09