Описание виртуального сервера SQL клиентских подключений

Код статьи: 273673 - Список продуктов, к которым относится данная статья.
Переведено с помощью машинного переводаПРЕДУПРЕЖДЕНИЕ: СТАТЬЯ ПЕРЕВЕДЕНА С ПОМОЩЬЮ МАШИННОГО ПЕРЕВОДА
Развернуть все | Свернуть все

На этой странице

Аннотация

В данной статье описываются некоторые основные сведения о подключениях клиента Microsoft SQL Virtual Server.
Перейти к началу страницы | Отправить отзыв

Дополнительная информация

Существенный:Этот раздел, метод или задачу включены действия по инструкции по изменению реестра. Однако, серьезные проблемы могут возникнуть в случае некорректного изменения реестра.. Поэтому при выполнении этих действий рекомендуется строго соблюдать инструкции.. Чтобы обеспечить дополнительную защиту, создайте резервную копию реестра.. В этом случае при возникновении неполадок реестр можно будет восстановить.. Дополнительные сведения о создании резервной копии и восстановлении реестра см. в следующей статье базы знаний Майкрософт::
322756
(http://support.microsoft.com/kb/322756/ )
Создание резервных копий и восстановление реестра Windows


Клиентское расширение функциональности виртуального сервера SQL

Сервер кластеров Microsoft (MSCS) обеспечивает надежный и надежная платформа, на которой можно построить критически важных приложений SQL Server. Не нужно изменять большинство серверных приложений для использования их с помощью MSCS. Тем не менее приложения на основе транзакций (например, серверы баз данных, таких как Microsoft SQL Server) обычно требуют дополнительные изменения, если сервер выйдет из строя, поддержки перемещения при сбое правильно предотвращает потерю поддержка целостности данных. Разработка клиентского приложения для работы с помощью MSCS довольно прост. Необходимо разработать приложения с восстановления базы данных и проверка ошибок в виду.

Даже без использования SQL Server в кластере, сервер автоматически восстанавливает все базы данных после перезапуска сервера. Чтобы убедиться, что база данных восстанавливается состояние согласованное приложение, использование транзакций базы данных таким образом, чтобы при переходе базы данных в согласованное состояние и правильно. Все операции, не завершены, когда происходит переход на другой ресурс должен быть выполнен откат, хотя результаты всех транзакций должны быть сохранены.

Во время перемещения при сбое клиентских приложений потери их подключения к серверу SQL Server и необходимо подключиться к продолжить обработку. Если подключение клиента к серверу без сохранения состояния, (например, приложений, разработанных с помощью Microsoft Internet Information Server [IIS] не имеют состояния) клиент подключится к серверу и продолжает обработку. Если клиент и сервер имеет общего состояния (например, открытых курсоров, переменных сеанса, глобальные переменные языка Transact-SQL или данных в базе данных tempdb), переход на другой ресурс не является прозрачным для клиента. В таких случаях следует разрабатывать приложения для информирования пользователя соединение было либо потеряны, восстановить или приложение автоматически восстановить подключение к серверу. Любая транзакция, не было зафиксировано, при возникновении сбоя выполняется откат.

Обсуждение как клиентов работать с ошибками сервера является стандартным для любого клиентского приложения SQL Server, даже без использования кластеров и виртуальные серверы. Процесс ошибок довольно похоже для клиентского приложения базы данных кластера. В начале отказоустойчивого кластера клиентская программа получает сообщение об ошибке при подключении базы данных. Сообщения об ошибках при зависят от того, клиентская программа выполняет попытку провести это время.

Если сервер SQL Server прошел через кластеромAdminСброс пакетов TCP не отправляются. Если процесс SQL Server завершается операционной системой (по Kill.exe), будут отправлены пакетов сброса.

Это может повлиять на клиентское приложение, если приложение не указывает параметр тайм-аута запроса или время ожидания запроса, равное нулю (0).

Если приложение не имеет значение времени ожидания запроса, откройте подключение остается в УСТАНОВЛЕНО состояние после сбоя.Тот факт, открытые соединения не закрыты и что из этих соединений не отправляются дополнительные пакеты TCP указывает, что эти подключения полностью простоя. Из-за перехода на другой ресурс не отправил любой TCP reset пакеты клиентскому приложению, этих соединений ждать результатов запроса неограниченное время (при условии запроса бесконечный тайм-аут) и потенциально могут заставить соединение перестает отвечать на запросы (зависает).

Чтобы устранить эту проблему с точки зрения клиентского приложения, измените время ожидания запроса на конечным числом.

Поведение сбоя виртуального базы данных

При повреждении базы данных виртуального сервера подключения ссылку неудачных сообщение об ошибке для ожидания клиента. Базы данных на сбойном узле кластера, завершите работу и перезапускается на том же узле, на параметры, настроенные в:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
Порог перемещения при сбое группы по умолчанию равно 10 перезапусков в 6-часового периода, до перемещения при сбое на оставшемся узле. Тем не менее SQL Server перезапустите порогового значения, который может быть проверена через свойства SQL Server на кластере ресурс SQL Server, пороговое значение по умолчанию из трех перезагрузки на SQL Server в 900 секунд и по умолчанию воздействовать на группу. Если клиент пытается подключиться к серверу, а восстановление базы данных, клиент получает ожидает сообщение об ошибке восстановления базы данных и следует повторить после короткой паузы.

SQL Server 6.5 и SQL Server 7.0

SQL Server 6.5 и SQL Server 7.0 работают точно так же, как описано в предыдущем разделе «Виртуальный образом ошибка базы данных».

При запуске SQL Server 7.0, как виртуальный сервер SQL Server 7.0 поддерживает только один IP-адрес, но может прослушивать другие порты, в конфигурации клиента. Это описано в разделе «Несколько на прослушивание порты TCP/IP» в следующей статье Microsoft Knowledge Base:
254321
(http://support.microsoft.com/kb/254321/EN-US/ )
INF: Кластерного SQL Server Do's Don'ts и основные предупреждения

Вопросы использования Microsoft SQL Server 2000

SQL Server 2000 есть некоторые различия в поведении версий SQL Server 6.5 и SQL Server 7.0.

Использование порта SQL Server 2000

Именованный экземпляр прослушивание динамических портов по умолчанию. При первом запуске сервер с порта, на значение нуль (0), сервер запрашивает свободный порт из операционной системы, а затем сервер прослушивает порт. Сервер записывает это в реестр и использует тот же порт каждый раз.

Если сервер настроен на прослушивание динамических портов, а сервер выйдет из строя на прослушивание динамических портов при запуске, сервер выбирает другой порт.

Если настроен статический порт во время установки или после установки с помощью программы сетевого сервера происходит сбой на прослушивание протокола TCP/IP, если этот порт уже используется.

Clients detect the port number to connect to in the case of a named instance or one with a non-default port number.

The connection information is written to the "LastConnect" cache in this registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
You will find entries for each server and the method that was used to connect to them in the registry.

The client attempts to re-use the connection information on each connection unless it fails and then re-negotiates the new information. This might happen if the port number has changed because someone changed it or if it was a dynamic port that was re-assigned due to a port being in use.

Broken connections

There are three ways a connection can be broken:
  1. The server fails; the process terminates by being killed (system server process ID [SPID] kill) or an access violation (AV) or something else causes the operating system or required service to fail.
  2. Machine hardware failure or loss of power.
  3. Server shutdown.
Each of these broken connections exhibit different behaviors seen on the client computer.
  1. In the case where a server fails, the client receives a connection broken error message immediately. You can simulate this behavior by connecting with OSQL, running a long query and then useKILLto terminate your SQL Server process. The client exits with an ODBC error message.
  2. A machine failure is more complicated. The behavior can change slightly based on how the connection loss is detected.

    If the client is in the middle of reading information, the connection loss can be detected immediately because the data stops.

    If the client is just waiting for results, the behavior is slightly different. The behavior depends upon the Keep Alive configuration of the client computer.

    On Microsoft Windows 2000 Keep Alive is set by the client code on a per connection basis. By default, Keep Alive is set to 30 seconds. This means that if the socket dies it is detected within 30 seconds and the client receives an error message. On Microsoft Windows NT 4.0, Keep Alive cannot be set on a per connection basis. Keep Alive must be set for the whole computer, thus affecting all applications on the server.

    Следующие разделы реестра, которые относятся к
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime\REG_DWORD 30000

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveInterval\REG_DWORD 1000
  3. После инициирования завершения работы сервера, сервер ожидает время для клиентов, для завершения. Тем не менее если клиент по-прежнему работает сервер ликвидирует потоков внутри сервера. Уничтожение потоков могут возникать различные сообщения об ошибках на клиентском компьютере. Сообщения об ошибках могут включать подключение прервано ошибки; однако в большинстве случаев вы видите это сообщение об ошибке:
    «Произошла неизвестная ошибка, подключение было прервано сервером».
    Имеет значение ноль (0) в этом случае код внутренней ошибки ODBC, но возвращается как сообщение об ошибке для клиента.
Перейти к началу страницы | Отправить отзыв

Ссылки

Для получения дополнительных сведений о поведении клиентов виртуального сервера SQL в SQL Server 2005 посетите следующий веб-узел Microsoft Developer Network (MSDN):
http://msdn2.Microsoft.com/en-us/library/ms189585.aspx
(http://msdn2.microsoft.com/en-us/library/ms189585.aspx)
Перейти к началу страницы | Отправить отзыв

Свойства

Код статьи: 273673 - Последнее изменение :: 21 ноября 2010 г. - Редакция: 3.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft SQL Server 6.5 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Ключевые слова: 
kbhowto kbsql2005cluster kbclientserver kbinfo kbmt KB273673 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:273673
(http://support.microsoft.com/kb/273673/en-us/ )
Перейти к началу страницы | Отправить отзыв

Отправить отзыв

 
Перейти к началу страницыПерейти к началу страницы