Esta mañana temprano, store.exe falló de una forma u otra, lo que requirió reiniciar nuestro servidor Exchange. Volvió a estar en línea sin errores ni problemas, todos los registros de transacciones se reprodujeron exitosamente y todas las tiendas se montaron normalmente. Para mí, fue sólo uno de esos accidentes aleatorios; sin embargo, nuestro consultor sospecha que fue causado por corrupción en una de las tiendas. Quizás tenga razón, ya que tiene mucha más experiencia que yo, pero ese no es el punto.
Para corregir los errores sospechosos, planea ejecutar una desfragmentación ESEUTIL (a través de PerfectDisk) para corregirlos, que, según afirma, también solucionará cualquier error presente.
Por lo que tengo entendido, desfragmentar, verificar y reparar son 3 acciones separadas, y una desfragmentación no implica ningún tipo de verificación de integridad.¿Es esto correcto? ¿Existe algún peligro al ejecutar una desfragmentación directa en una base de datos que podría estar corrupta?
Editar:
Aquí está el primer error en el registro de eventos, que indicó el inicio de los problemas que estábamos teniendo. ¿Alguien sabe qué podría indicar?
Event Type: Error
Event Source: Microsoft Exchange Server
Event Category: None
Event ID: 1000
Date: 11/23/2011
Time: 8:15:47 AM
User: N/A
Computer: SERVER
Description:
Faulting application exsp.dll, version 6.5.7638.1, stamp 430e735b, faulting module kernel32.dll, version 5.2.3790.4480, stamp 49c51f0a, debug? 0, fault address 0x0000bef7.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 41 00 70 00 70 00 6c 00 A.p.p.l.
0008: 69 00 63 00 61 00 74 00 i.c.a.t.
0010: 69 00 6f 00 6e 00 20 00 i.o.n. .
0018: 46 00 61 00 69 00 6c 00 F.a.i.l.
0020: 75 00 72 00 65 00 20 00 u.r.e. .
0028: 20 00 65 00 78 00 73 00 .e.x.s.
0030: 70 00 2e 00 64 00 6c 00 p...d.l.
0038: 6c 00 20 00 36 00 2e 00 l. .6...
0040: 35 00 2e 00 37 00 36 00 5...7.6.
0048: 33 00 38 00 2e 00 31 00 3.8...1.
0050: 20 00 34 00 33 00 30 00 .4.3.0.
0058: 65 00 37 00 33 00 35 00 e.7.3.5.
0060: 62 00 20 00 69 00 6e 00 b. .i.n.
0068: 20 00 6b 00 65 00 72 00 .k.e.r.
0070: 6e 00 65 00 6c 00 33 00 n.e.l.3.
0078: 32 00 2e 00 64 00 6c 00 2...d.l.
0080: 6c 00 20 00 35 00 2e 00 l. .5...
0088: 32 00 2e 00 33 00 37 00 2...3.7.
0090: 39 00 30 00 2e 00 34 00 9.0...4.
0098: 34 00 38 00 30 00 20 00 4.8.0. .
00a0: 34 00 39 00 63 00 35 00 4.9.c.5.
00a8: 31 00 66 00 30 00 61 00 1.f.0.a.
00b0: 20 00 66 00 44 00 65 00 .f.D.e.
00b8: 62 00 75 00 67 00 20 00 b.u.g. .
00c0: 30 00 20 00 61 00 74 00 0. .a.t.
00c8: 20 00 6f 00 66 00 66 00 .o.f.f.
00d0: 73 00 65 00 74 00 20 00 s.e.t. .
00d8: 30 00 30 00 30 00 30 00 0.0.0.0.
00e0: 62 00 65 00 66 00 37 00 b.e.f.7.
00e8: 0d 00 0a 00 ....
Respuesta1
Una desfragmentación sin conexión eseutilfallará si encuentra daños a nivel de página en la base de datos porque. Tendrías que usar la /popción (reparear) para descartar páginas corruptas.
La corrupción de datos a nivel lógico (piense en el daño a los "datos" de la base de datos, no a la "estructura" de la base de datos) no puede repararse mediante eseutil. La isintegherramienta puede encontrar inconsistencias lógicas en la base de datos en versiones de Exchange hasta 2007. En Exchange 2010 isintegfue reemplazado por el new-MailboxRepairRequestcmdlet (Más detalles están disponibles en el blog del equipo de Exchange.).
Dicho todo esto, me preocupa el consejo de su consultor. ¿Está viendo eventos en el registro de eventos de la aplicación de ESE o servicios relacionados con Exchange que indiquen daños en la base de datos? En general, Exchange no "falla aleatoriamente" y un problema con un controlador de hardware o el propio hardware parece ser una causa más probable que un problema con Exchange. Además, dado que los registros se reprodujeron sin problemas, me parece un poco improbable que estés sufriendo daños a nivel de página.
Finalmente, si está tomando corrupción a nivel de página, simplemente limpiar esa corrupción no es una solución. Debe encontrar la causa raíz (hardware defectuoso, etc.) que está causando la corrupción y eliminarla. Hacer cualquier otra cosa solo lo expone a un riesgo continuo.
La desfragmentación fuera de línea no es, por sí sola, un riesgo importante. Debe realizar una copia de seguridad completa inmediatamente después de completar la desfragmentación fuera de línea porque todas las copias de seguridad incrementales y diferenciales anteriores no se pueden restaurar (porque la nueva base de datos es solo eso: una base de datos completamente nueva). Obviamente, su servidor tampoco será accesible para los usuarios durante el período de desfragmentación.
Estaría investigando en detalle lo que sucedió esta mañana y llegaría a una conclusión sobre la causa raíz (o al menos a una hipótesis muy probable) antes de comenzar a gastar dinero en "arreglarlo".
Tuve un caso reciente en el que una máquina con Exchange Server 2003 no tomaba instantáneas de VSS e informó varios errores de JET durante los intentos de realizar copias de seguridad. Opté por iniciar una nueva instalación de Exchange en otra máquina, mover todos los buzones de correo de los usuarios a la nueva máquina, luego eliminar la base de datos problemática en el servidor original y permitir que se creara una nueva. Después de realizar algunas pruebas de estrés y verificar que el servidor original funcionaba correctamente, movimos todos los buzones de nuevo. Preferiría esa estrategia en la situación que estás describiendo (si tuviera suficientes mensajes de registro de eventos que indicaran una "corrupción" real en la base de datos del buzón de correo de la computadora con Exchange Server original).
Editar:
La entrada que publicó anteriormente es una falla en el proveedor de Exchange para Microsoft Search (que genera índices de texto completo de las bases de datos de Exchange). Me interesaría ver más de lo que sucedió después, así como cualquier evento inmediatamente anterior a este en el Registro de eventos del sistema. ¿Tuvo una condición de poco espacio en disco en alguno de los volúmenes de la computadora servidor?
Respuesta2
La desfragmentación de ESEUTIL no está dedicada a la reparación exhaustiva de bases de datos de Exchange. La función de desfragmentación consiste en recuperar espacio libre en la base de datos y optimizar el rendimiento de la base de datos mediante la creación de un nuevo archivo de base de datos compactado.
Mientras ejecuta la desfragmentación, también puede realizar ciertas reparaciones en la base de datos cuando encuentre inconsistencias o problemas. Esta es parte del proceso general de desfragmentación y puede solucionar problemas menores.
Si su base de datos de Exchange Server está dañada, se recomienda ejecutar primero el comando ESEUTIL /mh para verificar el estado completo de su base de datos. Si lo ha encontrado, la base de datos está en estado sucio. Posteriormente, puede utilizar los comandos ESEUTIL /P o ESEUTIL /R según el daño de la base de datos. Asegúrese de haber realizado una copia de seguridad de su base de datos antes de intentar cualquier operación de reparación.
Le aconsejé consultar con el soporte de Microsoft para garantizar los pasos de recuperación adecuados.
Puede consultar estos artículos de Microsoft: