У нас є два виробничих SQL-сервери під управлінням SQL Server 2005 SP4 з накопичувальним оновленням 3. Обидва сервери працюють на фізичних машинах, які однакові. DELL PowerEdge R815 з 4-х 12-ядерними процесорами та 512 ГБ (так ГБ) оперативної пам’яті, з 10-ти ГБ iSCSI-накопичувачами SAN для всіх баз даних і журналів SQL. ОС - це Microsoft Windows Server 2008 R2 Enterprise Edition із усіма оновленнями SP та Windows. OS привід - це масив RAID 5 з 3-х 72 ГБ 2,5-дюймовими 15-дюймовими SAS-накопичувачами. SAN - це Dell EqualLogic 6510 з накопичувачами 48 x 10K SAS 3.5 ", налаштований в RAID 50, розрізаний на різні LUN для 2-х серверів SQL, а також спільний доступ з машиною Exchange та кількома серверами VMWare.
Ми маємо понад 20 баз даних, 11 з яких відображено з високою доступністю за допомогою сервера свідків. Сервер свідчень - це машина з нижчим рівнем роботи, на якій працює екземпляр SQL Server, який використовується ні для чого, крім надання служб свідків. Найбільша дзеркальна база даних - 450 Гб і генерує близько 100-300 іопів. Монітор дзеркального відображення бази даних повідомляє про поточну швидкість надсилання приблизно від 100 кбіт до 10 Мб в секунду, а дзеркальна фіксація накладає витрати (зазвичай) 0 мілісекунд. Дзеркальний сервер не має проблем бути в курсі основного.
Ми постійно відчуваємо відмови від дзеркального відображення. Іноді одна база даних перестане змінюватись, в іншому випадку майже всі бази даних будуть одночасно переходити в прокат. Наприклад, минулої ночі у нас було відмовлено 10 з 11 баз даних, решта бази даних залишалася доступною, поки я вручну її не завершив.
Я пройшов кілька етапів усунення несправностей, щоб спробувати визначити проблему, але досі не зміг вирішити проблему:
1) Машина оснащена мережевим адаптером Gigabit з порту Broadcom BCM5709C NetXtreme II 4 4, який ми спочатку використовували як основне мережеве з'єднання. З того часу ми встановили на двох обох машинах адаптер подвійного порту сервера Intel (R) PRO / 1000 PT, щоб усунути NIC як проблему.
2) Усі бази даних мають автоматичну повну резервну копію щоночі разом із резервною копією журналу для баз даних, що беруть участь у дзеркальному відображенні. Використання файлів журналу контролюється і рідко стає вище 15%. Файл журналу для основної бази даних - 125 ГБ, що складається з 159 віртуальних файлів журналів, що мають розмір від 511 МБ до 1 ГБ. TempDB має власний LUN і складається з 24 x 2 ГБ файлів.
3) Журнал SQL Server у свідка не показує помилок, окрім: З'єднання дзеркального відображення до "TCP: //SQL02.DOMAIN.INET: 5022" вичерпано для бази даних "Дані" через 30 секунд без відповіді. Перевірте сервісні та мережеві з'єднання.
Журнал SQL Server на первинному та вторинному серверах показує повідомлення, що стосуються дзеркального відображення:
З'єднання дзеркального відображення до "TCP: //SQL01.DOMAIN.INET: 5022" вичерпано для бази даних "Дані" через 30 секунд без відповіді. Перевірте сервісні та мережеві з'єднання.
Дзеркальна база даних "Дані" змінює ролі з "ПРИНЦИПАЛЬНИЙ" на "МИРОВИЙ" завдяки синхронізації ролей. (Синхронізація помилково написана тут, оскільки саме так відображається власне повідомлення.)
Дзеркальна база даних "Дані" змінює ролі з "ПРИНЦИПАЛЬНИЙ" на "МИРОВНИЙ" через Невдачу.
Дзеркальна база даних "Дані" змінює ролі з "Дзеркало" на "ПРИНЦИПАЛЬНЕ" завдяки відмові від партнера.
Служби SQL Server продовжують працювати, і мережеві з'єднання, здається, не працюють. Ми послідовно маємо від 500 до 2500 сеансів підключених до кожного сервера (насамперед роботизованих додатків, які підключаються до черг сервісних брокерів на одній базі даних).
4) TCP-димар та RSS тощо відключені за допомогою синтаксису NET SH.
5) Я запустив аналізатор кращих практик SQL Server 2005 проти обох машин і не знайшов нічого, окрім дуже випадкової помилки журналу подій програми 833, жодна з яких не збігається з подіями аварійної відмови:
SQL Server зіткнувся з 1 явищами запитів вводу / виводу, тривалістю яких більше 15 секунд для завершення файлу [F: \ Data.MDF] у базі даних [Дані] (9). Ручка файлу ОС становить 0x00000000000010A0. Зсув останнього довгого вводу-виводу становить: 0x000007d4b10000).
6) Іноді ми бачимо, що "Клієнт не зміг повторно використати сеанс із SPID XXX, який був скинутий для об'єднання з'єднань. Ця помилка може бути викликана попередньою помилкою операції. Перевірте журнали помилок на помилкові операції безпосередньо перед цим повідомленням про помилку . " генерується обома серверами. Здається, немає "попередніх" повідомлень, які б вказували на будь-яку проблему.
7) Іноді пошта бази даних записує помилку в журнал подій програми:
Тип винятку: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Повідомлення: Під час підключення сталася помилка. Причина: термін очікування минув. Період часу очікування, який минув до завершення операції або сервер не відповідає., Параметри з'єднання: Назва сервера: MGSQL02, Назва бази даних: msdb Дані: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) Довідкова посилання: NULL Джерело: DatabaseMailEngine
Інформація про стек-трек у Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) у Microsoft.SqlServer.Management.SqlIMail.Server.DataAcring.Name StringerNameCame. ) у Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Я вважаю, що час очікування викликає відмову; що може спричинити ці очікування? Очевидно, якщо виникла проблема з мережею, наприклад, поганий кабель або поганий комутатор, що може спричинити втрату пакету, а отже і тайм-аут, але які інші речі можуть спричинити тайм-аути? Блокування? Якщо MSDB або якась інша системна база даних мали час очікування вводу / виводу, це може викликати відмову дзеркального відображення?
Дякую за будь-яку пораду!
Про сам механізм тайм-ауту MSDN має сказати наступне :
Механізм відбиття дзеркального відображення
Оскільки м'які помилки не виявляються безпосередньо серверним екземпляром, м'яка помилка може потенційно змусити серверний екземпляр чекати нескінченно. Щоб запобігти цьому, дзеркальне відображення бази даних реалізує свій власний механізм тайм-ауту, заснований на кожному екземплярі сервера під час сеансу дзеркального відображення, що надсилає пінг на кожне відкрите з'єднання через фіксований інтервал.
Щоб зберегти з'єднання відкритим, екземпляр сервера повинен отримати ping по цьому з'єднанню у визначений період очікування, плюс час, необхідний для надсилання ще одного ping. Отримання пінгу протягом періоду очікування означає, що з'єднання все ще відкрите і що екземпляри сервера спілкуються через нього. Отримавши ping, екземпляр сервера скидає лічильник тайм-ауту для цього з'єднання.
Якщо під час з'єднання не було отримано жодної ping, екземпляр сервера вважає, що з'єднання вичерпано. Екземпляр сервера закриває тимчасове з'єднання та обробляє події очікування відповідно до стану та режиму роботи сеансу.
netsh interface tcp show global показує:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Спеціальні поширені запити 0
маска спорідненості вводу / виводу 0
маска спорідненості 0
афінність64 маска вводу / виводу 0
маска афінності64 0
Агенти XP 1
дозволити оновлення 0
трепет включений 0
заблокований поріг процесу 5
c2 режим аудиту 0
clr увімкнено 1
включено загальні критерії 0
Поріг витрат на паралелізм 4
перехресна власність ланцюга власності 0
поріг курсора -1
Бази даних XP XP 1
повнотекстова мова за замовчуванням 1033
мова за замовчуванням 0
за замовчуванням увімкнено 1
заборонити результати за допомогою тригерів 0
коефіцієнт заповнення (%) 0
пропускна здатність сканування футів (макс.) 100
ft пропускна здатність сканування (хв) 0
ft пропускна здатність повідомлення (макс.) 100
ft повідомлення пропускної здатності (хв) 0
індекс створення пам'яті (КБ) 0
сумнів xact дозволу 0
полегшення басейну 0
замки 0
максимальний ступінь паралелізму 6
максимальний повнотекстовий діапазон сканування 4
максимальна пам'ять сервера (МБ) 393216
максимальний розмір відбиття тексту (B) 65536
максимум робочих ниток 0
утримання ЗМІ 0
хв пам'яті на запит (КБ) 2048
хв. пам'яті сервера (МБ) 52427
вкладені тригери 1
розмір мережевого пакету (B) 1400
Процедури Ole Automation 1
відкриті об'єкти 0
Час очікування PH 60
попередній обчислення 0
пріоритетний приріст 0
обмеження вартості губернатора запиту 0
запит чекати (-ів) -1
інтервал відновлення (хв) 0
віддалений доступ 1
підключення віддаленого адміністратора 0
тайм-аути для віддаленого входу в систему 20
віддалений Proc Trans 0
таймаут (и) віддаленого запиту 600
Реплікація XP 0
сканування програм запуску 0
рекурсія триггера сервера 1
встановити розмір робочого набору 0
показати розширені варіанти 1
SMO та DMO XP 1
XP SQL Mail 0
перетворити шум слова 0
двозначний рік відрізку 2049
підключення користувача 0
параметри користувача 4216
Процедури веб-асистента 0
xp_cmdshell 1
Нещодавно я вручну змінив mirroring_connection_timeoutзначення для всіх дзеркальних баз даних на 30 секунд, щоб спробувати усунути проблему; це просто збільшило кількість часу між аварійними подіями. Якщо mirroring_connection_timeoutналаштування встановлено за замовчуванням 10 секунд, ми бачимо набагато більше відмов.
У коментарі попросили мене переконатися, що IPSec відключений, тому я розміщую вміст кількох netshкоманд, які відображають конфігурацію IPSec операційної системи:
C: \> netsh ipsec динамічно показати всі Наразі Політика не призначена Політика основного режиму недоступна. Політика Quickmode недоступна. Загальні фільтри основного режиму недоступні. Конкретні фільтри основного режиму недоступні. Загальні фільтри Quickmode недоступні. Спеціальні фільтри Quickmode недоступні. Асоціації безпеки IPsec MainMode не доступні. Асоціації безпеки IPsec QuickMode недоступні. Параметри конфігурації IPsec ------------------------------ СильнаCRLПеревірка: 1 IPsecexempt: 3 Статистика IPsec ---------------- Активний доцент: 0 Завантажити SA: 0 Ключ очікування: 0 Ключові доповнення: 0 Видалення клавіш: 0 ReKeys: 0 Активні тунелі: 0 Поганий SPI Pkts: 0 Pkts не розшифровано: 0 Pkts не засвідчені: 0 Pkts з виявленням відтворення: 0 Конфіденційні байти Надіслано: 0 Отримано конфіденційних байтів: 0 Автентифіковані байти Надіслано: 0 Отримані автентичні байти: 0 Транспортні байти Надіслано: 0 Отримані транспортні байти: 0 Байтів, надісланих в тунелях: 0 Байти, отримані в тунелях: 0 Розвантажених байтів відправлено: 0 Отримано завантажених байтів: 0 C: \> netsh ipsec статична показати всі ERR IPsec [05072]: у політиці немає політики
ОНОВЛЕННЯ: 2012-12-20
Зараз ми перенесли наші виробничі системи на SQL Server 2012. Ми працюємо цим з ранку 17 грудня - поки що жодних відмов. Однак пара днів перебуває в межах того, що ми бачили із системами на основі 2005 року.
Прагнучи задокументувати ефективність наших нових систем, я придивився sys.dm_os_wait_statsбільш уважно; і помітив DBMIRROR_DBM_EVENT, що є незадокументованим типом очікування. Graham Kent в Microsoft має цікаву статтю щодо усунення неполадок несподіваних помилок і цього типу очікування. Я резюмую його висновки тут:
Замовник відчував величезну ланцюг блокування, побудовану на базі даних OLTP з великим обсягом, де всі блокатори головного очікування чекали на DBMIRROR_DBM_EVENT. Ось послідовність подій, які я пройшов:
Перегляньте саму ланцюг блокування - тут допоможемо, як ми бачимо, що ми чекаємо на DBMIRROR_DBM_EVENT
Перегляньте джерело щодо неподокументованого типу очікування. Очевидно, що ви не можете зробити це за межами MS, але я можу сказати, що на момент написання цей тип очікування являє собою очікування, яке використовується, коли довіритель чекає, щоб дзеркало затверділо LSN, що означає, що транзакція, до якої він входить, не може здійснити . Це відразу вказує досить конкретно на проблему, що довіритель не може здійснювати транзакції, оскільки чекає на дзеркалі. Тепер нам потрібно розібратися, чому дзеркало не здійснює транзакцій або чому довіритель не знає, чи це так.
Перегляньте системні таблиці msdb
(a) Подивіться на таблицю [backupset], щоб побачити, чи розмір журналів, створених на момент виникнення проблеми, значно перевищує звичайний. Якщо вони були винятково великими, можливо, дзеркало було затоплене транзакціями і просто не могло не відставати від обсягу. Ось чому книги в Інтернеті іноді дозволять вам відключити дзеркальне відображення, якщо вам потрібно виконати надзвичайно велику операцію, зареєстровану таким чином, як перебудова індексу. (посилання на те, чому це є на веб-сайті http://technet.microsoft.com/en-us/library/cc917681.aspx ). Тут я використав наступний TSQL
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(б) по-друге, я переглянув дані в таблицях [dbm_monitor_data]. Головне тут - знайти часовий інтервал, в якому у нас виникли проблеми, а потім побачити, чи відчуваємо зміни у будь-якому з наступного:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateЦе всі показники, подібні до частини (а) тим, що вони можуть показати компонент або фрагмент архітектури, який не відповідав. Наприклад, якщо send_queue раптом починає зростати, але черга re_do не росте, то це означатиме, що головний директор не може надсилати записи журналу до дзеркала, тому, можливо, ви хочете переглянути зв’язок, або черги сервісного брокера розглядаючи фактичні передачі.
У цьому конкретному сценарії ми зазначали, що всі лічильники, мабуть, мають дивні значення, оскільки резервні копії журналу відбуваються у звичайних розмірах, але не було змін статусу, 0 черги відправки, 0 черги повторів, рівна швидкість надсилання та квартира швидкість повтору. Це дуже дивно, оскільки це означає, що монітор DBM не міг записувати будь-які значення з будь-якого місця протягом проблемного періоду.
Перегляньте журнали помилок SQL Server. У цьому випадку не було жодних помилок чи інформаційних повідомлень, але в інших сценаріях, таких як цей, дуже часто зустрічаються повідомлення про помилки в діапазоні 1400, приклади яких можна знайти в інших місцях в інших моїх дзеркальних блогах, наприклад цей приклад помилки 1413
Перегляньте файли трас за замовчуванням - у цьому сценарії мені не було надано слідів за замовчуванням, проте вони є фантастичними джерелами інформації про проблеми DBM, оскільки вони фіксують події зміни стану на всіх партнерах. Це документально підтверджено тут:
Клас подій дзеркального відображення бази даних
Це часто дає вам прекрасну картину таких сценаріїв, як, наприклад, коли мережеве підключення між одним або всіма партнерами не вдалося, а потім, яким став стан партнерства після цього.
ВИСНОВКИ:
У цьому конкретному сценарії мені наразі не вистачає 2 ключових моментів даних, але, окрім того, я все-таки можу зробити обґрунтовану гіпотезу щодо вищезазначеної інформації. Ми, безумовно, можемо сказати, що блокування було викликано тим, що DBM було ввімкнено завдяки блокаторам, які очікують на тип очікування DBMIRROR_DBM_EVENT. Оскільки ми знаємо, що ми не затопили дзеркало з великою операцією, яка зареєстрована, і що це розгортання нормально працює в цьому режимі, ми можемо виключити незвичайні великі операції. Це означає, що на цьому етапі у нас є 2 потенційні кандидати:
Проблеми з обладнанням щодо зв’язку між деякими або всіма партнерами.
Виснаження процесора на дзеркальному сервері - просто не в змозі йти в ногу з повторами - виснаження процесора може бути самим процесом поза SQL Server або поза цим дзеркальним партнерством.
Проблема з самим дзеркальним кодом (нам дійсно знадобляться кілька пам’яток пам’яті, щоб підтвердити це).
Виходячи з досвіду, я підозрюю, що це 1 або 2, але я завжди постійно розумію, що це стосується 3, ми намагаємось зібрати ще деякі дані, щоб детальніше розглянути цю проблему.