Si hallas alguna incompatibilidad en tu código o trabajo, recuerda probar siempre en un entorno de testing antes añadir el código al proyecto final.
Solución:
No tiene que ser elegante / preocupado o asustado cuando reinicia el servidor SQL.
Solo asegúrese de no tener transacciones de larga duración. Lo mejor es reiniciar el servidor SQL usando la consola o el comando de apagado durante un período de actividad mínima / baja, también llamado ventana de mantenimiento para minimizar el impacto en su negocio.
Si tiene alguna configuración de DR y no quiere estar inactivo, lo mejor es realizar una conmutación por error y luego reiniciar el nodo pasivo o secundario.
El apagado limpio de SQL Server se produce en los siguientes escenarios:
- Detenga el servidor SQL usando la consola de Servicios.
- Apagando su servidor
- ejecutando el comando SHUTDOWN en SSMS
En todas las situaciones, el servidor SQL cierra limpiamente todas sus bases de datos y luego termina el servicio, lo que implica comprometer o revertir todas las transacciones, escribir todas las páginas sucias en el disco y luego escribir una entrada en el registro de transacciones.
Apagado incorrecto del servidor SQL:
- apagar con nowait
- tirando del cable de alimentación de su servidor (si tiene acceso).
- asesinato sqlserver.exe desde el administrador de tareas
- Dirve falla en el que residen los binarios del servidor SQL, exe, bases de datos del sistema o falla de la unidad del sistema de Windows … generalmente C: unidad.
- sobrecalentamiento del servidor que hace que se apague (¡raramente debería suceder!)
SQL Server siempre intentará hacer un apagado limpio … a menos que haga algo incorrecto como se indicó anteriormente.
Algunos enlaces de lectura realmente buenos sobre lo que sucede detrás de escena durante la fase de recuperación:
- Comprensión del registro y la recuperación en SQL Server
- Comprender cómo funcionan la restauración y la recuperación de copias de seguridad en SQL Server
- Descripción general simple del proceso de recuperación de SQL Server
Todo esto se detalla exhaustivamente en esta página.
- Iniciar, detener, pausar, reanudar y reiniciar los servicios de SQL Server
Siendo que tu pregunta específicamente pide “¿Hay alguno recomendado por Microsoft“Me inclino a pensar que es contraproducente tener esta discusión aquí. El artículo detalla el proceso a través de
- Usando cualquiera
- línea de comando
- Potencia Shell,
- SQL Server Management Studio (GUI)
- Para 2008, 2012, 2014, 2016.
- Para el bien
- Motor de base de datos
- o, agente
Si esos pasos son satisfactorios o no, sería mi opinión, que usted no quiere. Por lo tanto, la respuesta correcta siempre estará más actualizada allí.
Detener el servicio antes de apagarlo
¿Es necesario o recomendado hacerlo antes de apagar un servidor que está ejecutando servicios SQL?
No, no es necesario. Cuando el kernel de Windows envía la señal de apagado a SQL Server, lo hará de una manera segura y el sistema esperará a que se complete. Hablando en general, cualquier cosa construida con la capacidad de apagarse de manera segura no tiene que apagarse manualmente, y es lógico que todas las aplicaciones de Microsoft sigan su propia API y procedimientos vinculados a la PRESHUTDOWN, o SHUTDOWN etapas. De los documentos en adelante PRESHUTDOWN, que supongo que están usando,
Notifica a un servicio que el sistema se cerrará. Los servicios que necesitan tiempo adicional para realizar tareas de limpieza más allá de la estricta restricción de tiempo al apagar el sistema pueden usar esta notificación. El administrador de control de servicios envía esta notificación a las aplicaciones que se han registrado antes de enviar una
SERVICE_CONTROL_SHUTDOWNnotificación a las aplicaciones que se han registrado para esa notificación.Un servicio que maneja esta notificación bloquea el apagado del sistema hasta que el servicio se detiene o el intervalo de tiempo de espera previo al apagado especificado a través de
SERVICE_PRESHUTDOWN_INFOexpira. Debido a que esto afecta la experiencia del usuario, los servicios deben usar esta función solo si es absolutamente necesario para evitar la pérdida de datos o un tiempo de recuperación significativo en el próximo inicio del sistema.
Como puede ser necesario, supongo que así es como funciona SQL Server.
No exactamente cuando se trata de apagar y prevenir la corrupción de la base de datos. MS SQL Server es un producto muy maduro y las probabilidades de causar un problema de corrupción con un simple ‘apagado’ serían un escenario de borde. Es mucho más probable que cause daños si no ejecuta CHECK DB o si tiene configurada la validación de suma de comprobación en su base de datos.
Quizás tener herramientas externas que toquen directamente los archivos MDF / NDF / LDF podría causar problemas, como intentar “mover” los archivos entre cierres o hacer que algún software intente bloquear los archivos durante el cierre. He visto que la agrupación en clústeres de Windows se estropea cuando un disco que aloja archivos de base de datos está lleno, pero no causa específicamente una ‘corrupción de la base de datos’.
Si desea ayudar a garantizar un apagado o una conmutación por error sin problemas, puede ejecutar un punto de control, asegúrese de ejecutar DBCC CHECKDB con frecuencia (al menos el tiempo suficiente para poder recuperar datos corruptos de una copia de seguridad) y verificar que las dependencias externas estén cuidado como el espejo.
Sin embargo, si algún experto TIENE otras ‘mejores prácticas’, me encantaría escucharlas, pero revisando los blogs y los recursos en línea durante los últimos años, no he visto mucho en la corrupción de datos y un simple ‘apagado / reinicio’.
Puedes proteger nuestro trabajo mostrando un comentario y dejando una puntuación te damos la bienvenida.