Щоб виконати початкове з'єднання з відображається базою даних, клієнт повинен надати рядок з'єднання, яка обов'язково містить ім'я екземпляра сервера. Це необхідна ім'я сервера повинно ідентифікувати поточний екземпляр основного сервера, і називається ім'я початкового учасника.
При необхідності рядок з'єднання може також містити ім'я іншого примірника сервера, що ідентифікує поточний екземпляр дзеркального сервера, використовуваного в тому випадку, коли початковий учасник недоступний під час першої спроби з'єднання. Друге ім'я називається іменем партнера по забезпеченню відпрацювання відмови.
У рядку з'єднання має також бути ім'я бази даних. Це необхідно, щоб надати можливість постачальнику доступу до даних намагатися здійснювати відпрацювання відмови.
Після отримання рядка з'єднання постачальник доступу до даних зберігає ім'я початкового учасника та ім'я партнера по забезпеченню відпрацювання відмови (якщо воно приведено) в кеші в енергозалежною пам'яті (для керованого коду кеш міститься в домені додатку). Після кешування ім'я початкового учасника постачальником доступу до даних не оновлюється. Якщо клієнт надає ім'я учасника відпрацювання відмови, то в разі, якщо постачальник доступу до даних не може підключитися з використанням імені початкового учасника, постачальник також зберігає ім'я партнера по забезпеченню відпрацювання відмови.
Сеанс дзеркального відображення бази даних не забезпечує захисту від проблем, пов'язаних з доступом клієнта до серверів, наприклад якщо комп'ютер клієнта відчуває проблеми у взаємодії з мережею. Спроба з'єднання з відображається базою може завершитися невдало з безлічі причин, що не відносяться до постачальника доступу до даних, наприклад спроба з'єднання може виявитися невдалою, якщо екземпляр основного сервера неактивний; це відбувається, коли виконується перехід на іншу базу даних, або через помилки в мережі.
При спробі підключення постачальник доступу до даних намагається підключитися спочатку за допомогою імені початкового учасника. Якщо зазначений примірник сервера доступний і є поточним екземпляром основного сервера, то спроба з'єднання зазвичай завершується успішно.
Якщо сеанс дзеркального відображення припинений, то клієнт зазвичай підключається до основного сервера і завантажує ім'я учасника. Однак база даних не буде доступна клієнту до тих пір, поки не відновиться процес дзеркального відображення.
Якщо спроба завершилася невдачею, постачальник доступу до даних намагається підключитися за допомогою імені партнера по забезпеченню відпрацювання відмови, якщо вона встановлена. Якщо ім'я іншого учасника правильно ідентифікує поточний основний сервер, то постачальнику доступу до даних зазвичай вдається відкрити первісне з'єднання. Після завершення даного з'єднання постачальник доступу до даних завантажує ім'я екземпляра поточного дзеркального сервера. Ця назва зберігається в кеші як ім'я партнера по забезпеченню відпрацювання відмови, при цьому надане клієнтом ім'я партнера по забезпеченню відпрацювання відмови, якщо воно існує, перезаписується. Після цього постачальник даних .NET Framework Data Provider для SQL Server не оновлюється ім'я партнера по забезпеченню відпрацювання відмови. Однак, власний клієнт SQL Server оновлює кеш кожен раз, коли подальше з'єднання або перевстановлення з'єднання повертає інше ім'я учасника.
На наведеній нижче схемі показано з'єднання клієнта з початковим учасником Учасник А для відображається бази даних Db_1. Схема ілюструє випадок, коли ім'я початкового учасника, надане клієнтом, вірно ідентифікує поточний основний сервер Учасник А. Спочатку з'єднання завершується успішно, і постачальник доступу до даних зберігає ім'я поточного дзеркального сервера (Учасник Б) в локальному кеші в якості імені учасника щодо забезпечення відпрацювання відмови . Нарешті, клієнт підключається до основної копії бази даних Db_1.
Спроба початкового з'єднання може завершитися невдало, наприклад в результаті помилки мережі або через те, що екземпляр сервера неактивний. Так як початковий учасник недоступний, клієнт повинен надати ім'я партнера по забезпеченню відпрацювання відмови в рядку з'єднання, щоб постачальник доступу до даних спробував підключитися до партнера по забезпеченню відпрацювання відмови.
У разі якщо ім'я партнера по забезпеченню відпрацювання відмови недоступно, спроби початкового підключення тривають до тих пір, поки не закінчиться час очікування підключення до мережі або не буде повернута помилка (аналогічно підключенню до не відображаються базі даних).
Якщо в рядку підключення наведено ім'я партнера по забезпеченню відпрацювання відмови, то поведінка постачальника доступу до даних залежить від мережевого протоколу і операційної системи клієнта наступним чином:
Для протоколу TCP / IP спроби з'єднання регулюються алгоритмом повторення підключень, специфічним для дзеркального відображення бази даних. Алгоритм повторного з'єднання визначає максимальний час (час повтору), відведений для відкриття з'єднання в рамках даної спроби з'єднання.
Для інших мережевих протоколів
Якщо виникла помилка або початковий учасник недоступний, то спроби початкового з'єднання тривають до тих пір, поки не закінчиться час очікування з'єднання з мережею або не закінчиться час очікування входу на постачальника доступу до даних. Зазвичай цей час очікування становить приблизно 20-30 секунд. Після цього, якщо час очікування постачальника доступу до даних не минуло, постачальник намагається підключитися до партнера по забезпеченню відпрацювання відмови. Якщо час очікування з'єднання минув до успішного завершення підключення або партнер по забезпеченню відпрацювання відмови недоступний, спроба підключення завершується невдало. Якщо до тайм-ауту входу партнер по забезпеченню відпрацювання відмови доступний і в даний момент є основним сервером, спроба з'єднання зазвичай завершується успішно.
Рядки підключення із дзеркальною базою даних
Що повідомляється клієнтом рядок підключення містить відомості, які використовуються постачальником доступу до даних для підключення до бази даних. У цьому розділі описані ключові слова, що відповідають Вашому з'єднанню із дзеркальною базою даних за допомогою драйвера Native Client ODBC SQL Server.
Атрибут Network
Рядок підключення повинна містити атрибут Network. вказує мережевий протокол. Це гарантує збереження зазначеного мережевого протоколу при з'єднанні з різними учасниками. Протокол TCP / IP - найкращий протокол для з'єднання з відображається базою даних. Щоб гарантувати запит протоколу TCP / IP клієнтом при кожному підключенні до учасників, необхідно включити в рядок з'єднання наступний атрибут:
Так як іменовані канали не використовують алгоритм повторення протоколу TCP / IP, у багатьох випадках час спроби підключення за допомогою іменованих каналів закінчується до з'єднання з відображається базою даних.
Атрибут Server
Рядок підключення повинна містити Server атрибут, який надає ім'я початкового учасника, яка повинна ідентифікувати поточний екземпляр основного сервера.
Найпростіший спосіб ідентифікувати примірник сервера - це вказати його ім'я, <имя_сервера> [\<имя_экземпляра_SQL_Server> ]. наприклад:
Запит до браузеру SQL Server необхідний, якщо в рядку підключення вказано ім'я іменованого примірника, а не порт.
Для з'єднання по протоколу TCP / IP, коли імена обох учасників знаходяться в кеші, постачальник доступу до даних встановлює з'єднання за алгоритмом повторного з'єднання. Це справедливо як для початкового з'єднання з сеансом, так і для повторного з'єднання після втрати зв'язку. Після установки з'єднання виконання попередніх і основних кроків підключення вимагає додаткового часу.
Час, витрачений на створення з'єднання, може перевищувати період затримки через зовнішніх чинників, таких як повільні уточнюючі запити DNS, повільний контролер домену або KDC, час, витрачений на зв'язок з браузером SQL Server, завантаженість мережі і так далі. Такі зовнішні чинники можуть перешкоджати підключенню клієнта до дзеркально відображається базі даних. Також зовнішні чинники можуть зробити час створення з'єднання більшим, ніж встановлений час повтору. Додаткові відомості про обхід DNS і браузера SQL Server при підключенні до вихідного учаснику см. В розділі Установка початкового з'єднання з сеансом дзеркального відображення бази даних вище в даній темі.
Якщо спроба з'єднання не вдається або час повтору закінчується до успішного створення з'єднання, постачальник даних намагається підключитися до іншого учасника. Якщо створити з'єднання не вдалося, постачальник намагається змінювати імена вихідного учасника і партнера по забезпеченню відпрацювання відмови, поки не встановиться з'єднання або не має терміну дії час входу. За замовчуванням період очікування входу становить 15 секунд. Рекомендується встановлювати значення інтервалу часу очікування не менше 5 секунд. Завдання меншого інтервалу часу очікування може перешкоджати успішному виконанню будь-яких спроб з'єднання.
Час повтору - це відсоток від часу входу. Час повтору для спроби з'єднання збільшується при кожному успішному циклі. У першому циклі час повтору для кожної з двох спроб становить 8 відсотків від загального часу входу. При кожному успішному циклі алгоритм повтору збільшує максимальний час повтору на те ж число. Отже, час повтору для перших восьми спроб з'єднання буде наступним:
8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%
Час повтору розраховується за допомогою такої формули:
де PreviousRetryTime спочатку дорівнює 0.
Наприклад, при використанні часу очікування входу 15 секунд LoginTimeout = 15. У цьому випадку час повтору, призначене на перші три цикли, буде наступним:
На наступному малюнку показані періоди повторів для успішних спроб з'єднання, час очікування кожної з яких закінчується.
Для часу очікування періоду входу, встановленого за замовчуванням, максимальний час, призначений на перші три цикли спроб з'єднання, становить 14,4 секунди. Якби кожна спроба використовувала весь свій призначений час, то залишалося б лише 0,6 секунди до закінчення часу входу. В цьому випадку четвертий цикл буде скорочений, допускаючи лише останню швидку спробу з'єднання з використанням імені вихідного учасника. Однак спроба з'єднання може не вдатися за період затримки, менше призначеного, особливо в наступних циклах. Наприклад, виникнення помилки мережі може призвести до припинення спроби до закінчення часу повтору. Якщо попередні спроби не вдалися через помилку мережі, для четвертого і, можливо, додаткових циклів буде доступно додатковий час.
Інша причина невдалих спроб - неактивний екземпляр сервера, що трапляється при перекладі екземпляром сервера на інший ресурс своєї бази даних. В цьому випадку виконується затримка повтору для запобігання перевантаження учасників швидким виконанням спроб з'єднання.
Якщо доступні імена обох учасників, а час очікування входу нескінченно, клієнт намагається підключитися до серверів безперервно, перемикаючись між ім'ям вихідного учасника та ім'ям партнера по забезпеченню відпрацювання відмови.
)
Затримки повторів під час відпрацювання відмови
Якщо клієнт намагається підключитися до учасника, яке переходить на інший ресурс, учасник негайно відповідає, що він недоступний. У цьому випадку кожен цикл спроб з'єднання буде значно коротше призначеного часу повтору. Це означає, що до закінчення часу входу може виникнути безліч циклів спроб підключення. Щоб уникнути перевантаження учасників швидкими серіями спроб з'єднання під час відпрацювання відмови, постачальник доступу до даних додає коротку затримку повтору після кожного циклу повтору. Тривалість заданої затримки повтору визначається алгоритмом затримки повтору. Після першого циклу затримка складає 100 мілісекунд. Після кожного з наступних трьох раундів затримка повтору подвоюється - до 200, 400 і 800. Для всіх наступних циклів затримка повтору складає 1 секунду аж до успішного виконання спроби з'єднання або закінчення часу.
Якщо екземпляр сервера зупинений, запит на підключення припиняється негайно.
На наступному малюнку показано, як затримки повторів впливають на спроби підключення під час переходу на інший ресурс вручну, при якому партнери перемикають свої ролі. Період очікування становить 15 секунд.
