INF: Modo de paso (emergencia) y DUMP TRANSACTION WITH NO_LOG

Seleccione idioma Seleccione idioma
Id. de artículo: 165918 - Ver los productos a los que se aplica este artículo
Expandir todo | Contraer todo

Resumen

En situaciones poco frecuentes, una base de datos puede marcarse SUSPECT debido a un error de recuperación en tiempo de inicio. Normalmente, esto impide que cualquiera acceso a los datos. Sin embargo, es posible establecer el estado de una base de datos SOSPECHOSA "Omitir modo" (también denominado "modo de emergencia") y SELECT o utilizar el BCP (programa de copia de masiva) para copiar los datos de manualmente. Mientras no se puede hacer modificaciones de datos normal en omiten modo, es posible ejecutar DUMP TRANSACTION WITH NO_LOG. Observe que al realizar esta operación, omitir el modo no es compatible y es una operación potencialmente peligrosa.

Por motivos similares, si la recuperación de inicio tarda mucho tiempo, debería no anularlo, establecen la base de datos en modo de omisión y a continuación, realice DUMP TRANSACTION WITH NO_LOG.

Más información

Normalmente se registran todas las acciones realizadas por DUMP TRANSACTION, por lo que es recuperable y abortable. Sin embargo, se consume espacio de registro en el propio comando DUMP. Si el registro de transacciones es tan completo que existe espacio suficiente para realizar un registrados DUMP TRANSACTION, la opción WITH NO_LOG puede truncar el registro de transacciones con no.

DUMP TRANSACTION WITH NO_LOG es relativamente seguro en condiciones normales. El servidor toma medidas para garantizar que la recuperación funcionará correctamente incluso si el servidor falla durante esta operación.

En raras circunstancias puede fallar la recuperación automática (también denominada recuperación de inicio), marca SUSPECT de una base de datos. Recuperación falla por un motivo específico. Es muy importante anotar el mensaje de registro de errores que provocó inicialmente la recuperación falla, porque puede ayudar a diagnosticar la causa.

"Recuperación" es el proceso de hacer que la base de datos no confirmados el momento de la última punto de control o coherente por todas las transacciones que estaban cualquiera iniciar después de deshacer o rehacer. Este proceso depende de la naturaleza de escritura anticipada del registro de transacciones (todas las páginas modificadas se escriben en el registro antes de que se escriben en la base de datos). Recuperación consiste en leer cada registro del sistema, comparar su marca de hora a la marca de hora de la página de base de datos correspondiente y deshacer el cambio (en el caso de una transacción no confirmada) o rehacer el cambio (en el caso de una transacción confirmada). Después de anotar el mensaje de registro de errores que está causando la recuperación de errores, intente establecer el estado de la base de datos NORMAL y reinicie SQL Server para ver si recuperación se realiza correctamente la segunda vez. Puede cambiar el estado de la base de datos por medio del procedimiento sp_resetstatus almacenados. Esto es un procedimiento almacenado complementario que se puede instalar desde la secuencia de comandos Instsupl.SQL en el directorio Mssql\Install. Para obtener más información, consulte "Restablecer el estado de sospecha" en la documentación en pantalla.

Si sigue sin funcionar recuperación, tenga en cuenta la mensaje de error y póngase en contacto con su proveedor principal de soporte técnico. También debe comprobar la disponibilidad de la última copia de seguridad buena base de datos, porque puede ser necesario. Sin embargo, muchos de los datos en la base de datos a menudo todavía está disponible, aunque incoherente transaccionalmente (y físicamente). Puede obtener acceso a este tipo de datos estableciendo el estado de la base de datos para omitir o modo de emergencia. Para ello, configuración sysdatabases.status entre-32768 y para una base de datos SQL 6.5 a 32768 para una base de datos SQL 7.0, después de activar "Permitir actualizaciones". Por ejemplo, utilice el comando siguiente para una base de datos SQL 6.5:
   UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'
				

Después de hacer esto, puede especificar la base de datos y SELECT los datos o utilizar BCP para conseguir que. Puede encontrar errores al hacerlo, pero en la mayoría de los casos muchos de los datos se pueden recuperar.

Propiedades

Id. de artículo: 165918 - Última revisión: martes, 22 de febrero de 2005 - Versión: 3.1
La información de este artículo se refiere a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palabras clave: 
kbmt kbinfo kbusage KB165918 KbMtes
Traducción automática
IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.
Haga clic aquí para ver el artículo original (en inglés): 165918
Renuncia a responsabilidad de los contenidos de la KB sobre productos a los que ya no se ofrece asistencia alguna
El presente artículo se escribió para productos para los que Microsoft ya no ofrece soporte técnico. Por tanto, el presente artículo se ofrece "tal cual" y no será actualizado.

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com