Tamaño límite en el mailbox - Asegura tamaño máximo de la base de datos?
Por Daniel Seveso
Limitando el tamaño de los buzones
Una práctica usual de los administradores de Exchange es limitar el tamaño de los buzones de usuario. Por supuesto esta práctica es no solo válida, sino que recomendada para limitar el uso de recursos en nuestros servidores. Pero que pasa cuando esta práctica se lleva a un extremo?
Supongamos que definimos un límite de tamaño por buzón demasiado pequeño (por ejemplo 20MB), y en base a este límite consideramos que el número de usuarios que podrían definirse en esta base de datos es 500. Perfecto.... entonces calculo el tamaño del disco que va a ser 500 x 20Mb más alguna precaución que leí por ahí para la retención, reglas, conversión de mensajes, etc.... y obtengo como resultado que necesito un disco de aproximadamente 20 Gb. Para no quedarme corto, decido darle un margen de un 50%. Así que compro uno de 30Gb.
Cuando ponemos a funcionar una configuración de estas características en producción, lo más probable es que los usuarios opten por una configuración de entrega de mensajes en carpetas personales (PSTs), la cual les permitirá superar los restrictivos límites impuestos por el administrador.
¿Qué sucede con el tamaño de la base de datos?
La base de datos de Exchange procesa todas las transacciones de los usuarios que están definidos en ella, por lo que, cuando un usuario recibe un mensaje con un archivo adjunto de 10Mb, se generan transacciones correspondientes al procesamiento de este mensaje (dos o tres logs de transacciones) y la base de datos va a aumentar su tamaño en 10Mb aproximadamente. Si el usuario que recibe el mensaje tiene configurado la entrega a PST, el mensaje será movido desde la base de datos al PST.
El tamaño que ocupaba este mensaje es considerado por el store como un mensaje borrado, por lo que está sujeto al período de retención de mensajes. Sin embargo, este no contará contra el límite del usuario, ya que los mensajes borrados no cuentan en la quota "tamaño de buzón". En otras palabras, el usuario aún tiene 20Mb disponibles en su buzón cuando ya provocó 10Mb de incremento en el tamaño de la base de datos.
Multipliquemos mentalmente el comportamiento de este usuario, por la cantidad potencial de veces que puede ocurrir en un día, por el período de retención de la base de datos por defecto que es 7 días, por el número de usuarios (500) y seguramente se darán cuenta a donde apunto con todo esto...
Cuando consultamos en el Exchange System Manager por los tamaños de los buzones en esta base de datos, verás que hay una enorme diferencia entre el tamaño de los archivos de base de datos y la suma de los tamaños de los buzones, debido a que el procesamiento de mensajes por parte del Information Store es mucho mayor que lo establecen los límites de tamaño de la base.
Otros factores que influyen a favor de este comportamiento
Los archivos que conforman la base de datos de Exchange (.edb y .stm en Exchange 2003) nunca disminuye su tamaño físico excepto luego de una defragmentación offline (corriendo ESEUTIL / D). Durante la defragmentación online, (que ese la que ocurre diariamente), se libera el espacio de utilización temporal e ítems retenidos que han expirado generándose lo que se llama "espacio en blanco" en la base de datos, el cual será ocupado por nuevas transacciones al día siguiente.
Esto hace que inclusive luego de expirado el período de retención de mensajes, los archivos de la base de datos conservará su máximo tamaño.
Para probar este punto puedes realizar la siguiente prueba
Crea una base de datos en blanco con un único usuario. Configura un perfil de usuario MAPI con entrega a PST. Envía al mismo usuario varios mensajes con un adjunto (de 6 MB por ejemplo), y nota como luego de cada mensaje, la base de datos crecerá en proporción a la información que recibe y no a la que realmente reporta en el "mailbox size" del usuario en el Exchange System Manager.
Si desmontas la base de datos y corres un ESEUTIL /MS <priv1.edb> para ver la distribución de espacio, verás algo parecido a esto:
******************************** SPACE DUMP ***********************************
Name Type ObjidFDP PgnoFDP PriExt Owned Available
===============================================================================
C:\Program Files\Exchsr Db 1 1 256-m 11776 122
<SLV Avail Map> SLV 6 33 32-m 32 29
<SLV Owner Map> SLV 7 65 32-m 48 12
...
1-24 Tbl 63 257 2-m 10970 0
<Long Values> LV 133 654 1-m 10898 3
....
Directory of C:\Program Files\Exchsrvr\MDBDATA
02/06/2009 08:04 PM 48,242,688 priv1.edb
1 File(s) 48,242,688 bytes
El valor Owned en la primera línea es el valor en páginas (4Kb) de la información de la base de datos (Type Db). Si multiplicamos el valor 11776 * 4Kb nos dá aproximadamente el tamaño físico de la base que es ~48Mb. Como pueden ver, 10970 páginas de las 11776 totales se encuentran en la tabla 1-24 que es la tabla de attachments.
Si dejas pasar el período de retención de ítems y el proceso de mantenimiento online, verás que luego del online defrag la composición de tamaño cambia de la siguiente forma (en este ejemplo se envió un mensaje adicional de 6Mb luego del ejemplo anterior):
******************************** SPACE DUMP ***********************************
Name Type ObjidFDP PgnoFDP PriExt Owned Available
===============================================================================
C:\Program Files\Exchsr Db 1 1 256-m 13312 12480
<SLV Avail Map> SLV 6 33 32-m 32 29
<SLV Owner Map> SLV 7 65 32-m 48 12
...
1-24 Tbl 63 257 2-m 146 28
<Long Values> LV 133 654 1-m 47 32
...
Esto indica que se liberó el espacio que ocupaban estos mensaje en la tabla de attachments convirtiéndolo en "espacio en blanco" (Available) para ser reutilizado por nuevas transacciones.
Sin embargo, el tamaño del archivo de nuestra base sigue reflejando el número de páginas en la columna Owned de la base de datos (Type Db).
Directory of C:\Program Files\Exchsrvr\MDBDATA
02/06/2009 08:50 PM 54,534,144 priv1.edb
1 File(s) 54,534,144 bytes
0 Dir(s) 60,711,231,488 bytes free
La conclusión que podemos sacar, es que aunque configuremos este usuario con un límite de 10Mb en su mailbox, terminamos con una base de ~54Mb. Por lo tanto, si volvemos a la pregunta del título, claramente limitar el tamaño del buzón no asegura un tamaño máximo de la base de datos... especialmente cuando el límite es pequeño.