Файл интерфейсов

играет крайне важную роль в процессе работы самого SQL Server и связанных с ним программных продуктов. Фактически, он представляет собой перечень всех доступных экземпляров SQL Server, Open Server, а также таких вспомогательных программных продуктов, как сервер архивации Backup Server и компоненты сервера тиражирования Replication Server.

В файле указываются названия доступных серверов вместе с сетевыми именами соответствующих серверных машин и номерами распределенных этим серверам портов серверных машин.

Рассмотрим особенности файла интерфейсов, используя формат этого файла, принятый в системе SunOS, когда сетевое имя машины и номер порта сервера указывается в файле явно. Напомним, что SQL Server System 11 не работает с системой SunOS, поэтому его интерфейсный файл должен задаваться исключительно в формате системы Solaris. Об этом подробно говорится в разделе “Преобразование файла интерфейсов SunOS в формат системы Solaris”.

Описание каждого сервера в файле интерфейсов состоит из нескольких строк, каждая из которых начинается словами “master”, “query” или “console” (возможны и другие варианты, но они встречаются крайне редко). Существуют три варианта использования файла интерфейсов, каждый из которых подробно рассматривается ниже.

Во-первых, файл интерфейсов читается при запуске SQL Server. Сервер находит в файле интерфейсов описание сервера с именем, указанным в командном файле запуска сервера. Говоря точнее, имя сервера задается либо в качестве значения переменной среды DSLISTEN, либо указывается в командной строке при запуске выполняемого модуля сервера dataserver.

Найдя в файле интерфейсов собственное описание, сервер определяет из строки “master”, на какой серверной машине он должен запуститься и какой номер порта использовать. Кроме того, сервер узнает из файла интерфейсов (строка “console”), где должен быть запущен консольный процесс. Обратите внимание на то, что для SQL Server требуется серверная версия файла интерфейсов, в которой указаны все три строки — “master”, “query” и “console”.

Другие программы — например, серверный модуль SQL Monitor, чье описание в файле интерфейсов приводится под именем <имя_сервера>_МSV, — используют только строки “master” и “query”. (Необходимо заметить, что SQL Server версий System 10 и 11 больше не имеет отдельного серверного процесса, поэтому не нуждается в строке “console”.

Отметим, что SQL Server вовсе не обязательно запускать под именем, указанным в системной таблице sysservers для локального сервера.

Его можно запустить, задав в командном файле запуска любое имя, поскольку оно нужно только для определения имени серверной машины и номера порта из файла интерфейсов. Это имя никак не влияет на соответствующую запись таблицы sysseruers, значение которой можно выдать командой

select @@servername

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

Если командный файл не содержит имени файла интерфейсов, оно дано в переменной среды SYBASE. (Точнее, переменная SYBASE определяет только название каталога, в котором должен находится файл интерфейсов с именем “interfaces”.) Найдя в файле интерфейсов описание удаленного сервера, SQL Server определяет из строки “query” сетевое имя серверной машины удаленного сервера и номер его порта.

В-третьих, любая программа-клиент, которой необходимо подключиться (log in) к SQL Server, находит в файле интерфейсов описание необходимого ей сервера и узнает имя серверной машины и номер порта. Все клиенты должны применять только клиентскую версию файла интерфейсов. Отметим, что имя сервера, используемого по умолчанию, задается в переменной среды DSQUERY.

Поэтому в случаях, когда при запуске программы isql или другого пользовательского приложения имя сервера не было указано явно, приложение использует сервер с именем, определяемым из переменной DSQUERY. В любом случае оно должно найти в файле интерфейсов сервер с соответствующим именем. Если связь с сервером невозможна, необходимо проверить, правильно ли установлена переменная среды DSQUERY (или явно указанное имя сервера) и наличие описания соответствующего сервера в файле интерфейсов.

имеет огромное значение для нормального запуска и работы SQL Server и должен содержать полное и точное описание (сетевое имя машины + номер порта) всех взаимодействующих друг с другом серверов и других программных продуктов.

Поэтому в вашей системе баз данных должен использоваться только один файл интерфейсов. Главные копии его клиентской и серверной версий должны храниться в одном стандартном месте. Оттуда серверная версия копируется на все серверы, а клиентская — на клиентские машины, а также файл”серверы, обеспечивающие работу клиентских машин.

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

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

Предположим, что вам необходимо изолировать от пользователей один из серверов системы для его тестирования. Конечно, это можно сделать путем его перезапуска в однопользовательском режиме. Но кто гарантирует, что именно вы окажетесь тем самым единственным пользователем изолированного сервера? Можно перевести все базы данных в режим доступа только для пользователя dbo.

Но тогда вы лишитесь возможности полномасштабного тестирования сервера, поскольку не сможете подключиться к нему в качестве обыкновенного пользователя при проверке правильности разграничения прав доступа и т.п. Значительно проще изолировать сервер с помощью модификации серверной версии файла интерфейсов, изменив в этом файле имя сервера и номера используемых им портов.

Указав в командном файле запуска сервера его новое имя DDSDBA1_TESTING, вы заставите сервер после запуска прослушивать порт 1925 серверной машины machine1. При этом подключиться к серверу смогут только пользователи, которых известили об изменении имени сервера и номера его порта. Пользователям, принимающим участие в тестировании сервера DDSDBA1_TESTING, придется работать непосредственно с серверной машины, где они смогут воспользоваться локальной модифицированной копией файла интерфейсов.

Они могут также создать на своих клиентских машинах временный интерфейсный файл, содержащий необходимые изменения. Все остальные пользователи, имеющие прежнюю копию клиентской версии файла интерфейсов, не смогут подключиться к несуществующему серверу DDSDBA1 через неиспользуемый порт 1025 серверной машины machine1.

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

В результате у сервера восстановится прежний номер порта, и он внезапно станет доступным для всех пользователей, причем вы об этом вообще не узнаете. Изменение имени сервера одновременно с номером порта позволит избежать подобной ситуации, поскольку случайно разосланная прежняя копия файла интерфейсов восстановит не только номер порта, но и прежнее имя сервера.

Однако в командном файле запуска сервера сохранится его модифицированное имя DDSDBA1_TESTING, и тестируемый сервер не сможет отвечать на запросы, адресованные серверу DDSDBA1 (ему вообще не удастся найти в файле интерфейсов собственное описание и, следовательно, узнать номер своего порта).

Разумеется, администратор сервера также потеряет возможность соединиться с тестируемым сервером. Все попытки подключиться к серверу DDSDBA1_TESTING вызовут сообщение об ошибке “server not found in interface file” — “имя сервера не найдено в файле интерфейсов”. Для решения проблемы будет достаточно восстановить изменения в локальной копии серверного файла интерфейсов и заново подключиться к тестируемому серверу, все это время остававшемуся недоступным для пользователей.

Важно подчеркнуть, что в начале строк “master”, “query” и “console” файла интерфейсов не должны указываться пробелы. Каждая такая строка обязательно начинается с одного символа табуляции. В противном случае сервер не сможет прочитать такую строку, и вы получите сообщение об отсутствии сервера в файле интерфейсов. Эта ошибка особенно неприятна из”за того, что ее невозможно обнаружить при распечатке содержимого файла интерфейсов на экране. Кроме того, подобная проблема может встретиться и в других случаях.

Например, перемещая файл интерфейсов с одной машины на другую с помощью обычной программы ftp, передачу файлов необходимо осуществлять в двоичном режиме (binary mode). Если это требование не выполняется, переданный файл будет выглядеть совершенно нормально, но вместо символов табуляции в началах строк будут стоять пробелы. Таким образом, в непонятных ситуациях с файлом интерфейсов обязательно убедитесь, что в начале строк описания сервера, с которым вам не удается соединиться, нет пробелов.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100