Al momento sei offline in attesa che la connessione Internet venga ristabilita

INF: Modalità bypass (emergenze) e DUMP TRANSACTION WITH NO_LOG

Il presente articolo è stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell’utente. Tuttavia, un articolo tradotto in modo automatico non è sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, più o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non è la sua. Microsoft non è responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell’utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.

Clicca qui per visualizzare la versione originale in inglese dell’articolo: 165918
Questo articolo è stato archiviato. L’articolo, quindi, viene offerto “così come è” e non verrà più aggiornato.
Sommario
In situazioni poco frequenti, un database può essere contrassegnato come sospetto a causa di errore ripristino all'avvio. In genere, ciò impedisce chiunque di accedere ai dati. Tuttavia, è possibile impostare lo stato di un database sospetto "modalità bypass" (denominata anche "modalità di emergenza") e SELECT manualmente o di utilizzare BCP (Bulk Copy Program) per copiare i dati. Mentre non è possibile eseguire le modifiche di dati normali in modalità di ignorare, è possibile eseguire il DUMP TRANSACTION WITH NO_LOG. Si noti che questa operazione Ignora modalità non sono supportato e un'operazione potenzialmente pericolosa.

Per motivi analoghi, se ripristino avvio richiede molto tempo, si dovrebbe non interrompere, impostare il database in modalità bypass e quindi eseguire DUMP TRANSACTION WITH NO_LOG.
Informazioni
Tutte le azioni intraprese da DUMP TRANSACTION in genere vengono registrate, pertanto è recuperabile e abortable. Tuttavia, lo spazio del log viene consumato tramite il comando DUMP stesso. Se il log delle transazioni è così completo esistenza di spazio insufficiente per eseguire un DUMP TRANSACTION registrati, è possibile che l'opzione WITH NO_LOG troncare il Registro di transazione con nessuna registrazione.

DUMP TRANSACTION WITH NO_LOG è relativamente sicuro in condizioni normali. Il server richiede misure per garantire che ripristino avrà esito positivo anche se il server durante l'operazione.

In alcune situazioni ripristino automatico, denominato anche ripristino di avvio, potrebbe non riuscire, contrassegnare un database come sospetto. Ripristino non riesce per un motivo specifico. È molto importante notare il messaggio di log degli errori che inizialmente ha provocato ripristino ha esito negativo, perché potrebbe essere utile per diagnosticare la causa.

"Ripristino" è il processo di rendere il database coerente da un ripristino o annullamento di tutte le transazioni sono avviate dopo o non salvate al momento del checkpoint ultima. Questo processo si basa sulla natura write-ahead del log delle transazioni (tutte le pagine modificate vengono scritti nel registro prima di essere scritte al database). Ripristino costituita dalla lettura ogni record di log, confrontare il timestamp per il timestamp della corrispondente pagina di database e annullare la modifica (nel caso di una transazione senza commit) o un ripristino la modifica (nel caso di una transazione di cui è stato eseguito il commit). Dopo aver notare il messaggio di log degli errori che causa il ripristino di un errore, provare a impostare lo stato del database al normale e riavviare SQL Server per verificare se la seconda volta riuscita del ripristino. È possibile modificare lo stato del database per mezzo della procedura sp_resetstatus memorizzati. Questo è una stored procedure supplementare, che è possibile installare dallo script di Instsupl.sql nella directory Mssql\Install. Per ulteriori informazioni, vedere "Reimpostazione di Suspect Status" nella documentazione in linea.

Se ha è ancora esito negativo ripristino, si noti il messaggio di errore e contattare il provider del servizio di supporto. È inoltre necessario verificare la disponibilità dell'ultimo backup valido del database, poiché potrebbe essere necessario. Tuttavia la maggior parte dei dati nel database è spesso ancora disponibile, sebbene incoerente in modo transazionale (e fisicamente). Puoi accedere a questi dati impostando lo stato del database per ignorare, o modalità di emergenza. Impostazione sysdatabases.status compreso tra-32768 e per un database SQL 6.5 e di 32768 per un database di SQL 7.0, ciò avviene dopo l'accensione "consentire gli aggiornamenti". Ad esempio, è possibile utilizzare il seguente comando per un database di SQL 6.5:
   UPDATE SYSDATABASES SET STATUS=-32768 WHERE NAME='DBNAME'				

Dopo questa operazione, è possibile specificare il database e SELECT i dati o utilizzare BCP per ottenere il. Gli errori riscontrabili durante questa operazione, ma nella maggior parte dei casi maggior parte dei dati può essere recuperato.

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 165918 - Ultima revisione: 12/04/2015 16:39:56 - Revisione: 3.1

Microsoft SQL Server 4.21a Standard Edition, Microsoft SQL Server 6.0 Standard Edition, Microsoft SQL Server 6.5 Standard Edition

  • kbnosurvey kbarchive kbmt kbinfo kbusage KB165918 KbMtit
Feedback