Конфигурирование Microsoft SQL Server в сети

API для SQL Server

Для коммуникации с SQL Server ваши приложения должны уметь "разговаривать" на его языке. Это значит, что при коммуникации должно применяться одно из инструментальных средств, поставляемых вместе с SQL Server, например, командная строка OSQL или ISQLW (анализатор запросов SQL Server). Эти инструментальные средства могут быть полезными для простых запросов, но они не подходят для обработок, ежедневно выполняемых приложениями. Например, люди, работающие с информацией о запасах товаров на складе, со счетами кредиторов и со счетами к получению, трудятся более эффективно, когда пользуются графическим интерфейсом, а не когда набирают с клавиатуры операторы SQL. На самом деле, большинство из пользователей таких приложений вообще не знают SQL. Как правило, для создания приложений, взаимодействующих с SQL Server, разработчики применяют API (Application Programming Interface), интерфейсы прикладного программирования. Благодаря API можно вызывать разнообразные функции для работы с базами данных.

Вместе с SQL Server поставляется множество разных API, в том числе DB-LIB, ODBC и OLE DB. DB-LIB – это первоначальный, "родной" интерфейс API для SQL Server, он доступен и для Microsoft SQL Server и для продуктов Sybase. ODBC – новее и гибче и может применяться для коммуникации с любым количеством реляционных СУБД. Для работы с SQL Server программистам доступны для применения также OLE DB и еще несколько других API. В данном разделе вы найдете описания различных API.

Соединения DB-LIB

Интерфейс DB-LIB был частью SQL Server начиная с первых версий SQL Server, еще с 1988 года. DB-LIB является первоначальным, исконным API для программирования SQL Server. Хотя DB-LIB всегда был составной частью SQL Server, происходит постепенный отказ от него в пользу ODBC, так что ODBC становится основным API. Языки C и C++, а также Microsoft Visual Basic поддерживают DB-LIB. Вызовы DB-LIB производятся из кода приложений, а затем отправляются через сетевую библиотеку, через уровень сетевого протокола и затем на уровень сетевого оборудования.

Соединения ODBC

ODBC – это стандартный API-интерфейс, разработанный фирмой Microsoft для упрощения соединения компьютеров под управлением Windows с различными реляционными СУБД. Благодаря программированию при помощи API-интерфейса ODBC, вы можете применять одно и то же приложение для коммуникации с любым количеством систем. ODBC обладает многофункциональностью, но может оказаться не самым эффективным API для некоторых реляционных СУБД. Как правило, "родные" API поддерживают большую функциональность и оптимизированы для работы со своими реляционными СУБД.

ODBC применяется для поддержки дополнительных возможностей соединения через Интернет с применением "активных серверных страниц" ASP (Active Server Pages). Также там имеется поддержка ActiveX, MFC (Microsoft Foundation Classes) и XML (Extensible Markup Language). За последние несколько лет поддержка ODBC выросла очень значительно, благодаря чему ODBC стал основным API для продуктов, поддерживающих много реляционных СУБД.

API ODBC имеет одинаковую форму независимо от того, с какой реляционной СУБД вы соединяетесь, но это не относится к драйверам ODBC. Вам придется приобретать по драйверу ODBC для каждой используемой реляционной СУБД. Эти драйверы преобразуют ODBC в "родной" сетевой протокол реляционной СУБД. Для оптимальной работы новых версий реляционных СУБД обычно требуются и новые драйверы ODBC, хотя обратная совместимость, как правило, поддерживается. В DB-LIB обычно применяется специфическая сетевая библиотека, а в ODBC – многопротокольная сетевая библиотека. Эта библиотека упрощает соединение приложений ODBC с сервером и избавляет от необходимости выбирать какой-либо определенный протокол.

Пулинг соединений ODBC

Способность к пулингу (объединению ресурсов) при выполнении соединений, вызываемых изнутри приложений, появилась в ODBC версий 2.х. Как правило, каждое приложение создает по одному соединению между уровнем приложений и базой данных всякий раз, когда в это приложение входит еще один пользователь. Этот процесс может оказаться неэффективным, т.к. установление и поддержание соединений с базой данных приводит к довольно-таки большой нагрузке на компьютер.

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

Когда приложение запрашивает соединение ODBC, ODBC Connection Manager (Диспетчер соединений ODBC) определяет, должно ли инициироваться новое соединение или же надо воспользоваться уже имеющимся соединением. Это решение принимается без возможности приложения влиять на него. Затем потоки приложения работают как обычно.

Когда поток завершает свою работу с соединением ODBC, приложение делает вызов для освобождения этого соединения. И снова ODBC Connection Manager берет на себя управление над соединением. А если какое-либо соединение простаивает в течение некоторого периода времени, то ODBC Connection Manager может закрыть его.

Другие API

Имеется множество других API, при помощи которых ваши приложения могут соединяться с SQL Server. Это, например, OLE DB, ODS, SQL-DMF (SQL-Distributed Management Framework), SQL-DMO (SQL-Distributed Management Objects) и SQL-NS (SQL-Namespace). Как правило, каждый из этих протоколов поддерживает те или иные специфические функции или сегмент рынка, для которого требуется свой собственный интерфейс программирования.

Сетевые библиотеки

Уровень сетевых библиотек SQL Server преобразует вызовы API в вызовы, специфичные для протоколов, а затем передает их ниже, на уровень сетевого протокола. На клиентских компьютерах администрирование уровня сетевого протокола производится при помощи утилиты Client Network Utility, а на сервере – при помощи утилиты Server Network Utility. Благодаря этим утилитам вы можете добавлять или удалять сетевые библиотеки как на сервере, так и на любом из компьютеров-клиентов. Чтобы взаимодействие с SQL Server было возможным, сетевые библиотеки, имеющиеся на компьютерах-клиентах, должны быть доступны и на сервере. В одной сети могут работать одновременно сразу несколько протоколов. Например, некоторые из компьютеров-клиентов могут взаимодействовать с SQL Server при помощи именованных каналов (named pipes), а другие клиенты в той же сети могут взаимодействовать с SQL Server при помощи TCP/IP.

Утилита SQL Server 2000 Server Network Utility

Как правило, на одном компьютере-сервере конфигурируют несколько протоколов. По умолчанию на сервере инсталлируются сетевые библиотеки для именованных каналов и TCP/IP. Чтобы сконфигурировать на сервере дополнительные сетевые библиотеки, выполните следующие действия:

Утилита SQL Server 2000 Client Network Utility

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

Запустите Client Network Utility, нажав на экранную кнопку Start, указав на Programs, затем указав на Microsoft SQL Server, и, наконец, выбрав Client Network Utility. Появится диалоговое окно SQL Server Client Network Utility (рис. 11.4), которое выполняет некоторые функции, такие же, как у диалогового окна SQL Server Network Utility, а также еще и многие другие функции.

В то время как диалоговое окно SQL Server Network Utility просто показывает список сетевых библиотек и параметров их соединений, при помощи окна SQL Server Client Network Utility можно указывать, какие протоколы на клиентах должны применяться по умолчанию, а также задать алиас сервера (псевдоним). Включенные протоколы показаны на вкладке General в том порядке, в котором они должны применяться. Например, на рис. 11.4 заданы следующие протоколы: сначала именованные каналы (named pipes), а затем TCP/IP. В нашем примере клиент сначала попытается соединиться с сервером через именованные каналы. Если это не получится, то клиент тогда попытается соединиться с сервером при помощи TCP/IP. Если и это не получится, то клиент выдаст сообщение об ошибке соединения.

(рис 11.4) Вкладка General диалогового окна SQL Server Client Network UtilityАлиас сервера (псевдоним) позволяет отказаться от списка включенных протоколов и дает возможность пользоваться только каким-либо определенным протоколом. Если соединение при помощи этого протокола не получится, то попыток применить другие протоколы не последует. Если у вас имеется несколько серверов, не применяющих общий протокол, то нужно поместить наиболее употребительный протокол на верхнюю строчку списка включенных протоколов. Это минимизирует длительность времени, которое потратилось бы на попытки повторных соединений. Включать и отключать протоколы несложно. Для включения протокола просто выберите нужный протокол в списке отключенных протоколов, а затем нажмите на кнопку Enable. Чтобы отключить протокол, выберите нужный протокол в списке включенных протоколов, а затем нажмите на кнопку Disable.

Вы можете изменять свойства включенных протоколов, выбрав протокол в списке Enabled protocols by order, а затем нажмите на кнопку Properties. Но надо заметить, что значения, применяемые по умолчанию, оптимально подходят почти для всех сетей.

Из вкладки General можно также включить шифрование протоколов, что защитит данные при передаче через сеть. Эта возможность доступна только для протокола multiprotocol.

Чтобы задать алиас сервера, откройте вкладку Alias. В этой вкладке перечислены все существующие алиасы. Чтобы добавить новый алиас, нажмите на Add. Появится диалоговое окно Add Network Library Configuration (Добавить конфигурацию сетевой библиотеки) (рис. 11.5).

В этом диалоговом окне вы можете добавить алиас, задающий нужный протокол. Этот сетевой протокол должен быть сконфигурирован на компьютере-клиенте и должен быть задан здесь, тогда клиент сможет осуществлять коммуникацию при помощи этого протокола. При попытках соединения с алиасом, клиент SQL Server будет применять сетевую библиотеку и параметры соединения, заданные вами здесь. Если приложение будет пытаться соединиться с сервером не через алиас, то будет применяться протокол, используемый по умолчанию.(рис 11.5) Диалоговое окно Add Network Library Configuration

Во вкладке DB-Library Options диалогового окна SQL Server Client Network Utility (рис. 11.6) показана информация о DB-Lib и имеются флажки Automatic ANSI to OEM conversion и Use international settings. При помощи первого флажка можно включить автоматическое преобразование от кодировки символов ANSI к кодировке OEM при коммуникации с SQL Server. При помощи второго флажка можно задать, чтобы форматы дат, времени и денежных единиц применялись бы те, что заданы для текущего компьютера, а не пользоваться жестко заданными настройками этих форматов.

Эти флажки, как правило, снимать не нужно. Установленные флажки вызывают некоторую дополнительную нагрузку на компьютер, но зато и повышают функциональность.

(рис 11.6) Вкладка DB-Library Options диалогового окна SQL Server Client Network Utility

В диалоговом окне SQL Server Client Network Utility имеется также вкладка Network Libraries (рис. 11.7). Как и одноименная вкладка из утилиты SQL Server Network Utility, эта вкладка просто показывает список доступных сетевых библиотек и информацию о номерах их версий.

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

(рис 11.7) Вкладка Network Libraries диалогового окна SQL Server Client Network Utility

Сетевые библиотеки и протоколы SQL Server

Как мы уже говорили, SQL Server поддерживает множество сетевых библиотек: именованные каналы (named pipes), TCP/IP, multiprotocol, NWLink IPX/SPX, AppleTalk, Banyan VINES, VIA (Giganet) и VIA (ServerNet II). Каждая сетевая библиотека соответствует своему сетевому протоколу или набору протоколов. В этом разделе мы дадим краткий обзор каждой из сетевых библиотек.

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

Named Pipes – именованные каналы

Протокол named pipes (именованные каналы) был разработан фирмой Microsoft несколько лет тому назад. В named pipes поддерживаются два режима: локальный и удаленный (дистанционный). Протокол local named pipes применяется в случаях, когда и клиент, и сервер находятся на одном и том же компьютере, а remote named pipes применяется, когда клиент и сервер находятся на разных компьютерах. Если соединение установлено через named pipes, сетевые утилиты SQL Server распознают, как оно осуществлено – с помощью локальных именованных каналов (local named pipes) или же с помощью удаленных (дистанционных) именованных каналов (remote named pipes).

Именованные каналы – это клиентский протокол, применяемый по умолчанию, и он является протоколом, применяемым по умолчанию в операционных системах Windows NT 4 Server и Windows 2000. В операционных системах Microsoft Windows 95 и Microsoft Windows 98 именованные каналы применяться не могут. В этих системах на стороне сервера применяются протоколы TCP/IP, multiprotocol и shared memory. Хотя протокол "именованные каналы" работает эффективно, он обычно не используется в больших сетях, потому что он не поддерживает маршрутизацию и шлюзы. Также не рекомендуется его применение на медленных сетях, т.к. по сравнению с другими протоколами, например, TCP/IP, для него требуется передача значительно большего объема информации между сервером и клиентом.

TCP/IP

Протокол TCP/IP является одним из наиболее популярных сетевых протоколов, из-за очень большого количества компьютеров, на которых он работает, из-за того, что его применение принято в качестве стандарта, и из-за его высокой скорости. Он также является сетевым протоколом, применяемым в Интернете. Сетевая библиотека TCP/IP является одной из наиболее высокопроизводительных сетевых библиотек SQL Server. Благодаря высокой скорости и богатым возможностям TCP/IP станет хорошим выбором.

Multiprotocol

Сетевая библиотека multiprotocol – это новинка, появившаяся в SQL Server 7 и сохранившаяся в SQL Server 2000. Эта сетевая библиотека на самом деле является совокупностью нескольких сетевых библиотек. Поэтому она не так эффективна, как одиночные сетевые библиотеки, но зато обеспечивает большую гибкость. Сетевая библиотека multiprotocol поддерживает протоколы TCP/IP, NWLink IPX/SPX и именованные каналы (named pipes). При использовании сетевой библиотеки multiprotocol обычно используется первый из протоколов, имеющихся на клиенте и на сервере. Так как клиент может соединяться с разными серверами при помощи разных протоколов, то multiprotocol является идеальным выбором.

NWLink IPX/SPX

Протокол NWLink IPX/SPX идеально подходит для интеграции (встраивания) систем SQL Server 2000 в сети Novell NetWare, потому что интеграция в нем реализована гладко, "без швов". Протокол IPX/SPX известен уже долгое время и обладает высокой производительностью и надежностью.

AppleTalk

AppleTalk – это сетевой протокол, разработанный фирмой Apple Computer и применяемый в компьютерах Apple. Windows NT и Windows 2000 поддерживают AppleTalk, благодаря чему серверы и клиенты Windows NT и Windows 2000 могут гладко, "без швов", интегрироваться в окружение AppleTalk.

Banyan VINES

Сетевая библиотека Banyan VINES служит для поддержки компьютеров, работающих в сети VINES. С помощью этой сетевой библиотеки можно интегрировать клиенты и серверы Windows в окружение VINES.

VIA (Virtual Interface Architecture)

Этот протокол поставляется в двух вариантах – Giganet и ServerNet II. Он хорошо подходит для кластеризованных серверов.

Выбор сетевой библиотеки

Выбор сетевой библиотеки должен осуществляться исходя из того, какие протоколы применяются в вашей сети. Проблемы с соединениями обычно возникают, когда сетевые библиотеки на сервере не синхронизованы с сетевыми библиотекам на клиенте. Если при соединении с сервером возникают трудности, то проверьте, как заданы сетевые библиотеки на обеих сторонах соединения. Также попробуйте соединиться с сервером при помощи другой программы, например, при помощи PING или Проводника Windows (Microsoft Windows Explorer), чтобы понять, относится ли проблема к работе SQL Server или же не работает сама сеть.

Сетевые компоненты и производительность SQL Server

Сеть состоит из двух уровней: уровня программного обеспечения, реализованного сетевыми протоколами, и уровня оборудования (аппаратуры). В рамках нашей книги к уровню оборудования будут отнесены также драйверы сетевого оборудования, необходимые для работы этого оборудования. Данные уровни независимы друг от друга и каждый из них может содержать много компонент. Например, можно запускать одновременно TCP/IP и IPX/SPX "поверх" одной и той же сетевой платы, а можно и применять одновременно много сетевых плат, работающих с одним и тем же протоколом (рис. 11.8).

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

Уровень программного обеспечения (сетевые протоколы)

Как уже говорилось, к сетевым протоколам относятся именованные каналы (named pipes), TCP/IP, NWLink IPX/SPX, AppleTalk и Banyan VINES. Важно отметить, что все сетевые протоколы функционируют примерно одинаковым образом, по крайней мере, с точки зрения SQL Server. Если сеть не функционирует или работает не так, как вам надо, то эта проблема, скорее всего, связана с уровнем оборудования.

С другой стороны, проблемы с соединениями обычно возникают либо на уровне сетевых библиотек, либо на уровне сетевого протокола. Если у вас имеются проблемы с соединением клиента SQL Server с сервером SQL Server 2000, то попробуйте соединиться как-либо по-другому, например, через Проводник Windows. Если вы можете соединиться через Проводник Windows, но не можете через SQL Server, то ваша проблема, видимо, связана с SQL Server. Проверьте, что попытки соединения производятся через правильный сетевой протокол. Если сконфигурировано много протоколов, то будет сложнее определить, какой именно протокол используется. Если вы можете соединяться с сервером через PING, Internet Explorer или через какой-либо другой внешний источник, то проблема связана, скорее всего, с вашим выбором сетевых библиотек.

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

Уровень оборудования (аппаратный уровень)

Вы должны понимать работу уровня оборудования (аппаратного уровня), чтобы уметь найти причину возникновения проблем с производительностью. Уровень физического оборудования и уровень протоколов независимы друг от друга, это значит, что вы можете запускать разные сетевые протоколы на любом количестве устройств сетевого оборудования. Производительность сети можно оценить в зависимости от выбранного вами сетевого оборудования. Объем трафика, который может быть обработан сетью, зависит как от типа сети, так и от ее скорости.

Пропускная способность сети

Пропускная способность сети – это показатель объема данных, которые могут быть переданы через сеть за заданный промежуток времени. Иногда пропускная способность указывается в названии сетевого оборудования, например, 10BaseT или 100BaseT, что означает, соответственно, пропускную способность 10 и 100 Мбит/с.

Однако, измерение пропускной способности сети может привести к обманчивым результатам. Для большинства сетевых адаптеров скорость, с которой этот сетевой адаптер может передавать данные, уменьшается при уменьшении объема передаваемых данных, потому что каждая передача через сеть вызывает некоторую дополнительную нагрузку на компьютер. Например, нагрузка, вызываемая передачей 64 Kб данных приблизительно равна нагрузке, необходимой для передачи 2 Кб данных. Реляционные СУБД, в том числе и SQL Server, обычно передают небольшие объемы данных. Поэтому объем данных, который может быть обработан вашим сервером, может оказаться меньше, чем пропускная способность сетевого оборудования.

Ethernet

Хотя существует много разных стандартов сетевого оборудования, но, наверное, самым популярным из них является Ethernet. За последние несколько лет скорость Ethernet выросла и продолжает расти. Ethernet был разработан фирмами Xerox, DEC и Intel в 1976 году. В то далекое время применялся коаксиальный кабель (coaxial cable, сокращенно – "coax") и пропускная способность Ethernet составляла около 3 Mбит/с. После появления технологии 10BaseT пропускная способность выросла до 10 Mбит/с, а после появления технологии 100BaseT – до 100 Mбит/с. Вскоре ожидается появление Gigabit Ethernet, и тогда пропускная способность увеличится до 1 Гбит/с. Показатели пропускной способности Ethernet приведены ниже в таблице:

Несмотря на стремительный рост производительности, Ethernet страдает от серьезной проблемы: иногда сетевые адаптеры Ethernet пытаются передавать данные одновременно. Если два или несколько сетевых адаптеров Ethernet осуществляют передачу данных полностью одновременно, то возникнет коллизия передачи данных. Каждый из адаптеров-участников коллизии должен подождать, а затем снова попытаться передать данные. Хотя вызванные этим потери времени и невелики, но эти задержки все же замедляют передачу данных. Чем больше коллизий будет происходить, тем дольше придется ждать повторных попыток передачи данных. При увеличении объема сетевого трафика вероятность коллизий возрастает. Если объем трафика приближается к пропускной способности сети, то вероятность коллизий становится довольно высокой (рис. 11.9). Коллизии снижают производительность. Поэтому важно следить за сетевым трафиком и наблюдать за коллизиями. Например, можно придерживаться практического правила, согласно которому пропускная способность сети не должна расходоваться более чем на 75%. Конечно, ваша сеть будет переживать кратковременные периоды интенсивного использования, когда трафик будет превышать это значение, но речь идет о том, что превышения 75% уровня не должны длиться долго.

Token Ring

В сетях Token Ring (Маркерное кольцо) каждый член "кольца" (member of the ring) имеет возможность общаться с другими членами, передавая "маркер" (token). Этот маркер разрешает передавать данные только одному компьютеру в сети – тому, кто имеет его в данный момент. Применяя этот тип архитектуры, вы можете расходовать почти полностью всю пропускную способность сети, без возникновения чрезмерных задержек коммуникации.

Token Ring, как и Ethernet, содержит в себе множество технологий, каждая из которых имеет свою пропускную способность, как показано в таблице ниже. Но поскольку Token Ring является последовательностью соединений "от точки к точке", то коллизии здесь возникнуть не могут, даже при использовании полностью пропускной способности. Как и технология Ethernet, Token Ring тоже постоянно совершенствуется.

Кроме Ethernet и Token Ring существуют и многие другие стандарты сетевого оборудования, в том числе ATM и "fiber optics".

Мониторинг сети

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

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

Мониторинг производительности

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

Во-первых, может быть так, что не все серверы и клиенты базы данных в вашей физической сети применяют одинаковые протоколы. Например, компьютер, исполняющий TCP/IP на Ethernet, сможет обнаруживать (на уровне операционной системы) только трафик, который по своей природе является трафиком TCP/IP. Пакеты IPX/SPX будут отбрасываться уже на уровне драйверов. Как правило, для программного обеспечения мониторинга сетей потребуются нестандартные драйверы устройств и компоненты сетевого уровня.

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

Как только вы установите оборудование для мониторинга сети или программное обеспечение, или и то, и другое, вы сможете получить хорошую информацию для оценки объема трафика, обрабатываемого в вашей сети. Этот трафик может быть заметен для ваших компьютеров, но иногда трафик возникает из-за проблем с маршрутизацией и или с конфигурированием. (Диагностика проблем сетевого оборудования выходит за тему нашего курса.) После того как ваша система сетевого мониторинга стала работать, нужно рассмотреть следующие вопросы:

Диагностика причин проблем

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

Можно рекомендовать не допускать трафика, превышающего 75% от пропускной способности сети. Если большинство данных, передаваемых через сеть, имеют небольшие объемы, то этот процент можно и снизить, т.к. обработка большого количества передач данных малого объема вызывает большую загруженность, чем обработка малого количества объемистых передач данных. В сети Ethernet такое уменьшение порогового процента также уменьшит и количество коллизий. Время отклика для сетевых запросов уменьшится, а сеть станет более быстрой.

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

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

Способы решения проблем с сетями

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

Один из способов снижения загруженности сети заключается в увеличении пропускной способности сети. Переход от 10BaseT к 100BaseT повышает пропускную способность десятикратно. Такое решение – простое и быстрое, но может оказаться дорогостоящим. Давайте рассмотрим альтернативные способы.

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

Другое решение – рассмотреть применение сети с точки зрения функциональности. Есть ли серьезные причины для использования сети? Быть может, приложения возвращают слишком большие объемы данных? Всегда полезно посмотреть на клиентские приложения SQL Server и проверить, не запрашивают ли они больше строк, чем это нужно пользователям. Если у вас много пользователей, то возврат минимально возможного количества строк станет простым способом уменьшить сетевой трафик.

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

Заключение

В этой лекции вы изучили основы работы и конфигурирования SQL Server в сетях. Вы познакомились с применяемыми в SQL Server уровнями сетей, от API до сетевых библиотек, сетевых протоколов и, наконец, до сетевого оборудования. Каждый из этих уровней является независимым, но все они взаимно подходят друг к другу в различных конфигурациях. У вас имеется очень много свободы при выборе различных API, сетевых библиотек, протоколов и даже аппаратных решений. И не забывайте периодически проверять сетевой трафик, что поможет избежать проблем с производительностью еще до того, как они возникнут. (О типичных проблемах с производительностью см.лекцию 36, а о том, как следует конфигурировать SQL Server со службой Microsoft Cluster Services, чтобы получить высоконадежную систему, см.лекцию 12.)