Oracle Exadata Database Machine: “Write-Back Flash Cache”

Por Joel Pérez , Deiby Gómez y Y.V RaviKumar (OCM)
Publicado en enero 2014

Desde el nacimiento de “Oracle Exadata” en el año 2008 en su primera versión optimizada para “Data Warehousing”, progresivamente se han adicionado nuevas características para aumentar su capacidad de trabajo para base de datos de tipo “Data warehousing” (muchas consultas contra grandes cantidades de datos) y OLTP (muchas sentencias de escritura y lectura) o incluso para ser capaz de soportar cargas combinadas.

Tener un óptimo rendimiento siempre ha sido el principal objetivo de la solución “Oracle Exadata” y esto ha sido posible gracias al surgimiento de nuevas características como “Smart Scan”, “Smart Flash Cache”, “Smart Flash Log”, “Storage Indexes”, entre otros. La ultima característica que fue adicionada para asegurar el mejor rendimiento de “Oracle Exadata” fue "Write-Back Flash Cache" la cual surge como una combinación de hardware (Flash Drives) y el Software (Exadata Storage Server Software).

Hay dos características con que cuenta el Software de los “Storage Servers” que mejoran el “Hardware” de “Exadata” y hacen de “Exadata Database Machine” un sistema rápido en el cual desplegar una base de datos Oracle “Single” o en “RAC”

  1. “Exadata Smart Flash Cache”: Provee la capacidad para alojar objetos activos dentro de los dispositivos flash.
  2. “Exadata Smart Flash Log”: Acelera las funciones críticas de escritura hacia los “Redo logs” para una base de datos.

El utilizar una base de datos requiere asumir un compromiso con el rendimiento en la entrega de la información por lo que el Software de “Exadata Storage server” en conjunto con la base de datos Oracle hace sencillo el cumplimiento de ese compromiso proporcionando la nueva característica llamada “Write-Back Flash Cache”.

“Write-Back Flash Cache” provee la capacidad de realizar operaciones de escritura directamente  a los dispositivos “flash”, sin perder la capacidad de realizar operaciones de  lecturas también. Si una aplicación lleva a cabo escritura intensa generándose en dicha actividad eventos de “free buffer waits”, entonces “Write-Back Flash Cache” es una buena opción para solucionar la contención de este escenario.

Cualquier Hardware de “Exadata” a partir de la versión tres (X3) puede tomar ventaja de esta característica. La versión dos de Exadata (X2) también puede utilizar ésta característica si la versión del Software que utiliza es 11.2.3.2.1 en adelante.

A partir de la versión 11.2.3.2.1, “Flash Cache” es automáticamente establecido a “Write-Through”.  El comando “ALTER CELL” es usado para cambiar este modo hacia “Write-Back”.

“Write-Back Flash Cache” de forma significativa mejora las operaciones que sufren de intensa escritura por el hecho de que escribir a dispositivos “flash” es más rápido que escribir a discos duros. Dependiendo de la aplicación, en las maquinas X3-2 el rendimiento de escrituras puede ser mejorado hasta 20 veces más que las escrituras hacia discos duros y 10 veces más con respecto a las escrituras a disco en X2-2.

El atributo de “flashCacheMode” dentro de un “Storage Server” determina este modo. Los posibles valores para este parámetro son:

  • WriteThrough
  • WriteBack

La sentencia “LIST CELL” muestra el actual valor de éste parámetro.

Por Ej:

CELLCLI>	list cell attributes flashcachemode
		WriteBack



CELLCLI>list cell detail

 

Características de Write-Back Flash Cache

  • Flash Cache provee un mejor rendimiento en cuanto a lecturas y escrituras.
  • La versión 11.2.3.2.1 del “Software” de los “Storage Servers” es la versión mínima requerida que permite escribir dentro de “Flash Cache”.

 

  • Esto implica que las escrituras de base de datos primero serán realizadas en “Flash Cache” y la base de datos únicamente retornara un mensaje de conocimiento indicando que los datos ya se encuentran persistentes, aunque aún no hayan sido sincronizados a los discos duros.
  • Inicialmente, cuando se realiza una operación de inserción ( “Insert into” ), un bloque es escrito al “Flash Cache” y marcado de inmediato como "Dirty" para indicar que es la ultima copia del bloque, eventualmente se sincronizará con los Discos duros mediante el algoritmo (“LRU: Last Recently Used”). Si se realiza una operación de modificación (“Update”) y los bloques que deben ser modificados no están en “Flash Cache”, entonces es leído desde los discos duros y colocado en el “Flash Cache”, es actualizado y luego marcado como "Dirty". Si una operación está solicitando un bloque, y dicho bloque se encuentra en “Flash Cache”, es leído directamente desde allí, de esta manera se reduce la latencia en lecturas. Un bloque escrito en “Flash Cache” el cal posea alta frecuencia de acceso puede llegar a estar en “Flash Cache” hasta por años, sin embargo, si el bloque es accedido pocas veces, será descargado a los discos duros.

Beneficios de “Write-Back Flash Cache”

  • Mejora el rendimiento de las operaciones de escritura que son realizadas de forma intensa, debido a que escribir en los dispositivos “Flash” es mucho más rápido que escribir en discos duros de (100,000 IOPS vs 3,600 IOPS).
  • El rendimiento de las escrituras en “Exadata X3-2” puede ser mejorado hasta 20 veces más con respecto al rendimiento de escrituras hacia los discos duros.
  • El rendimiento de las escrituras en “Exadata X2-2” puede ser mejorado hasta 10 veces más con respecto al rendimiento de escrituras hacia discos duros.
  • “Write-Back Flash Cache” acelera las lecturas y escrituras de manera transparente a los usuarios para todas las cargas de tipo OLTP y DW.
  • “Write-Back Flash Cache” reduce la latencia de escrituras en “Redo Logs” cuando los dispositivos “Flash” comparten discos con los datos del negocio.
  • Si existen significantes esperas por el evento "free buffer waits" o muchas esperas en las revisiones de cuellos de botellas en escrituras dentro de los reportes AWR (Automatic Workload Repository), entonces se recomienda altamente usar la característica “Write-Black Flash Cache”.

¿Cómo habilitar la característica “Write-Back Flash Cache”?

A través de los siguientes 2 métodos:

  1. Método escalonado
  2. Método no escalonado

Nota:  Antes de realizar los pasos que se indican a continuación, realice  los siguientes chequeos con el usuario “root” desde uno de los servidores de base de datos:

Realizar chequeo de todos los “Grid Disks” y asegúrar que los parámetros " asmdeactivationoutcome" y "asmmodestatus" estén establecidos a "Yes" y "ONLINE" respectivamente:

# dcli -g cell_group -l root cellcli -e list griddisk 
attributes asmdeactivationoutcome, asmmodestatus

Método Continuo:

En estos pasos se asume que  las instancias de base de datos y ASM están iniciadas y que la característica “Write-Back Flash Cache” se habilitará en un Storage Server a la vez.

1. Realizar “Login” al Storage Server.

2. Eliminar el “Flash Cache” en todo el “Storage Server”:

#cellcli –e drop flashcache

3. Revisar que el estado de ASM y que los “Grid Disks” estén “OFFLINE”. El siguiente comando debería retornar "Yes" para que los “Grid Disks” que se hayan listado:

 
# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

4. Deshabilitar los “Grid Disks” en el “Storage Server”.

# cellcli –e alter griddisk all inactive

5. Detener el servicio CELLSRV

# cellcli -e alter cell shutdown services cellsrv

6. Establecer el “Flash Cache” del “Storage Server” a "WriteBack"

# cellcli -e "alter cell flashCacheMode=writeback"

7. Iniciar el servicio CELLSRV

# cellcli -e alter cell startup services cellsrv

8. Activar los “Grid Disk” en el “Storage Server”

# cellcli –e alter griddisk all active

9. Verificar que todos los “Grid Disks” están funcionando correctamente y luego establecerlos a estado “ONLINE” utilizando el siguiente comando:

# cellcli -e list griddisk attributes name, asmmodestatus

10. Recrear el Flash Cache

# cellcli -e create flashcache all

11. Revisar el estado del Storage Server para confirmar que ahora está trabajando en modo "Write-Back":

# cellcli -e list cell detail | grep flashCacheMode

12. Repetir los mismos pasos en cada uno de los “Storage Servers” restantes. Sin embargo, antes de colocar otro “Storage Server” en estado “OFFLINE”, es necesario ejecutar lo siguiente para confirmar que el parámetro "asmdeactivationoutcome" muestra el valor "YES":

# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

Método no continuo:

En estos pasos se asume que  las instancias de  base de datos y ASM no están iniciadas mientras se esté realizando el proceso de activación de la característica “Write-Back Flash Cache”.

1. Eliminar todo el “Flash Cache” en el “Storage Server”

# cellcli -e drop flashcache

2. Apagar el servicio CELLSRV

# cellcli -e alter cell shutdown services cellsrv

3. Establecer el “Flash Cache” del “Storage Server” al modo "WriteBack"

# cellcli -e "alter cell flashCacheMode=writeback"

4. Reiniciar el servicio CELLSRV

# cellcli -e alter cell startup services cellsrv

5. Recrear el “Flash Cache”

# cellcli -e create flashcache all

“Deshabilitar Write-Back Flash Cache”:

 

Es posible deshabilitar “Write-Back Flash Cache” en “Diskgroups” que no requieran de esta característica, tales como RECO (Diskgroup utilizado para guardar respaldos). Esto reflejara en beneficios al “Flash Cache” liberando espacio.

CACHINGPOLICY: Puede ser usado para cambiar la política de “Flash Cache” en los “Grid Disks”.

Antes de cambiar la política del “Flash Cache” de valor "default" a "none", asegúrese que no existan datos aún en el “Flash Cache” para el “Grid Disk”.

Para nuevas creaciones de “Grid Disks”:

CellCLI> create griddisk all harddisk prefix=RECO, size=1006,
cachingPolicy="none“

Para los “Grid Disk” que ya hayan sido creados:

CELLCLI>ALTER GRIDDISK grid_disk_name FLUSH
CELLCLI>ALTER GRIDDISK grid_disk_name CACHINGPOLICY="none"

Bajar datos desde el Flash Cache a Disco (Método Manual):

Los datos que no están sincronizados con los “Grid Disks” pueden ser sincronizados manualmente usando la función "FLUSH":

CELLCLI>ALTER GRIDDISK grid_disk_name FLUSH

Se puede utilizar el siguiente comando para revisar el progreso de la actividad:

CELLCLI>LIST GRIDDISK ATTRIBUTES name, flushstatus, flusherr

Restablecer “Flash Cache” al modo “WriteThrough”:

Los siguientes requisitos deben ser satisfechos:

  • Para regresar al modo “WriteThrough”, el “Flash Cache” debe ser descargado a disco previamente.
  • El “Flash Cache” debe ser eliminado y el servicio CELLSRV detenido.
1.	CELLCLI> alter flashcache all flush 
2.	CELLCLI> drop flashcache
CELLCLI> alter cell shutdown services cellsrv 
3.	CELLCLI> alter cell flashCacheMode = WriteThrough 
4.	CELLCLI> alter cell startup services cellsrv

Monitoreo del uso de Flash Cache:

CELLCLI> list metricdefinition attributes name, 
description where name like '.*_DIRTY‘

Descripción de Campos:

CD_BY_FC_DIRTY:       Numero de “bytes” que aun no han sido descargados a disco en un CELL DISK

FC_BY_DIRTY:      Numero de “bytes” que aun no han sido descargados a disco en el “Flash Cache”.

FC_BY_STALE_DIRTY:      Numero de “bytes” que aun no han sido descargados a disco desde “Flash Cache” pero que no pueden ser descargados debido a que los discos “Flash” no son accesibles.

GD_BY_FC_DIRTY:       Numero de “bytes” que no han sido descargados a disco desde “Flash Cache” hacia un “Grid Disk”.

 

Joel es un experto DBA con más de 12 años de experiencia, especializado en bases de datos con especial énfasis en la soluciones de alta disponibilidad (RAC, Data Guard, y otras). Es un conferencista habitual en eventos de Oracle como: OTN LAD TOUR y otros. Consultor Internacional con trabajos en más de 20 países alrededor del mundo. Fue el primer latinoamericano en ser nombrado "Experto OTN" en el año 2003, Oracle ACE año 2004 y actualmente Oracle ACE Director.

Deiby Gómez es un DBA, con experiencia en administración de dominios “WebLogic” e implementaciones de Arquitecturas Orientadas a Servicios (SOA). De forma frecuente es conferencista en diversos eventos Oracle en Guatemala, entre ellos OTN LAD Tour 2013 y otros. Ha brindado consultoría en implementaciones de SOA y Bases de datos en diversas empresas de su país de residencia ( Guatemala ), actualmente es Consultor en Datum S.A. de Guatemala. Deiby es OCP11g y Oracle SOA Implementation Certified Expert.

Yenugula Venkata Ravi Kumar es un DBA con más de 13 años de experiencia, especializado en ambientes de Alta Disponibilidad de Bases de Datos (RAC, Data Guard, entre otras), afinación del rendimiento para Bases de Datos, Migraciones y Respaldos, Oracle Exadata v1/v2/v3, experto en Sistemas operativos como AIX, HP-UX y Linux . Ha participado como conferencista en varios eventos Oracle en la India donde actualmente reside. Obtuvo el título de OCM10g en el año 2009.