(Возврат на основную страницу)

Содержание номера за Декабрь 2008 год

SQL Server
для администраторов

Декабрь 2008
№ 12 (30)

Неизведанный путь x64

Проблемы со счетчиками производительности, встречающиеся на неизведанном пути x64

SQL Server 2008: отслеживание измененных данных. Часть 1

По материалам статьи Пола Ибисона

Общие рекомендации по репликации и устранению возникающих ошибок

По материалам статьи Хилари Коттер

Репликация таблиц с различной структурой

По материалам статьи Пола Ибисона

Репликация через Интернет или между доменами без доверительных отношений

Неизведанный путь x64

Зачем выполнять 32­разрядную версию SQL Server 2005 (или 2000) под управлением Windows Server x64? В конце концов, 64­разрядные версии SQL Server 2005 обеих редакций, как Enterprise, так и Standard, работая на системе x64, полностью используют 64­разрядное адресное пространство памяти. 64­разрядные версии SQL Server 2005 также могут обращаться ко всей доступной оперативной памяти (RAM) напрямую, без применения расширений AWE (Address Windowing Extensions (Расширение адресного пространства)), делая таким образом сочетание 64­разрядного SQL Server и системы x64 наиболее естественным и стандартным. Но бывают ситуации — они и рассматриваются в этой статье, — когда приходится выбирать неизведанный путь и запускать 32­разрядную версию SQL Server.

Прежде всего, хотелось бы уточнить, что речь идет о серверах баз данных на процессорах x64 от Intel или AMD. Эти процессоры предоставляют 64­разрядные вычисления с аппаратной и программно­аппаратной (микропрограммной) эмуляцией для 32­разрядных приложений Windows. Мы не рассматриваем серверы на 64­разрядных процессорах Itanium от Intel, поскольку в процессорах ia64 для 32­разрядных приложений реализована только программная эмуляция.

Оптимальная эмуляция 32­разрядных приложений на Windows Server x64 обеспечивается посредством утилиты WOW64. Приложения, эмулируемые при помощи WOW64 под управлением Windows x64, демонстрируют неплохую производительность, часто не уступающую производительности на совместимом 32­разрядном сервере. Утилита WOW64 запускается в фоновом режиме и включается автоматически, чтобы создать для 32­разрядной исполняемой программы адекватную среду. Вам остается только установить и запустить 32­разрядную программу — точно так же, как и на 32­разрядной версии Windows. (Есть подозрение, что автор уж слишком упрощает картину. WOW64 скорее следует назвать подсистемой, чем утилитой. Подробности можно найти здесь http://msdn.microsoft.com/en­us/library/aa384274(VS.85).aspx. — Прим. ред.)

Большинство администраторов баз данных (DBA) предпочитают выполнять 64­разрядную версию SQL Server под управлением системы x64. Этот подход видится естественным, и если провести опрос, скорее всего окажется, что подобное сочетание значительно более распространено, чем альтернативные. (SQL Server 2000 имеет 64­разрядную версию только для серверов Itanium, в такой ситуации вам волей­неволей придется запускать 32­разрядную версию SQL Server 2000 под управлением Windows Server x64.) Итак, зачем все­таки выполнять 32­разрядную версию SQL Server на Windows x64? Поделим факторы, могущие определить подобное решение, на три группы:

•    Производительность.

•    Количество экземпляров SQL Server.

•    Ограничения на обновление.

Рассмотрим каждую группу по отдельности.

Производительность

На первый взгляд представляется несомненным, что 64­разрядная версия SQL Server покажет лучшую производительность на Windows Server x64 по сравнению с 32­разрядной версией, поскольку 64­разрядная версия не требует эмуляции посредством WOW64.exe. Однако, не проведя тестирования, невозможно знать это наверняка. Иногда встречаются нагрузочные тесты, которые показывали лучшие результаты для 32­разрядной версии SQL Server 2005, хотя точное объяснение этому найти сложно. В других случаях лучше проявляла себя 64­разрядная версия. Как бы то ни было, если вопрос производительности стоит на первом месте, а нагрузочное тестирование выявляет преимущество 32­разрядной версии, ваш выбор предопределен.

Количество экземпляров SQL Server

Основной недостаток комбинирования 32­разрядной версии SQL Server и системы x64 — необходимость использовать расширения AWE (Address Win­do­wing Extensions) для доступа к памяти RAM за пределами 4 Гб (в некоторых случаях, например для стандартной редакции SQL Server 2000, даже расширения AWE недоступны). Однако это ограничение можно преодолеть, обратившись к множественным экземплярам SQL Server.

По умолчанию 32­разрядные версии SQL Server 2005 и 2000 могут обращаться к адресам RAM только в пределах 2 Гб. Однако если применить WOW64, то SQL Server 2005 Enterprise и Standard будут использовать 4 Гб RAM. Чтобы работать с памятью за пределами 4 Гб, необходимо включить расширения AWE. Таким образом возрастут затраты на управление, поскольку придется запоминать дополнительные настройки этого экземпляра SQL Server. Но вы не обязаны запускать только один экземпляр!

При работе с множественными экземплярами SQL Server расширения AWE могут и не понадобиться. Возьмем, к примеру, сервер баз данных, оснащенный 8 Гб RAM, и три экземпляра SQL Server, каждый из которых заберет 2 Гб, оставив 2 Гб для Windows, что как раз в сумме и даст 8 Гб. На сервере с 16 Гб RAM три экземпляра SQL Server 2005 возьмут по 4 Гб памяти на экземпляр (максимальный объем, если отказаться от расширений AWE), четвертый будет использовать 2 Гб, и 2 Гб по­прежнему достанутся Windows. Прибегнув к подобным сценариям, вы запустите множественные экземпляры, не применяя расширения AWE.

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

В конфигурации, основанной на множественных экземплярах, заложены также и потенциальные возможности для повышения производительности — каждый экземпляр работает со своей базой данных tempdb. Если имеется несколько баз данных, интенсивно использующих tempdb, возможно, стоит разнести их по отдельным экземплярам сервера и улучшить производительность за счет того, что у каждого экземпляра будет собственная tempdb. По сути, вы балансируете нагрузку на базу tempdb между множественными экземплярами. Конечно, для начала следует убедиться, что каждая база данных tempdb имеет не меньше файлов данных, чем установлено физических процессоров (CPU) на сервере. «Множественные» экземпляры tempdb от множественных экземпляров SQL Server помогут урегулировать накладные расходы на системную базу временных таблиц.

Ограничения на обновление

Не исключено, что найдутся причины, по которым вы не сможете обновить некоторые из приложений для SQL Server 2000 до SQL Server 2005. Например, поставщик не предоставляет подобной услуги или же ваш бюджет не предусматривает затрат на период разработки и т. д. В этом случае вы будете вынуждены запускать 32­разрядную версию SQL Server 2000 на имеющемся у вас в распоряжении сервере с установленной Windows x64. Чтобы полностью задействовать серверную RAM объемом 8, 16 или даже больше Гб, достаточно воспользоваться расширениями AWE в сочетании с SQL Server 2000 Enterprise Edition или с множественными экземплярами издания SQL Server 2000 Standard Edition.

Пойти другим путем

Мы рассмотрели несколько ситуаций, в которых вы, возможно, отдадите предпочтение 32­разрядной версии SQL Server под управлением Windows x64. Скорее всего, определяющим фактором станет производительность — стоит ли отказываться от 64­разрядной версии SQL Server 2005, если только не окажется, что 32­разрядная версия этого издания функционирует значительно быстрее. Использование 64­разрядного SQL Server на Windows Server x64 — наиболее распространенный и самый опробованный путь. Но если вы решите запускать 32­разрядную версию SQL Server на системе x64, то должны знать о некоторых проблемах с мониторингом, в частности, уметь получать доступ к счетчикам 32­разрядной утилиты System Monitor (Perfmon) на Windows x64. В следующей статье мы обсудим эти проблемы и их решения.

Проблемы со счетчиками производительности, встречающиеся на неизведанном пути x64

Если вы выберете не слишком исхоженный путь выполнения 32­разрядной версии SQL Server под управлением операционной системы Windows x64, как описано в последней колонке SQL Server Observer, то при работе с утилитой Windows System Monitor (также известной как Perfmon) вас будет поджидать парочка сюрпризов.

В двух словах — операционная система Windows x64 поставляется со встроенным эмулятором WOW64, позволяющим выполнять 32­разрядные приложения так же, как это делается на 32­разрядной ОС. Win­dows x64 использует тот факт, что процессорные микросхемы x64 как от Intel, так и от AMD могут аппаратно эмулировать набор команд Intel x86 и таким образом выполнять 32­разрядные приложения без дополнительных затрат. Такая эмуляция достаточно эффективна — при переходе на новый (обычно более быстрый) сервер x64 тестирование может показать, что 32­разрядные приложения стали выполняться быстрее, даже если они не используют всех преимуществ 64­разрядного процессора.

Зачем выполнять 32-разрядное приложение на Windows x64?

Хороший вопрос! Как было отмечено в предыдущей колонке SQL Server Observer («The x64 Path Less Travelled» («Неизведанный путь x64»)), на то имеется пара причин.

Не все приложения способны выполняются под управлением Windows x64, например SQL Server 2000. Если вы переносите SQL Server 2000 на Windows x64, то вам придется запускать его под эмулятором WOW64.

Выполнив соответствующие тесты, вы можете обнаружить, что 32­разрядная версия SQL Server 2005 (или уже SQL Server 2008) выполняется на сервере x64 быстрее, чем соответствующая 64­разрядная версия.

Но независимо от причины, по которой вы выбрали подобный вариант, вы столкнетесь с серьезной проблемой — отсутствием счетчиков производительности!

Где Perfmon?

Сперва отклонимся от темы, чтобы уточнить терминологию. В Windows Server 2003, Windows XP и более поздних версиях Perfmon уже не присутствует. Теперь эта утилита называется System Monitor. То, что для большинства приложений было бы простым переименованием, в случае Windows вполне может сбить вас с толку.

Утилита для измерения производительности, ранее известная как Perfmon, имеет, в частности, официальное название — System Monitor. Но многие специалисты (с большим опытом в этой области) для ясности добавляют в скобках название Perfmon.

Проблема состоит в том, что названия этой утилиты используются непоследовательно и несистематически. Если запускать ее в диалоговом режиме, посредством инструмента «Администрирование» панели управления, то соответствующая оснастка называется Performance (Производительность). В открывающемся графическом интерфейсе утилита, отображающая график производительности, представлена как «Системный монитор» (System Monitor), а также имеется и узел с именем Performance Logs and Alerts (Журналы и оповещения производительности).

Однако при запуске из командной строки или через меню Start/Run (Пуск | Выполнить) достаточно ввести команду «Perfmon» или «Perfmon.exe». Никаких сомнений — исполняемый файл perfmon.exe на диске присутствует! Если вы проявите настойчивость и отправитесь на сайт Microsoft Windows, то найдете ссылки на System Monitor. С другой стороны, на конференциях почти все докладчики от Microsoft называют утилиту Perfmon. Вероятно, они сами знают ее под таким названием или же считают, что слушатели ожидают именно этот термин.

Итак, какое же имя настоящее? Для простоты в этой статье используется термин System Monitor (Perf­mon), чтобы избежать возможных недоразумений, по крайней мере, здесь и сейчас!

Проблема 1: отсутствуют счетчики производительности SQL Server

Как только вы установите любую из 32­разрядных версий SQL Server на свежеустановленную версию Windows Server x64, запустите утилиту System Monitor (Perfmon) и попробуйте добавить несколько счетчиков для вашего 32­разрядного экземпляра SQL Server. Вы не обнаружите их — окажется, что диалоговое окно Add Counters (Добавить счетчики) включает счетчики для всех 64­разрядных экземпляров SQL Server, а счетчики для 32­разрядного экземпляра отсутствуют.

Неважно, попробуете ли вы запустить System Monitor (Perfmon) в диалоговом режиме (из узла System Monitor (Системный монитор)) либо же предпочтете создать файл журнала счетчиков для сбора информации о производительности системы в фоновом режиме — 32­разрядных счетчиков не будет.

Разгадка кроется в том, что утилита System Monitor (Perfmon), включенная в состав Windows x64 и используемая по умолчанию, также является 64­разрядным приложением. Microsoft не предоставляет возможности собирать информацию от 32­разрядных счетчиков 64­разрядной утилитой System Monitor (Perfmon). Но нет ли у нас и 32­разрядной версии? Да, она присутствует, поделенная на две части, одна из которых слегка замаскирована, а другая скрыта намного глубже!

Решение. Часть 1: использование 32-разрядных счетчиков в диалоговом режиме

Когда требуется собрать информацию от счетчиков производительности по 32­разрядному приложению, выполняемому под управлением Windows x64, необходимо запустить 32­разрядную версию System Monitor (Perfmon). По умолчанию, если вызвать Perfmon посредством диалогового окна Start/Run (Пуск | Выполнить), то откроется 64­разрядная версия.

Чтобы получить 32­разрядную версию System Monitor на Windows Server или XP x64, просто найдите Perfmon.exe в следующей папке:

C:\WINDOWS\SysWOW64\

(Предполагается, что Windows установлена в одноименную папку. Если это не так, придется сначала найти папку SysWOW64.)

Вы можете создать на рабочем столе доступный для всех пользователей ярлык к этому исполняемому файлу и переименовать его в «32­разрядный Perfmon». Заметьте, что запуская 32­разрядную версию System Monitor, вы по­прежнему имеете доступ ко всем счетчикам для 64­разрядных приложений.

Проблема 2: не будут работать журналы счетчиков

К сожалению, даже после запуска 32­разрядной версии System Monitor (Perfmon) вам не удастся собирать данные от 32­разрядных счетчиков производительности в журналы. Счетчики добавлять вы сможете, но при последующем анализе информации окажется, что данных по 32­разрядным приложениям в журналах нет! Дело в том, что для сбора данных от счетчиков производительности в журналы System Monitor использует отдельную программу, — а именно, службу smlog­svc.exe. И, конечно, как вы уже догадались, она существует в двух версиях: 64­разрядной и 32­разрядной!

Решение. Часть 2: работа с журналами 32-разрядных счетчиков

Чтобы собирать в журналы производительности данные от 32­разрядных приложений, необходимо заменить 64­разрядную службу на 32­разрядную. Для этого существует несколько непростых способов, основанных на хакерских манипуляциях с реестром, но более простой и эффективный путь заключается в применении входящей в состав Windows утилиты sc.exe, предназначенной для настройки служб. Это решение нашлось в блоге Тодда Картера (Todd Carter): http://blogs.msdn.com/toddca/archive/2007/05/08/logging­32bit­asp­net­performance­counters­on­a­win­dows­2003­64bit­os.aspx. Воспользуемся следующим примером, приведенным в блоге Тодда:

sc config sysmonlog binPath= %systemroot%\syswow64\smlogsvc.exe

Вы запускаете эту команду из окна командной строки, все в одну строчку. В соответствии с указанными параметрами утилита sc.exe настроит службу sysmonlog на использование 32­разрядной версии smlogsvc.exe, находящейся в папке \syswow64, а не в стандартной папке.

В приведенном примере предполагается, что команда запускается на сервере, но не с удаленного сервера, поэтому имя сервера не указано. Также учтите, что справа от знака равенства (=) должен присутствовать один пробел. В противном случае команда не будет выполнена успешно.

Хорошей новостью является то, что 32­разрядная служба smlogsvc.exe учитывает как 32­разрядные, так и 64­разрядные счетчики — не хуже своей родственницы — 32­разрядной диалоговой утилиты Perfmon.

Пока все идет неплохо

Мы применяем эти решения в течение нескольких месяцев, для различных продуктов SQL Server, запуская 32­разрядные экземпляры SQL Server 2000 и 2005 под управлением Windows Server 2003 x64, и до сих пор не столкнулись с какими­либо проблемами. Не следует зарекаться, но пока дела обстоят неплохо.

SQL Server 2008: отслеживание измененных данных. Часть 1

Система отслеживания измененных данных (далее для ее обозначения используется сокращение CDC — Change Data Capture) — это замечательная возможность, появившаяся в версии SQL Server 2008. Вас когда­нибудь интересовало, нельзя ли каким­то образом получить поток данных, в которые, начиная с некоторого определенного момента времени, вносились изменения? Поиски такой возможности ведутся уже довольно давно. Представьте, что у вас есть киоск или хранилище, где хранятся данные, которые являются репликой таблиц OLTP. Содержимое базы данных OLTP изменяется в результате многочисленных, ежедневно выполняемых транзакций, и, в конце концов, обнаруживается нарушение синхронизации данных, хранящихся в киоске или хранилище, с данными таблиц OLTP. В таком сценарии возможность использовать систему CDC, которую предоставляет SQL Server 2008, она позволяет получить надежный поток измененных данных. Система CDC реализована так, чтобы можно было накапливать сведения об операциях вставки, обновления и удаления, выполненных применительно к таблицам SQL.

Общие рекомендации по репликации и устранению возникающих ошибок

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

Рекомендации

Вопрос: Как настроить публикацию, чтобы подписчикам была передана только схема, но не передавались данные?

Ответ: Если в качестве распространителя используется SQL Server 2005, можно добавить недокументированный ключ агента моментальных снимков  /NoBcpData. Но нужно понимать, что использование недокументированных возможностей не гарантирует получения ожидаемого результата.

Вопрос: Как предотвратить появление ошибки ‘Server execution failed’ в работе Snapshot Agent?

Ответ: Установите значение следующего ключа реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\SQLServerAgent\Subsystems\Snapshot

равным следующему:

C:\Program Files\Microsoft SQL Server\MSSQL\BINN\SQLREPSS.DLL,C:\Program Files\Microsoft SQL Server\80\COM\SNAPSHOT.EXE,ReplStart,ReplEvent,ReplStop,120

вместо

C:\Program Files\Microsoft SQL Server\MSSQL\BINN\SQLREPSS.DLL,C:\Program Files\Microsoft SQL Server\80\COM\SNAPSHOT.EXE,ReplStart,ReplEvent,ReplStop,100

Вопрос: Как создать сценарий, восстанавливающий разрешения, для использования его в качестве сценария после применения снимка?

Ответ: Этот сценарий создает разрешения для всех статей на подписчике ‘yyy’

/*****************************************************************************************
Created: 11/02/2005
By: Paul Ibison
Purpose: Script to produce publisher permissions for the subscription 'yyy':
******************************************************************************************/
SELECT   'Grant ' +
 case
  when action = 193 then 'SELECT'
  when action = 195 then 'INSERT'
  when action = 196 then 'DELETE'
  when action = 197 then 'UPDATE'
  when action = 224 then 'EXECUTE'
 end as Grant1,
 ' ON [' + delivery.dbo.sysobjects.name + '] TO ' +
delivery.dbo.sysusers.name as Grant2
 --,ss.srvname
 --,delivery.dbo.syspublications.name AS Publication
FROM    delivery.dbo.syssubscriptions
 INNER JOIN delivery.dbo.sysextendedarticlesview ON
delivery.dbo.syssubscriptions.artid =
delivery.dbo.sysextendedarticlesview.artid
 INNER JOIN delivery.dbo.sysobjects ON
delivery.dbo.sysextendedarticlesview.objid =
delivery.dbo.sysobjects.id
 INNER JOIN delivery.dbo.syspublications ON
delivery.dbo.sysextendedarticlesview.pubid =
delivery.dbo.syspublications.pubid
 INNER JOIN master..sysservers ss on ss.srvid =
delivery.dbo.syssubscriptions.srvid
 left outer JOIN delivery.dbo.sysprotects on
delivery.dbo.sysprotects.id = delivery.dbo.sysobjects.id
 left outer JOIN delivery.dbo.sysusers on
delivery.dbo.sysprotects.uid = delivery.dbo.sysusers.uid
 where action in (193,195,196,197,224)
and srvname = 'yyy'
order by ss.srvname, delivery.dbo.syspublications.name,
delivery.dbo.sysobjects.name, delivery.dbo.sysusers.name
If you aren't interested in a particular subscriber, then this'll be simpler:
CREATE PROCEDURE spGetCPDBPermissionsatBT AS
SELECT   'Grant ' +
 case
  when action = 193 then 'SELECT'
  when action = 195 then 'INSERT'
  when action = 196 then 'DELETE'
  when action = 197 then 'UPDATE'
  when action = 224 then 'EXECUTE'
 end as Grant1,
 ' ON [' + delivery.dbo.sysobjects.name + '] TO ' +
delivery.dbo.sysusers.name as Grant2
FROM    delivery.dbo.sysextendedarticlesview
 INNER JOIN delivery.dbo.sysobjects ON
delivery.dbo.sysextendedarticlesview.objid = delivery.dbo.sysobjects.id
 INNER JOIN delivery.dbo.syspublications ON
delivery.dbo.sysextendedarticlesview.pubid =
delivery.dbo.syspublications.pubid
 left outer JOIN delivery.dbo.sysprotects on delivery.dbo.sysprotects.id =
delivery.dbo.sysobjects.id
 left outer JOIN delivery.dbo.sysusers on delivery.dbo.sysprotects.uid =
delivery.dbo.sysusers.uid
 where action in (193,195,196,197,224)
and delivery.dbo.sysusers.name not in ('RO','RW')
order by delivery.dbo.syspublications.name, delivery.dbo.sysobjects.name,
delivery.dbo.sysusers.name

Вопрос: Как найти триггеры, которые определены с опцией NOT FOR REPLICATION?

Ответ: Пример сценария:

/*****************************************************************************************
Created: 13/07/2005
By: Andy Cox
Purpose: Simple script to identify triggers lacking the NFR attribute.
Modified on PI original to cater for triggers occupying > 1 record in syscomments.
******************************************************************************************/
select a.name
from sysobjects a
where a.xtype = 'TR'
and a.id not in (
select b.id
from syscomments b
where patindex( '%not for replication%', b.text ) >= 1
group by b.id
)

Вопрос: Как добавить одну и ту же таблицу в две публикации?

Ответ: Эта таблица может быть добавлена в каждую публикацию. Однако для одной из публикаций нужно будет установить режим no­sync, поскольку если вы используете автоматическое управление диапазонами,  получите ошибку первичного ключа:

Violation of PRIMARY KEY constraint 'PK__MSrepl_identity___4D5F7D71'. Cannot insert duplicate key in object 'MSrepl_identity_range'

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

Вопрос: Как повысить производительность, если снимок большой?

Ответ:

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

•    Также для сжатого снимка можно использовать альтернативное местоположение.

•    Можно использовать съемные диски, если подписчик не слишком удален географически.

•    Можно увеличить значение параметра —Max­BCP­Threads.

•    В дополнение к предыдущему пункту можно использовать параметр —UseInProcLoader, если вы не применяете файлы с помощью bcp вручную и не используете съемные диски.

Вопрос: Как добавить для уже существующего поля свойство Identity?

Ответ: В данном примере я устанавливаю свойство identity not for replication для поля таблицы jobs:

sp_configure 'allow updates', 1
GO
reconfigure with override
GO
update syscolumns set colstat = colstat | 0x0008 where colstat &
0x0001 <> 0 and colstat & 0x0008 = 0 and id=object id('jobs')
GO
sp configure 'allow updates', 0

Вопрос: Как перенести базу данных distribution?

Ответ: Вы не сможете этого сделать. Вы должны отключить репликацию на издателе, установить дист­рибьютора и разрешить издателю использовать этого дистрибьютора. Затем включить репликацию на издателе и она будет использовать БД распределения. Потом необходимо пересоздать публикацию и подписчиков.

Вопрос: Как определить, что база данных вовлечена в процесс репликации?

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

Результат выполнения процедуры выглядит примерно так:

-----------------------------------
published
select into/bulkcopy
merge publish
trunc. log on chkpt.
auto create statistics
auto update statistics

Или другой способ: запустите на исполнение представленный ниже сценарий

select name, databasepropertyex (name,'IsMergePublished') from master..sysdatabases
select name, databasepropertyex (name,'IsPublished') from master..sysdatabases

Вопрос: Как сделать так, чтобы после изменения процедуры она попала на подписчика вместе с созданным снимком?

Ответ: Хотя процедура sp_refreshsubscriptions ‘publication’ добавляет новую статью в публикацию, которая затем попадет в снимок, но она не подходит для данного случая. Если мы сделаем необходимые изменения в тексте процедуры и запустим sp_refreshsubscriptions, в результате получим следующее сообщение: «A snapshot was not generated because no subscriber needed initialization».

Для того чтобы сформировать новый снимок, для измененной процедуры используется

sp_reinitsubscription @publication = 'publication'
, @article = 'myproc'
, @subscriber = 'london'
, @destination_db = 'testrep'
, @for_schema_change = '1'

После этого создаем снимок (он будет сделан только для новой процедуры) и затем запускаем синхронизацию.

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

Вопрос: Как изменить тип данных или длину уже имеющегося поля?

Ответ: Напрямую это сделать нельзя. Некоторыми способами этого все­таки можно добиться, но такой подход использовать нежелательно. Вы должны добавить новое поле с новым типом данных (sp_repladdcolumn). Затем с помощью команды Update заполнить это поле таблицы значениями из старого поля и удалить старое поле (sp_repldropcolumn). Необходимо проделать это еще раз, чтобы вернуть столбцу первоначальное имя.

Вопрос: Как убрать красный крестик в окне Replication monitor?

Ответ: Если запустить профайлер и перейти в EM к узлу Replication monitor, можно отследить, что происходит в это время на сервере. Для получения информации в Replication monitor используются данные таблицы MSreplication_agent_status и запускается процедура sp_MSload_replication_status, которая обновляет информацию в этой таблице. После перезапуска службы SQL Server проблема снимается, поскольку пересоздается БД tempdb на основе БД model.

Вопрос: Как удалить таблицу из подписки?

Ответ: Процедура sp_dropsubscriptions может быть использована для удаления из подписки одной статьи. Если нет ни одного подписчика, подписанного на эту статью, она может быть удалена с помощью sp_droparticle.

sp_dropsubscription @publication = 'northwindxxx'
, @article = 'region'
, @subscriber = 'pll-lt-16'

sp_droparticle @publication = 'northwindxxx'
, @article = 'region'

Вопрос: Как предотвратить применение снимка, если подписчик был помечен на реинициализацию по ошибке?

Ответ: Если применение снимка еще не запускалось, можно посмотреть и изменить статус подписчика в таблице syssubscriptions:

exec dbo.sp_changesubstatus
@publication = 'NorthwindRegion',
@article = 'region',
@subscriber = 'pll-lt-16',
@destination_db = 'Pubs',
@status = 'active'

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

Вопрос: Как подписаться на отдельную статью?

Ответ: Согласно документации, можно подписаться только на публикацию. Однако, если у вас имеется публикация, которая состоит из нескольких статей (таблиц), можно каждому подписчику подписаться на подмножество статей в публикации. Для этого вы, как обычно, создаете публикацию и затем добавляете подписчиков. Затем для каждого из подписчиков удаляете ненужные статьи. Этот метод работает только если подписчики находятся на разных серверах. Для того чтобы удалить статьи из подписки для подписчика, можно использовать следующую процедуру:

sp_dropsubscription 'publicationname', 'tablename',  'subscribername'

Или еще более простой способ — добавлять статьи для подписчика с помощью процедуры sp_add­subscription.

Как удалить подписчиков, помеченных красным цветом? (Когда я открываю папку Replication­> Subscriptions, я вижу подписчиков, которых там быть не должно и в контекстном меню недоступен пункт «удалить».)

Вы можете воспользоваться процедурой sp_MSenumsubscriptions, чтобы получить информацию, которую получаете при открытии папки с подписчиками. Основные таблицы в каждой базе данных подписки — sysmergesubscriptions и MSREPLICATION_SUBSCRIPTIONS. Если эта база данных больше не является подписчиком, то можно выполнить процедуру sp_removedbreplication, которая удалит ненужные системные таблицы. Если же вы хотите оставить эти таблицы, найдите в вышеупомянутых таблицах строки, соответствующие этим подписчикам, и удалите их.

Сообщения об ошибках

Вопрос: ’Could not bulk insert. Bulk data stream was incorrectly specified as sorted. (Source: ... (Data source); Error number: 4819’

Ответ: Для всех баз данных, вовлеченных в процесс репликации, должна быть установлена одинаковая collation. Для того чтобы увидеть, какая collation установлена для БД, можно воспользоваться процедурой sp_helpsort. Чтобы изменить collation, необходимо использовать команду Alter Database.

Вопрос: ’The process could not create file ‘d:\SQL­Data\­MSSQL\ReplData\unc\SERVER_DataBase_Pub­lica­tion\20041031000029\Publication_1.sch’. Full Message: The process cannot access the file because it is being used by another process.’

Ответ: Проверьте, не установлена ли автоматическая проверка на вирусы. Если это так, отключите проверку для папки, которая используется при создании снимка.

Вопрос: ’The process is running and is waiting for a response from one of the backend connections’

Ответ: Не волнуйтесь, если вы получили это сообщение и кажется, что процесс «завис». По моему опыту, это сообщение возникает, когда данные уже переданы, но об этом еще не пришло уведомление, поскольку на подписчике еще строятся индексы. Это можно увидеть, просмотрев текущую активность на подписчике. Однако необходимо убедиться в том, что в профиле агента (distribution/merge) установлено достаточно высокое значение параметра QUERYTIMEOUT.

Вопрос: ’The schema script ‘0\\DH1791628\C$\Program Files\Microsoft SQL Server\MSSQL\ReplData\20040915121438863\test.sql’ could not be propagated to the subscriber’

Ответ: Если вы используете sp_addscriptexec и возникают ошибки сценария, тогда работа агентов репликации (distribution/merge) будет завершаться с ошибкой. В данном случае можно избежать реинициализации. Чтобы продолжить работу, найдите вышеупомянутый сценарий, по возможности определите и устраните ошибку, или в качестве альтернативного решения можно вставить в сценарий некоторый код на TSQL, например DBCC INDEXDEFRAG, который отрабатывает без ошибок.

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

Вопрос: ’The subscription to publication ‘name of subscription’ has expired or does not exist’, хотя я его добавил.

Ответ: Были запущены процедуры sp_add­merge­pull­subscription и sp_addmergepull­subscription_­agent, а не sp_addmergesubscription.

Вопрос: Ошибка при создании снимка: The process could not bulk copy out of table ‘[dbo].[syncobj_xxxxxxxx]’. Error Details: ODBCBCP/Driver version mismatch

Ответ: Иногда эта проблема снимается после установки одинаковой версии MDAC на обе машины. Для определения версии, можно скачать с сайта загрузки Майкрософт утилиту MDAC Component Checker.

Следующие файлы должны иметь одинаковые версии файлов:

%SystemRoot%\system32\sqlsrv32.dll
%SystemRoot%\system32\sqlsrv32.rll
%SystemRoot%\system32\odbcbcp.dll

Почему возникает эта ошибка? Возможно, из­за неправильной установки MDAC.

Вопрос: Ошибка при создании снимка: The pro­cess could not bulk copy out of table ‘[dbo].[syncobj_­xxxx­xxxx]’. Error Details: I/O error while writing BCP data file (source:ODBC SQL Server Driver ODBC); Error num­ber:0)

Ответ: Обычно эта ошибка возникает, когда имеются проблемы с диском или на диске больше нет свободного места.

Вопрос: При попытке добавить новое поле возникает следующая ошибка: 21260 16 Schema replication failed because database ‘%s’ on server ‘%s’ is not the ori­ginal Publisher of table ‘%s’.

Ответ: В таблице sysmergearticles имеется поле pubid. Этому идентификатору должно быть соответствие в таблице sysmergepublications. В sysmerge­publications значение поля ‘publisher’ должно соответствовать имени сервера, но в вашем случае для этого поля установлено другое значение. Решить эту проблему можно установив правильное значение для поля ‘publisher’, но я не советую делать этого, лучше пересоздать публикацию.

Вопрос: После установки sp3a и восстановления базы данных: Could not find stored procedure ‘dbo_ss.­dbo.sp_MSremovedbreplication’

Ответ: Обычно причиной возникновения этой ошибки является неправильная установка пакета обновления.

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

Вопрос: Почему у меня возникает эта ошибка: ‘ [298] SQLServer Error: 8198, Could not obtain infor­mation about Windows NT group/user ‘domain\user­name’’?

Ответ: Вот хорошая статья, описывающая данную проблему: http://support.microsoft.com/?kbid­=834124.

В соответствующей секции данной статьи объясняются причины возникновения этой ошибки.

Ниже приведены две возможные причины:

•    Учетная запись, под которой запущена служба SQL Server, не имеет необходимых прав в домене Windows. В этом случае можно воспользоваться процедурой sp_logininfo, чтобы получить информацию об учетной записи, под которой запущен сервис SQL Server. Поскольку учетная запись не имеет административных прав, то при получении свойств пользователя в домене посредством хранимой процедуры xp_logininfo, вы получите ошибку 8198. Для устранения этой проблемы, измените учетную запись, под которой стартует служба SQL Server на доменную.

•    Службы SQL Server и SQL Server Agent на издателе и на подписчике используют контекст безопасности разных доменов Windows. Решить данную проблему можно с помощью следующих методов:

•    Использовать одну и ту же учетную запись для запуска SQL Server и SQL Server Agent.

•    Создать доменную учетную запись на издателе и на подписчике, имеющую одинаковое имя и пароль на обоих серверах.

Если рекомендованные методы вам не помогли, можно установить заплатку, доступную по ссылке: http://support.microsoft.com/default.aspx?kbid=830596.

Вопрос: Как избежать ошибки, которая иногда возникает при попытке создания сценария репликации через SQL Server Enterprise Manager: Error 14262. The specified @job_id (‘....’) does not exist?

Ответ: Эта ошибка возникает при попытке создания в SQL Script Enterprise Manager сценария репликации через папку Replication, при выборе контекстного меню Generate. Иногда после удаления подписки, остается информация, а также возможно не обновлен список заданий — это может послужить причиной данной ошибки. Для того чтобы устранить эту проблему, необходимо удалить на подписчике неактуальные записи в таблице MSreplication_subscriptions, обновить информацию в папке Jobs, а затем уже создавать сценарий.

Вопрос: При инициализации я получаю одну из следующих ошибок:

•    The process could not read file ‘\\PLL-LT-16\C$\Program Files\Microsoft SQL Server\MSSQL\ReplData\unc\PLL-LT-16_Northwind_NorthwindOrders\20040226171940\Orders_1.sch’ due to OS error 5.

•    The schema script ‘\\PLL-LT-16\ReplData\unc\PLL-LT-16_Northwind_NorthwindEmployees\20040227085540\Employees_1.sch’ could not be propagated to the subscriber. The step failed.

Ответ: В подписке по запросу (pull), если используется стандартный общий ресурс C$, учетная запись должна иметь права локального администратора. Обычно создают другой общий ресурс. Для данного случая общим ресурсом нужно сделать \\PLL­LT­16\Repldata и изменить путь в свойствах дистрибьютора на вкладке Publishers. (в Enterprise Manager в папке Publications, в контекстном меню выбрать пункт Configure Publishing, Subscribes and Distribution).

Вопрос: Ошибка при инициализации: The process could not connect to Distributor ‘PLL-LT-16’. Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’. The step failed

Ответ: Служба SQL Server Agent не должна использовать учетную запись LocalSystem, ее нужно заменить на доменную учетную запись.

Вопрос: При репликации представления или хранимой процедуры я получаю одну из следующих ошибок:

•    Invalid column name ‘Column Name’

•    Cannot use empty object or column names. Use a single space if necessary.

•    The name ‘Object Name’ is not permitted in this context. Only constants, expressions, or variables allowed here. Column names are not permitted.

•    The schema script ‘Path of the .sch file for the stored procedure proc1’ could not be propagated to the sub­scriber.

Ответ: Эта проблема возникает, потому что Snapshot Agent всегда устанавливает опцию QUOTED_IDENTIFIER в ON, несмотря на текущие установки сервера. Таким образом, если в представлении или хранимой процедуре используются двойные кавычки, Distribution Agent или Merge Agent использует установленные опции для обработки двойных кавычек только для идентификаторов.

Для того чтобы обойти эту проблему, необходимо изменить скрипт, где создается объект (в папке снимка) так, чтобы для литералов использовались одинарные кавычки или передать объект с помощью DTS.

Вопрос: Ошибка при инициализации: The process could not connect to Subscriber ‘SQLReporting’.

Ответ: Distribution agent должен подключиться к подписчику и применить снимок, а затем, возможно, выполнить какие­то дополнительные действия, в зависимости от типа репликации. Для подключения он может использовать учетную запись Windows (доверительное соединение) или SQL Server. Если логин на подписчике неправильный, то вы получите сообщение, приведенное выше. Если логин правильный, но недостаточно разрешений, вы получите следующее сообщение об ошибке: «Only members of the sysadmin or db_owner roles can perform this operation». Для того чтобы устранить проблему, измените свойства дистрибутора (в EM папка Replication, в контекстном меню выбрать «Configure Publishing, Subscribers and Distribution») на вкладке Subscribers, нажав на серую кнопку с тремя точками напротив нужного подписчика. Выбрать «impersonate the sql server agent account on ‘servername’ (trusted connection)». Убедитесь, что учетная запись, под которой работает distribution agent, существует на подписчике и входит в серверную роль sysadmin или в роль db_owner базы данных подписчика, тогда проблема будет разрешена.

Вопрос: Ошибка при инициализации: The process could not connect to Distributor ‘SERVER1’.

Ответ: Эта ошибка может произойти если сервер был переименован. Эта же причина может повлечь следующие ошибки:

18483 ­ could not connect to server ‘Newname’ be­cause distributor_admin is not defined as a remote login at the server.

18482 ­ could not connect to server ‘Newname’ be­cause ‘Oldname’ is not defined as a remote server.

Выполните следующий код:

Use Master
go
Select @@Servername

Запрос вернет имя сервера или NULL. Если вернется NULL, то выполните следующий код, подставив соответствующие имена:

Use Master
go
Sp_DropServer 'OldName'
GO
Use Master
go
Sp_Addserver 'NewName', 'local'
GO

После этого необходимо перезапустить службу SQL Server.

Определить сетевое имя компьютера, на котором работает SQL Server, можно с помощью глобальной переменной @@SERVERNAME или функции SERVER­PRO­PERTY(‘ServerName’). Свойство ‘Server­Name’ функции SERVERPROPERTY изменяется автоматически при перезагрузке компьютера, а переменная @@SER­VER­NAME возвращает первоначальное имя сервера до тех пор, пока его не изменят вручную.

Вопрос: При инициализации возникает ошибка 208 с определенным представлением. Есть ли какие-либо идеи, как это исправить?

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

Для представления, которое вызывает ошибку, запустите процедуру sp_depends, которая вернет зависимости данного объекта в SQL Server. Если процедура показывает, что зависимостей нет, обновите представление и снова запустите проверку зависимостей, после этого порядок статей в снимке должен быть корректным. Также можно воспользоваться процедурой sp_addscriptexec и добавлять, таким образом, представления в любом порядке.

Эти статьи могут быть вам полезны:

•    BUG: Recreating a Table Causes sysdepends to Be­come Invalid (Пересоздание таблицы в случае некорректной информации в sysdepends)

•    BUG: Reference to Deferred Object in Stored Pro­ce­dure Will Not Show in Sp_depends (Ссылка на отсутствующий объект в хранимой процедуре не будет отражена в sp_depends)

•    Displaying Dependencies (Отображение зависимостей)

Вопрос: Я хочу удалить столбец, но не могу запустить процедуру sp_repldropcolumn

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

Вопрос: Я пытаюсь изменить поле, но получаю следующее сообщение об ошибке: “Can’t update column as it’s used in replication”. Однако это поле не задействовано в репликации.

Ответ: Для того чтобы это исправить, имеется процедура sp_MSunmarkreplinfo, параметром ее является имя таблицы. Также в таблице sysobjects можно поменять значение поля replinfo на 0 для этой таблицы. И наконец, можно запустить sp_removedbreplication для удаления всех следов репликации в базе данных подписчика, но это возможно только если эта база данных не издается.

Вопрос: Table ‘UPDATE_LOG’ does not exist in the Subscriber database.

Ответ: Эта ошибка может возникнуть, если Distribution Agent первоначально не создал эту таблицу. Такое может случится, когда на подписчике у другой таблицы существует первичный ключ с тем же именем, что и у файла снимка. Чтобы обойти эту ошибку, можно переименовать ограничение в BCP файле или переименовать его на подписчике.

Общие проблемы

Вопрос: База данных в состоянии Suspect, как вывести ее из этого состояния и продолжить процесс репликации?

Ответ: Для этого изучите статью «Recommended actions for corrupt or suspect databases» и сообщение в колонке журнала Windows IT Pro: «Questions, Answers, and Tips About SQL Server», которые доступны по следующим ссылкам:

•    http://www.karaszi.com/SQLServer/info_corrupt_suspect_db.asp

•    http://www.winnetmag.com/Windows/Article/ArticleID/492/492.html

Вопрос: Для чего используется учетная запись distributor_admin?

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

Репликация таблиц с различной структурой

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

Репликация через Интернет или между доменами без доверительных отношений

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

(Возврат на основную страницу)