Asserzioni di FRS nel membro primario contenente un numero elevato di file o directory

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.

291165
Questo articolo è stato archiviato. L’articolo, quindi, viene offerto “così come è” e non verrà più aggiornato.
importante : questo articolo contiene informazioni sulla modifica del Registro di sistema. Prima di modificare il Registro di sistema, eseguire una copia di backup e assicurarsi di sapere come ripristinarlo in caso di problemi. Per ulteriori informazioni su come eseguire il backup, ripristinare e modificare il Registro di sistema, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito:
256986Descrizione del Registro di sistema di Microsoft Windows
Sintomi
Il servizio Replica File (FRS) è un motore di replica multimaster multithread che sostituisce il servizio LMREPL in Microsoft Windows NT 3.x e 4.0. I controller di dominio Windows 2000 e server è possibile utilizzare FRS per replicare criteri di sistema e account di accesso gli script per Windows 2000 e i client di livello inferiore che risiedono in un volume di sistema.

FRS è in può anche di replicare contenuto tra server Windows 2000 che ospitano le directory principali DFS di samefault a tolleranza d ' o repliche di nodi figlio.

In questo articolo viene descritto un errore in cui il computer membro di Windows 2000 o controller di domini che sono contrassegnati nel Registro di sistema o file system distribuito (Dfsgui.msc) snap-in come "primario" per un set di repliche FRS che contiene centinaia di migliaia di file:
  1. Non tutti i file nella struttura della replica di magazzino.
  2. Rileva un errore journal_wrap solitamente si verifica quando il servizio Replica file disattivato per un periodo di tempo prolungato.
  3. Vengono registrati i seguenti eventi nel Registro di debug di FRS:
    <DbsInitOneReplicaSet:          1428: 11268: S1: 15:45:38> ++ WStatus: 26-??? -- CMD_JOURNAL_INIT_ONE_RS failed<JrnlSetReplicaState:           1428:  5787: S4: 15:45:38> :S: Replica (0)REPLICATEST state change from INITIALIZING to ERROR						
Cause
Quando un set di repliche FRS viene creato o reinizializzato, il comando "Set principale" nello strumento di amministrazione DFS (o il Registro di sistema equivalente) viene utilizzato per definire il computer in cui file e la struttura di directory verrà utilizzato inizialmente per popolare un set di repliche FRS.

Prima per la replica, FRS membro primario inventari tutti i file le directory replicate (struttura di replica) nel tentativo di popolare il IDTABLE (un elenco di tutti i file e directory in una struttura di replica). Questa "analisi IDTABLE" deve essere completata prima del membro primario inviare ordini di cambiamento o file dell'area di gestione temporanea di partner downstream vengono generati come parte del processo di replica.

Il diario USN è un registro di dimensioni fisse che registra tutte le modifiche che hanno luogo su partizioni NTFS 5.0 formattato. NTFRS controlla il file di diario USN NTFS per i file chiusi nelle directory di FRS replicati, purché FRS è in esecuzione.

Gli errori di ritorno a capo giornale di registrazione si verificano se un numero sufficiente di modifiche luogo mentre il servizio FRS esegue la scansione IDTABLE tale l'USN di ultima modifica FRS registrata nel database FRS non è più presente nel diario USN. Poiché FRS non è più possibile richiedono il diario USN come origine per le modifiche nella relativa struttura di replica, FRS asserzioni in uno stato a capo automatico di giornale di registrazione. Per eseguire in caso contrario potrebbe causare un'inconsistenza dei dati.
Risoluzione
Sono disponibili per risolvere il problema due opzioni:
  • Aumentare le dimensioni del diario USN NTFRS sul volume di contenuto che gli host di FRS replicati.
  • Ridurre il numero di file che si trovano nella struttura della replica finché non viene completata la fase di inizializzazione.
Status
Microsoft ha confermato che questo problema riguarda i prodotti Microsoft elencati all'inizio di questo articolo.
Informazioni
avviso : se si utilizza Editor del Registro di sistema in modo non corretto, si potrebbero provocare problemi gravi che potrebbero richiedere la reinstallazione del sistema operativo. Microsoft non garantisce la che è possibile risolvere i problemi derivanti dall'errato utilizzo dell'editor del Registro di sistema. Utilizzare Editor del Registro di sistema a proprio rischio.

Aumentare le dimensioni del diario USN e, di conseguenza il numero di modifiche può contenere prima che il giornale di registrazione "include" riduce le probabilità che il diario USN andrà a capo. È possibile modificare le dimensioni del diario USN, impostando la quantità di megabyte (MB) nella seguente chiave del Registro di sistema:
HKLM\System\CCS\Services\NTFRS\Parameters\ dimensioni del diario NTFS in MB (REG_DWORD)
Intervallo valido è compreso da 8 a 128 MB con un valore predefinito di 32 MB. Questa impostazione si applica a tutti i volumi host un FRS struttura della replica. Aumenta dimensioni del diario USN verificarsi dopo interrompere e riavviare il servizio NTFRS. Diminuisce dimensioni del diario USN possono avvenire solo riformattando tutti i volumi che contengono contenuto replicato da FRS.

È possibile prevedere il numero di modifiche che può contenere un determinato file diario USN con la formula seguente:
<dimensione giornale di registrazione > / ((60 byte + (lunghezza del nome file)) * 2)
Deriva il "2" nella formula precedente dalle voci del diario 2 per ogni modifica di file: 1 per aprire e 1 per la chiusura. Dividere la dimensione di giornale di registrazione per la dimensione di ogni modifica apportata a determinare il numero approssimativo di modifiche che possono verificarsi prima l'errore di ritorno a capo automatico del giornale di registrazione si verifica. Esegue supponendo che i nomi di 8.3 file, il mapping a circa 200.000 file o directory per un file di giornale di registrazione di 32 MB. Il numero di modifiche sarebbe minore se i nomi di file lunghi vengono utilizzati.
NTFRS FRS sysvol

Avviso: questo articolo è stato tradotto automaticamente

Proprietà

ID articolo: 291165 - Ultima revisione: 01/24/2014 03:28:44 - Revisione: 2.3

  • Microsoft Windows 2000 Server
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • kbnosurvey kbarchive kbmt kbenv kberrmsg kbprb KB291165 KbMtit
Feedback