Exchange, stubbing y recuperación de espacio de base de datos
Artículo original publicado el martes, 28 de agosto de 2012
Exchange 2010 SP2 RU1 contenía una corrección de un problema relacionado con la reclamación de espacio de base de datos. Parece haber cierta confusión en torno a este problema, de modo que me gustaría explicarlo, explicar su corrección y discutir las expectativas que existen cuando el uso de productos de terceros reemplaza elementos de la base de datos (el stubbing es el proceso por el que un mensaje se reemplaza con un objeto puntero y la versión original se almacena en un repositorio externo).
El error y la corrección
En Exchange 2010 se identificó que no se recuperaba espacio de base de datos en varios escenarios en los que se eliminan elementos permanentemente (cuando el elemento se ha purgado del almacén). Esto incluye escenarios de archivado en los que los elementos se eliminan en masa según la fecha, escenarios de stubbing en los que se eliminan datos adjuntos y otros escenarios como buzones de diario y replicación de carpetas públicas. Este problema afectaba a gran cantidad de clientes y radicaba en el modo en que funcionaba la eliminación de elementos.
Exchange 2010 normalmente tratará de limpiar la fila de un elemento eliminado algunos minutos después de que se haya eliminado permanentemente el elemento. En cualquier caso, la limpieza producirá un error si aún existen referencias abiertas al elemento. Así, algunos posibles escenarios en los que la limpieza produciría un error son: que la indización de contenido esté indizando el mensaje, que un cliente independiente esté leyendo el mensaje, etc. Si existen referencias abiertas, la limpieza produce un error. Si la limpieza ha producido un error previo a la corrección, ese espacio se perdió eficazmente y no se pudo recuperar sin mover el buzón.
Parece ser que las referencias pendientes de mensajes eliminados son particularmente habituales en buzones de correo de registro en diario o cuando se utiliza software de archivado de terceros, de modo que la inmensa mayoría de clientes que se encontraron con este error lo asociaron a uno de esos dos escenarios. Pero técnicamente, cualquier cliente podría retener una referencia abierta e impedir que se limpie un elemento.
La corrección incluida en SP2 RU1 soluciona el problema agregando un mecanismo de reintento de limpieza. Si la limpieza produce un error porque algo continúa teniendo una referencia abierta, el almacén volverá a intentarlo periódicamente hasta que lo consiga.
¿Se ha conseguido corregir así el stubbing?
Stubbing hace referencia a un proceso en el que un producto de archivado de terceros toma un mensaje grande y lo convierte en un elemento más pequeño o stub. Esto se suele hacer eliminando los datos adjuntos y modificando el cuerpo del mensaje para disminuir su tamaño.
En la medida en que el stubbing elimina datos adjuntos, sería posible que se viese afectado por este error porque los datos adjuntos eliminados podrían dar un error de limpieza causado por referencias abiertas. Pero, aparte de eso, el error nunca ha estado realmente relacionado con el stubbing.
¿Qué pasa si el stubbing no me proporciona todo el espacio que esperaba?
El Almacén de información de Exchange ha cambiado mucho a lo largo de los años, pero ya en las versiones de Exchange 2003 y 2007 el stubbing causaba que el tamaño de las bases de datos terminase siendo bastante mayor al que se podía esperar al agregar tamaños de buzón. Esto estaba motivado principalmente por dos tipos de sobrecarga.
El primer tipo de sobrecarga son las propiedades que sencillamente no recuentan para el tamaño del mensaje. Cuando se consulta el tamaño de un mensaje en Outlook, el tamaño que se ve no es el total de todos los datos que Exchange almacena para ese mensaje. Se almacenan algunas propiedades que no se recuentan y que no se reflejan en el tamaño del mensaje. Pueden ser propiedades públicamente documentadas, como PR_URL_NAME u otras propiedades internas a las que no pueden obtener acceso los clientes.
El segundo tipo de sobrecarga es la fragmentación de páginas. El tamaño de página de la base de datos ha cambiado a lo largo de los años, de 4k en Exchange 2003 a 8k en Exchange 2007 y a 32k en Exchange 2010. Cada registro de la base de datos tiene que organizarse en estas páginas y, dependiendo de la eficiencia, sobrará algo de espacio en la página. En esto consiste la fragmentación de páginas, que produce espacio vacío que no puede recuperarse con el mantenimiento de la base de datos. Los tamaños de página mayores de versiones más recientes de Exchange facilitan la organización de varios elementos pequeños en una sola página, lo que resulta en menos fragmentación (aunque siempre exista alguna).
Por lo general, la cantidad de sobrecarga no difiere demasiado entre mensajes: un mensaje pequeño tendrá la misma sobrecarga que uno grande. Por este motivo, cuando rellena una base de datos con elementos pequeños, la sobrecarga resulta mucho más visible.
Tomemos como ejemplo un escenario donde ha rellenado una base de datos con elementos de 1MB de tamaño y que todos ellos tienen 1k de sobrecarga. Esto significa que la base de datos tiene aproximadamente 0,09 % de sobrecarga. Ahora supongamos que reemplaza todos los elementos de la base de datos y reduce su tamaño a 4k. De repente, 1k de sobrecarga es mucho más perceptible y ocupa el 25 % de la base de datos. Yo una vez creé una base de datos de Exchange 2003 que tenía una sobrecarga del 70 % por rellenarla con elementos y reemplazarlos todos.
¿Y Exchange 2010?
En Exchange 2010 existe un factor adicional que podría afectar a la recuperación de espacio del stubbing y ahí radica el cambio del diseño de la base de datos.
Exchange 2010 supuso grandes avances en la reducción de la E/S por segundo de las bases de datos. En su mayor parte esto consistía en deshacerse del antiguo proceso de desfragmentación en línea que se arremolinaba violentamente cada noche en la base de datos y cambiaba las cosas de sitio para optimizar el espacio. En Exchange 2010 se presta mucha más atención al almacenamiento del contenido del buzón en páginas contiguas para reducir la E/S. Dicho de otro modo, Exchange 2010 no estaba orientado a recuperar espacio contundentemente cuando un mensaje disminuía repentinamente de tamaño. Se trata de un escenario minimizado en la arquitectura de mejora de E/S. Para más información sobre cambios en el mantenimiento consulte Mantenimiento de datos en Exchange 2010.
¿Quiere esto decir que con el stubbing no ahorrará espacio? No necesariamente. Los productos de stubbing suelen eliminar datos adjuntos, así que sería de esperar que se liberase espacio. Además, a pesar de no estar diseñado para ello, se ha dado el caso de que Exchange 2010 liberase espacio incluso al reemplazar elementos sin datos adjuntos.
De todos modos, como esto no forma parte del diseño de Exchange 2010 no podemos decirle qué esperar en cuanto al espacio que se liberará con el archivado de reemplazo. Cualquier expectativa sobre este tema debería basarse en sus propias pruebas o en datos proporcionados por el proveedor de software de archivado.
Dicho de otro modo: no podemos publicar notificaciones sobre recuperación de espacio cuando se modifica un elemento para disminuir el tamaño de sus propiedades. Si modificar un elemento para disminuir su tamaño no libera ningún espacio en absoluto, puede que esto responda al diseño de Exchange 2010. Como siempre, si se comprueba que Exchange funciona así por diseño, la investigación de compatibilidad de problemas de espacio en la base de datos al utilizar productos de terceros puede motivar que le remitamos al servicio técnico del tercero en cuestión.
Conclusión
Exchange 2010 SP2 RU1 incluyó una corrección que facilitará a los clientes cualquier tipo de tareas de archivado, stubbing u otras, porque es fiable con la limpieza de elementos eliminados permanentemente. En cualquier caso, usted y su proveedor de software de archivado tienen que validar cualquier ahorro de espacio en disco resultante de un proceso de stubbing. Al aprovisionar su almacenamiento, sugerimos que siga la guía y las herramientas publicadas (que incluye el aprovechamiento de buzones grandes para no tener que recurrir a soluciones de archivado de terceros) para asegurarse de que dispone de espacio suficiente para los datos de Exchange.
Bill Long
Esta entrada de blog es una traducción. Puede consultar el artículo original en Exchange, Stubbing, and Database Space Reclamation