FIX: Sincronizare lentă atunci când discurilor au dimensiuni de sector diferite pentru fișierele jurnal primare și secundare dublură în SQL Server AG și Logshipping medii

IMPORTANT: Acest articol este tradus cu ajutorul software-ului Microsoft de traducere automată și poate fi corectat prin intermediul tehnologiei Community Translation Framework (CTF). Microsoft oferă articole traduse automat, post-editate de comunitate și articole traduse de oameni, pentru a permite accesul la toate articolele din Baza noastră de cunoștințe în mai multe limbi. Articolele traduse automat și post-editate pot conține greșeli de vocabular, sintaxă și/sau gramatică. Microsoft nu este responsabil de inexactitățile, erorile sau daunele cauzate de traducerea greșită a conținutului sau de utilizarea acestuia de către clienți. Găsiți mai multe informații despre traducerea în colaborare la http://support.microsoft.com/gp/machine-translation-corrections/ro.

Faceți clic aici pentru a vizualiza versiunea în limba engleză a acestui articol: 3009974
Înştiinţare
Notă După ce Aplicați această remediere rapidă, trebuie să activați semnalizatorul de urmărire 1800 pe toate serverele de a face această remediere rapidă funcționează corect.
Simptome
Să luăm în considerare următorul scenariu:
  • Activați caracteristica grupuri de disponibilitate cu AlwaysOn sau Logshipping în Microsoft SQL Server 2012 sau SQL Server 2014.
  • Discurile care stocați fișierele de jurnal de reproduceri primare și secundare într-un grup de disponibilitate AlwaysOn (AG) au dimensiuni de sector diferite. Sau în medii Logshipping, discurile că depozitul Jurnalul fişiere pentru Logshipping principală fermă de servere și Logshipping secundare au dimensiuni de sector diferite. De exemplu:
    • Fișierul jurnal replică principală se află pe un disc care are o dimensiune de sector de 512 octeți. Cu toate acestea, fișierul jurnal secundară replică se află pe un disc care are dimensiunea sectorului de 4 kiloocteți (KO).
    • Fișierul jurnal replică principală se află pe un sistem local local care are o dimensiune de sector de 512 octeți. Cu toate acestea, replică secundară se află pe un disc Windows Azure Storage care are dimensiunea sectorului de 4 kiloocteți (KO).
În acest scenariu, următorul mesaj de eroare este înregistrat în Jurnalul de erori de Server SQL:

Au existat X nealiniate log IOs ce necesare care se încadrează înapoi la sincron IO. IO curentă este fișier...

În plus, AG sau Logshipping sincronizare se execută foarte lent din cauza i sincron. Dacă dublura secundară este în Windows Azure Storage, durează mult mai mult decât se așteaptă pentru a termina procesul de sincronizare.

Notă Această problemă apare când utilizați ambele unități noi care au o dimensiune de sector de 4 KO și unitățile vechi care au o dimensiune de sector de 512 octeți. Pentru mai multe informații despre unitățile nou, consultați SQL Server - noi unități de dimensiune de sector utilizarea 4K și SQL Server – stocare spații/VHDx și dimensiune de sector 4K.
Rezoluţie
Problema a fost rezolvată mai întâi în următoarea actualizare cumulativă de SQL Server.

Actualizare cumulativă 5 pentru SQL Server 2014

Actualizarea cumulativă 3 pentru SQL Server 2012 SP2

Actualizare cumulativă 13 pentru SQL Server 2012 SP1

După ce aplicați remedierea rapidă și activați semnalizatorul de urmărire 1800 pe serverele principal, observați o creștere mici în dimensiunea de următoarele fișiere:
  • Fișierul jurnalului de tranzacții
  • Jurnal de face o copiere de rezervă
În plus, observați că următoarele mesaje se înregistrează în Jurnalul de erori de Server SQL Server principală:

pune în Listă tabel de aşteptare jurnal pentru baza acoperire de date 'nume de sign-in bazei acoperire de date>' este fiind rescris pentru a corespunde nouă dimensiune de sector de 4096 octeți

Acesta este un mesaj informativ, care poate fi ignorată în siguranță.

Despre actualizările cumulative pentru SQL Server

Fiecare nouă actualizare cumulativă pentru SQL Server conține toate remedierile rapide și toate remedierile de securitate care au fost incluse în actualizarea cumulativă anterioară. Vedeți cele mai recente actualizări cumulative pentru SQL Server:

Remediere
Pentru a rezolva această problemă, mutați fișierul jurnalului de tranzacții la destinația pe o unitate care are Bytes per Physical Sector setat ca 512 octeți.
Stare
Microsoft a confirmat că aceasta este o problemă cu produsele Microsoft enumerate în secţiunea „Se aplică la".
Informaţii suplimentare
Cea mai bună practică, încercați să vă asigurați că toate discurile pe toate dublurile (cel puțin toate discurile care găzduiesc fișierele jurnal) au aceeași dimensiune de sector. În mediile mixte, unde secundar are un sector fizic de 512 octeți și primar are o dimensiune de sector de 4 KO, Task Force 1800 se recomandă ca o pornire semnalizează pe toate serverele (în special serverele care au un sector fizic de 512 octeți) care poate tranziție în rolul principal. Acest lucru asigură că formatul de crearea în curs de desfăşurare jurnal utilizează o dimensiune de sector de 4 KO.

Pentru mai multe informații despre funcționarea SQL Server cu dimensiuni de sector, consultați următorul post pe blog de asistență:

SQL Server – stocare spații/VHDx și dimensiune de sector 4K

Aveți posibilitatea să utilizați utilitarul de linia Către de comandă Fsutil pentru a determina valoarea Bytes per Sector fizic. Dacă acest parametru nu este vizibil în datele de ieșire, trebuie să aplicați remedierea rapidă care este specificat în articol din bază de cunoştinţe 982018.

Pentru a verifica tipul de unitate pe care o aveți, urmați acești pași:
  1. Executaţi următoarea comandă la un prompt de comandă:
    FSutil fsinfo ntfsinfo x:
    Notă Substituentul x reprezintă unitatea pe care o Verificați.
  2. Utilizați valorile pentru Bytes Per Sector și Bytes per Physical Sector pentru a determina tipul de unitate pe care le aveți. Pentru aceasta, utilizați tabelul următor:
    Valoarea "Bytes Per Sector"Valoarea "Bytes per Physical Sector"Tip de unitate
    409640964K nativ
    5124096Advanced Format (cunoscut și ca 512E)
    512512512 octeți nativ

Avertisment: acest articol a fost tradus automat

Proprietăți

ID articol: 3009974 - Ultima examinare: 01/20/2016 00:22:00 - Revizie: 6.0

Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Standard

  • kbqfe kbhotfixserver kbfix kbsurveynew kbexpertiseadvanced kbmt KB3009974 KbMtro
Feedback