Временные таблицы, работа с 64-разрядными ОС, зеркальное отражение, и многое другое
Временные таблицы
Вопрос: Я слышал, что для того, чтобы избежать проблем с соревнованием за доступ к ресурсам, не рекомендуется использовать временную базу данных tempdb. Правда ли это? Я использую эту временную базу данных, поскольку мне нужно использовать данные, распределенные по многим таблицам, а также нужна возможность изменять эти данные. С помощью видов это сделать сложнее.
Ответ: Действительно, при активном использовании временной базы данных tempdb могут возникнуть проблемы с соревнованием за доступ к ресурсам. Однако эта проблема возникает только в редких случаях, когда существуют сотни идентификаторов серверных процессов SPID, которые создают и удаляют многочисленные временные таблицы, как описано в статье базы знаний Майкрософт, которую можно найти по адресу support.microsoft.com/kb/328551.
Приемлемым решением может стать использование временной таблицы (которая может входить или не входить в состав базы данных tempdb). Основной вопрос заключается в том, перевешивает ли увеличение производительности при работе с данными во временной таблице системные издержки, связанные с построением такой таблицы.
Прежде чем отказываться от такого решения, необходимо учесть такие вопросы, как размер, время существования, частота использования и число активных экземпляров временной таблицы (временных таблиц). Параметры сервера также имеют значение, поскольку соревнование за ресурсы базы tempdb может быть связано с аппаратными ограничениями.
Если вам требуется большое число небольших таблиц с коротким сроком существования, вы можете попробовать использовать переменные таблиц, имеющие некоторое преимущество перед временными таблицами. (В ответе на следующий вопрос вы найдете более подробную информацию относительно различий между переменными таблиц и временными таблицами. Также более подробную информацию можно найти на странице "Часто задаваемые вопросы - SQL Server 2000 – Переменные таблиц").
В вашем случае, если все запросы базы данных должны проходить через процедуры создания временных таблиц, стоит вообще подумать о том, чтобы изменить модель данных, а не приспосабливаться к ней.
Вопрос: Что представляют собой переменные таблиц, и как они работают? Можно ли использовать их вместо временных таблиц?
Временные таблицы и переменные таблиц имеют одни и те же базовые функции. Фактически, и те, и другие материализуются в базе данных tempdb в виде временных таблиц. Однако при использовании небольшого количества строк переменные таблиц обеспечивают преимущество производительности. Это связано с тем, что переменные таблиц не ведут статистику и не занимаются индексацией, в результате чего издержки уменьшаются. Если содержание таблицы не превышает несколько страниц базы данных размером 8 КБ, которые будут хранится механизмом базы данных в кэш-памяти, лучше использовать переменные таблиц.
В онлайн-пособии по SQL Server™ дано следующее описание:
- Переменная таблицы ведет себя, как локальная переменная . Переменные таблиц имеют четко определенную сферу действия, которая представляет собой функцию, хранимую процедуру или командный файл, в котором она декларирована. В рамках сферы действия переменную таблиц можно использовать, как обычную таблицу. - Переменные таблиц автоматически очищаются по окончании выполнения функции, хранимой процедуры или командного файла, в котором они определены. - При применении переменных таблиц в хранимых процедурах требуется меньше повторных компиляций хранимых процедур, чем при использовании временных таблиц. - Переменные таблиц требуют меньше ресурсов для блокировки и регистрации. - В некоторых случаях возможно повышение производительности, хотя статистические измерения не проводились.
Зеркальное отражение
Вопрос: Я планирую использовать функцию зеркального отражения в SQL Server 2005 для обеспечения непрерывности работы. Система будет работать в режиме непрерывной работы с автоматическим переключением на резервный ресурс в случае неисправности. Однако при этом я хочу использовать на зеркальном ресурсе некоторые другие приложения, чтобы повысить его эффективность. На зеркальном сервере будет размещено две базы данных: база данных Production DB, представляющая собой зеркало основной базы данных, и база данных Staging DB, представляющая собой независимую базу данных. Она также будет поддерживать два типа клиентских систем: систему с автоматическим переключением на зеркальный ресурс для доступа к базе данных Production DB, и другую систему, непосредственно подключающуюся к базе данных Staging DB.
Кроме того, на зеркальном сервере будет работать несколько пакетов SQL Server Integration Services (SSIS). Эти пакеты будут выполнять доступ к обеим базам данных, а также перемещать данные из базы данных Staging DB на локальном компьютере в базу данных Production DB на основном сервере. В случае переключения при неисправности пакеты SSIS переместят данные из локальной базы данных Staging DB в локальную базу данных Production DB (резервная база). Существуют ли какие-либо проблемы с такой конфигурацией, о которых мне следует знать?
Ответ: Вообще такие конфигурации использовать не рекомендуется, поскольку после переключения при неисправности возможна перегрузка новой основной системы (ранее выступавшей в качестве резервной).
С функциональной точки зрения, с зеркальным отражением проблем быть не должно, но вам необходимо провести тщательное тестирование, если вы все же остановитесь на этом решении. Тестирование следует провести при пиковой нагрузке, в стандартной конфигурации и в условиях после переключения при неисправности. Пиковая нагрузка должна равняться не текущей пиковой нагрузке, а прогнозируемой. Если вы не будете учитывать будущие потребности, решение перестанет работать, когда нагрузка чрезмерно вырастет.
Тестирование также может открыть узкие места, связанные с производительностью сети, жестких дисков и даже процессоров, которые могут в будущем проявиться в виде высокой задержки реакции приложений, низкой пропускной способности, ошибок истечения времени ожидания или чрезвычайно длинных очередей повтора на зеркальном сервере (что может привести к чрезвычайно долгому времени переключения при неисправности, зависящему от скорости выполнения операций повтора).
Кроме того, в случае переключения при неисправности работающие пакеты потеряют связь с неисправным основным сервером. После того, как будет выполнено переключение, и база данных будет запущена на новом основном сервере, пакеты должны иметь возможность подключиться к новому основному серверу. Это предполагает, что в пакеты должны быть встроены механизмы реализации повторных попыток подключения, а в этих механизмах должна иметься возможность обработки ошибок связи, а также восстановления подключения при разрыве.
SQL Server и 64-разрядные ОС
Вопрос: Верно ли, что если я использую 64-разрядную версию операционной системы Windows Server®, я должен использовать SQL Server 2000 Enterprise Edition (64-разрядную версию), а 32-разрядную версию SQL Server 2000 использовать нельзя?
Ответ: С точки зрения SQL Server 2000, единственная поддерживаемая 64-разрядная архитектура – это архитектура Intel® ia64. Таким образом, когда речь идет о поддержке 64-разрядного режима SQL Server 2000, речь идет об архитектуре ia64. Единственная версия SQL Server 2000, поддерживающая 64-разрядную архитектуру ia64 – это версия Enterprise Edition. Версия SQL Server 2000 Standard Edition не поддерживает архитектуру ia64, ни как 64-разрядное приложение, ни как ia64 Windows® on Windows (WOW, подсистема ОС, выполняющая 32-разрядные приложения).
На компьютерах на базе архитектуры AMD x64 есть два варианта использования SQL Server 2000. Вы можете использовать 32-разрядную операционную систему, что позволит вам работать с любой версией SQL Server 2000 и с любым пакетом обновлений (SP). Также вы можете использовать 64-разрядную операционную систему и SQL Server 2000 (любую версию) SP4, применяя WOW. В таких условиях SQL Server 2000 не работает как 64-разрядное приложение. Если он работает под управлением WOW в 32-разрядном режиме, он также не представляет, что он работает в 64-разрядной системе.
Кроме того, подсистемы ia64 WOW и x64 WOW значительно отличаются друг от друга. В архитектуре ia64, WOW эмулирует ограниченное пространство виртуальных адресов и реальные команды компьютера. Команды ia64 полностью отличаются от команд x86 т.к. это совершенно другая архитектура. SQL Server не поддерживает работу никаких компонентов (SQL Server 2000 или SQL Server 2005) под управлением ia64 WOW.
С x64 WOW ситуация обстоит иначе. Архитектуры x86 и x64 очень схожи друг с другом. Они используют одинаковый (или практически одинаковый набор команд). Фактически требуется эмулировать только 32-разрядное виртуальное адресное пространство, а для этого имеется требуемая аппаратная поддержка. Таким образом, x64 WOW поддерживают многочисленные компоненты SQL Server, в том числе SQL Server 2000 SP4 и SQL Server 2005.
Переход на SQL Server 2005
Вопрос: Я хочу перейти с SQL Server 2000 на SQL Server 2005. Какие изменения в приложения мне нужно будет внести, помимо собственно изменения кода SQL? Например, если я подключаюсь к SQL Server 2005 с помощью клиента Microsoft® .NET Framework, нужно ли мне установить на мои клиентские системы Windows XP SP2?
Я использую Windows XP SP1 и Visual Basic® 6.0, а также несколько приложений на базе .NET. Требуется ли мне использовать SQL Server Native Client, .NET Framework 2.0 и Windows XP SP2? Другими словами, каковы минимальные требования к клиентским системам для выполнения обновления? И изменятся ли требования к клиентским системам, если я решу использовать зеркальное отражение SQL Server 2005?
Ответ: Чтобы полностью воспользоваться преимуществами зеркального отражения, требуется клиент SQL Native Client (для OleDb или ODBC) или клиент ADO.NET 2.0 SqlClient. Строку подключения следует изменить, включив в нее ссылку как на основной сервер, так и на зеркало.
Однако для того, чтобы клиент знал о существовании, требуются только SQL Native Client и .NET Framework 2.0. Более старые клиенты могут подключаться к серверу, но не будут автоматически пытаться переключиться на зеркало при неисправности основного сервера.
Если вы не хотите модифицировать клиентские системы, вы можете использовать для их подключения к серверу коммутатор BIG-IP, переключающий их с одного сервера на другой при неисправности. Также вы можете изменить код приложения, чтобы при невозможности подключения к основному серверу оно пыталось подключиться к зеркалу.
Вопрос: Я сталкиваюсь со странными ошибками из-за недостатка памяти при использовании SQL Server 2000 Enterprise Edition SP4 в системе под управлением Windows Server 2003 SP1.Рисунке 1 показано сообщение об ошибке, выводимое в журнале.
На моем сервере установлено много памяти (32 ГБ). Как это ни странно, данная проблема возникает случайным образом. Хранимая процедура, вызывающая эту ошибку, делает это только один-два раза из двадцати.
Счетчики производительности сервера показывают, что доступной памяти много. Может быть, отложенная запись выполняется слишком медленно? Почему процесс выполнения хранимых процедур требует столько памяти? Это связано с числом выражений выбора или с использованием временных таблиц?
Ответ: В данном случае объем физической памяти на компьютере не имеет значения. В зависимости от настроек файла boot.ini, приложениям доступно от 2 до 3 ГБ виртуального адресного пространства. Виртуальное адресное пространство представляет собой очень ценный ресурс в 32-разрядных системах. По умолчанию, пул буферов занимает все виртуальное адресное пространство, за исключением 384 МБ. Эти 384 МБ выделяются на наборы потоков компонентов, которые слишком велики для того, чтобы их обслуживал пул буферов, или не знают, как получать ресурсы из пула буферов (xproc других разработчиков, связанные серверы, COM-компоненты).
Предупреждение указывает, что произошла ошибка выделения приблизительно 23 МБ памяти. Успешность выделения области такого масштаба зависит от числа, а также от распределения других областей блока 384 МБ.
Вы можете рассмотреть возможность удаления некоторых процессов xproc из системы, определяя, используются ли COM-компоненты через sp_oacreate или связанные серверы.
Существует большая вероятность того, что процесс требует выделения такого большого количества памяти при выполнении хранимых процедур SQL в связи с использованием оператора FOR XML в sproc (мы не перепечатываем эту ссылку здесь). Если вам нужна дополнительная информация, Process\sqlservr\Virtual Bytes поможет вам узнать объем свободного виртуального адресного пространства. Также существует инструмент VMStat (его можно найти на компакт-диске, прилагаемом к книге Джеффри Рихтера (Jeffrey Richter) “Programming Applications for Microsoft Windows”), позволяющий определить размер самого большого блока виртуального адресного пространства. Отложенная запись при выделении не используется, используемая для выделения область памяти не входит в bpool.?
