ВИПРАВЛЕННЯ: Низька синхронізації, коли дисків різних сектора розміри первинного та вторинного репліки файлів журналу, на SQL Server AG та Logshipping середовища

ВАЖЛИВО! Ця стаття перекладена засобами машинного перекладу Microsoft. Статтю можна редагувати в середовищі Community Translation Framework (CTF). Щоб якомога швидше перекласти всі статті у своїй базі знань різними мовами, компанія Microsoft не лише звертається до професійних перекладачів, але й вдається до машинного перекладу, який потім редагується спільнотою. Такі статті можуть містити лексичні, синтаксичні та граматичні помилки. Microsoft не несе відповідальності за будь-які неточності, помилки або збитки, до яких може призвести неправильний переклад статей або їх використання. Докладніше про CTF див. на веб-сторінці http://support.microsoft.com/gp/machine-translation-corrections/uk-ua.

Клацніть тут, щоб переглянути цю статтю англійською мовою: 3009974
Примітка
Примітка Після застосування цього виправлення, потрібно ввімкнути прапор трасування 1800 на всіх серверах, щоб зробити це виправлення, які працюють належним чином.
Ознаки
Розглянемо таку ситуацію:
  • Увімкнення функції AlwaysOn наявність групи або Logshipping Microsoft SQL Server 2012 немає або SQL Server 2014.
  • дублювання диска, на яких зберігаються на основному й додатковому реплік, файли журналу в групи забезпечення доступності AlwaysOn (AG), мають розміри сектора на інший. Або в Logshipping середовищі, диски, що магазин в ній файли журналу Logshipping, основні сервери та додаткові-сервери Logshipping розміри сектора на інший. Наприклад:
    • Основна репліка файлу журналу, розташований на дублювання диска розміру сектора на 512 байт. Однак файл журналу додаткової репліки розташований на дублювання диска розміру сектора 4 кілобайт (КБ).
    • Основна репліка файлу журналу, розташований на локальних локальної системи, із розміру сектора на 512 байт. Однак додатковий репліки знаходиться на диску Windows Azure Storage із розміру сектора 4 кілобайт (КБ).
У цьому випадку таке протокол IMAP про помилку, записується в журнал помилка сервера SQL Server:

Було X розрегульований входу IOs, яких потрібно стати знову Синхронне вводу-ВИВОДУ. Поточний вводу-ВИВОДУ, це файл...

Крім того, AG або Logshipping синхронізація працює дуже повільно через Синхронне виконаних. Якщо Windows Azure Storage додаткової репліка, триває значно довше, ніж очікувалося, щоб завершити процес синхронізації.

Примітка. Ця проблема виникає, якщо використовується як нових дисків, які мають розмір сектора на 4 КБ, так і старі диски, які мають розмір сектора на 512 байт. Щоб отримати додаткові відомості про нових дисків див. SQL Server – новий диски, розмір сектора в користування 4 КБ. і SQL Server – онлайнове пул носіїв простору /: vhdx; та стосовно розміру сектора 4 КБ..
Розв'язанн
Проблему, спочатку було усунуто у такий сукупний пакет оновлень із сервера SQL Server.

Сукупний пакет оновлень, 5 для SQL Server 2014 року

Сукупний пакет оновлень 3, для SQL Server 2012 SP2

Сукупний пакет оновлень, 13 для SQL Server 2012 з пакетом оновлень 1

Після застосування виправлення та позначку трасування 1800 на основному серверів, ви помітите невелике Збільшення розміру такі файли:
  • файл журналу транзакцій
  • Резервні копії журналів
Крім того, ви помітите, що записуються такі протокол IMAP в журналі помилка сервера SQL Server основного сервера:

Хвіст журналу для баз даних "ім'я бази даних> "має бути переписати відповідно до нового розміру сектора 4096 байт

Це інформаційні протокол IMAP можна проігнорувати.

Про сукупний пакет оновлень для SQL Server

Нові накопичувальне оновлення для SQL Server, містить усі виправлення, і усі виправлення безпеки, які входять до складу попередній сукупний пакет оновлень. Див. останній сукупний пакет оновлень для SQL Server:

Обхідний шлях
Щоб вирішити цю проблему, перемістіть файл журналу транзакцій до місця призначення до дисків із байт на фізичний сектор , як 512 байт.
Стан
корпорація Майкрософт підтвердила існування цієї неполадки у продуктах Майкрософт, перелічених у розділі "Застосовується до".
Додаткові відомості
Рекомендовано спробуйте, щоб переконатися, що всі диски на всіх реплік (принаймні всі диски на яких зберігаються файли журналу), мають однаковий розмір сектора. У змішаному середовищі, де вторинного фізичного сектора, 512 байт і основний маркер розміром сектору 4 КБ, підтримка 1800 слід використовувати, як і запуск позначає на всіх серверах (особливо серверів, які мають фізичний сектор 512 байт), можна переходу в основному роль. Це гарантує, що створення формат поточної журналу, використовує розмір сектора на 4 КБ.

Щоб отримати додаткові відомості про те, як SQL Server працює з секторів більшого розміру див. такі протокол IMAP на блозі підтримки:

SQL Server – онлайнове пул носіїв простору /: vhdx; та стосовно розміру сектора 4 КБ.

Ви можете використовувати утиліту командний рядок Fsutil. exe щоб визначити значення байт на фізичний сектор. Цей параметр може не відображатися у вихідні, слід застосувати виправлення, указаного у Статті бази Знань, 982018.

Щоб перевірити тип свого диска, виконайте такі дії:
  1. У командному рядку в режимі адміністратора, виконайте таку команду:
    Fsutil fsinfo ntfsinfo x.:
    Примітка. Покажчик місця заповнення x-це дублювання диска, на який потрібно перевірити.
  2. Використовуйте значення для Байт на сектор "і" байт на фізичний сектор , щоб визначити тип свого диска. Для цього, скористайтеся наведеною нижче таблицею:
    Значення для "Байт на сектор"Значення для "Байт на фізичний сектор"Тип диска
    40964096На 4 кілобайти
    5124096Розширений формат (також відомий як 512E)
    512512Убудований на 512 байт

Попередження. Цю статтю переведено автоматично

Властивості

Ідентифікатор статті: 3009974 – останній перегляд: 01/20/2016 00:26:00 – виправлення: 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 KbMtuk
Зворотний зв’язок