СОДЕРЖАНИЕ

1.	СОВЕТЫ
1.1.	Установка, настройка и контроль Log shipping в SQL Server 2000
1.2.	Введение
1.3.	Установка log shipping<
1.4.	Пошаговое руководство
1.5.	Изменение конфигурации log shipping
1.6.	Мониторинг log shipping
1.7.	Удаление и повторная установка log shipping
3.	ССЫЛКИ НА СТАТЬИ
3.1.	Отечественные статьи
3.2.	Новые технические статьи Microsoft
4.	ФОРУМ SQL.RU
4.1.	Самые популярные темы недели
4.2.	Вопросы остались без ответа
5.	ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ

СОВЕТЫ

Установка, настройка и контроль Log shipping в SQL Server 2000
По материалам статьи Ron Talmage: Log Shipping in SQL Server 2000

Введение

Log shipping предназначен для увеличения степени доступности баз данных SQL Server, за счёт автоматического копирования и восстановления журнала транзакция одной базы данных в журнал другой базы данных на другом сервере. Поскольку вторая база данных (далее: резервная) получает все изменения из первой базы данных, она является точным дубликатом первой базы данных с задержкой на процесс копирования и загрузки записей журнала. В любой момент можно сделать резервный сервер основным, если вдруг оригинальный, первый сервер (далее: промышленный) станет недоступным. Когда промышленный сервер снова станет доступным, его можно сделать резервным, полностью изменив роли обеих серверов.
В изданиях Microsoft SQL Server 2000 Enterprise и Developer, в Enterprise Manager присутствует утилита для log shipping, как часть Database Maintenance Plan Wizard. Предварительно, нужно настроить систему log shipping или, в случае SQL Server 7.0, использовать не поддерживаемые семёркой инструментальные средства log shipping, доступные в Microsoft BackOffice 4.5 Resource Kit. Этот визард упрощает процесс установки, конфигурации и контроля SQL Server 2000 log shipping.

[Содержание]

Установка log shipping

Первый сервер (primary server) - это промышленный сервер, на котором осуществляется реальная работа и на нём расположена исходная база данных. Второй сервер (secondary server) содержит резервную базу данных, в которую копируется и восстанавливается журнал регистрации транзакций исходной базы данных. Сервер мониторинга (monitor server) контролирует первый и второй сервер. В отличие от метода контроля log shipping в SQL Server 7.0 для secondary server, SQL Server 2000 log shipping использует для контроля утилиту Enterprise Manager Log Shipping Monitor. Microsoft рекомендует устанавливать эту утилиту на отдельном сервере мониторинга.
Для установки SQL Server 2000 log shipping используется Enterprise Manager Database Maintenance Plan Wizard. Прежде, чем использовать этот визард, Вы должны сделать некоторые первоначальные приготовления. Выполните следующие шаги:

1. Определите пары серверов для log shipping (то есть, primary server и резервные варианты сервера, которые должны участвовать в log shipping). Хотя Вы можете устанавливать log shipping между двумя базами данных на одном сервере, эта статья предполагает, что Вы устанавливаете log shipping между разными серверами.
2. Определите monitor server, который должен быть отдельным от промышленного и резервных серверов.
3. Установите политики безопасности для всех серверов. Учетная запись Windows NT, которая будет использоваться для установки log shipping, должна иметь привилегии системного администратора SQL Server (sa) на всех серверах.
4. Создайте первичные и вторичные распределённые файловые ресурсы. Сначала, создайте ресурс для папки, в которой постоянно будет находиться журнал транзакций исходной базы данных промышленного сервера. Во вторых, создайте ресурс для папки резервного сервера, в которую Вы планируете копировать и восстанавливать журналы транзакций. Чтобы было понятно назначение файлового ресурса, пропишите имена сервера и базы данных в имени файлового ресурса. Если файловые ресурсы уже существуют, можно удалить или переместить другие файлы, особенно старые резервные копии файлов журналов транзакций, из этих файловых ресурсов. Установите разрешения на этот совместно используемый файловый ресурс для учетной записи Windows, которую использует SQL AGENT каждого сервера.
5. Решите, каким способом Вы создадите и проведёте первоначальную синхронизацию резервных баз данных. Вы можете воспользоваться встроенными средствами при установке log shipping для создания и первоначальной синхронизации резервных баз данных, или восстановить полную резервную копию базы данных вручную.
6. Зарегистрируйте все три сервера (то есть: primary server, secondary сервера и monitor server) в Enterprise Manager.

После того, как будут завершены эти предварительные приготовления, Вы готовы использовать Database Maintenance Plan Wizard для установки log shipping. Вы можете рассматривать процесс установки, как последовательность из пяти шагов, которые изображены на рисунке №1.

Primary server

Secondary server

Промышленная база данных

—>

1. Инициализация полной резервной копии

—>

2. Восстановление полной копии без RECOVERY

—>

Резервная база данных

|  V

^  |

3. Периодические резервные копии журнала

SQL Agent Xp_sqlmaint

—>

5. Восстановление резервной копии журнала без RECOVERY

|  V

4. Копирование файла журнала транзакций

| V

|  V

Файл резервной копии журнала транзакций

|  V

—>

Скопированный файл резервной копии журнала транзакций

Monitor server

—>

MSDB

<—

Рисунок №1. Log Shipping в SQL Server 2000

Первые два шага являются дополнительными. Если Вы в начале не синхронизировали базы данных основного и резервного сервера, на шаге №1 будет сделана резервная копия исходной базы данных. На шаге №2, визард копирует резервную копию на secondary server и восстанавливает её поверх резервной базы данных.
Визард всегда исполняет следующие три шага: На шаге №3 он создаёт задачу для SQL AGENT на primary server. Эта задача периодически выполняет резервное копирование в файл. Этот визард также создает ориентированный на log shipping план обслуживания (maintenance plan) для базы данных на secondary server. Этот план состоит из двух заданий SQL AGENT: первое для копирования журнала транзакций на secondary server (Шаг №4), а второе для восстановления журнала регистрации транзакций поверх резервной базы данных (Шаг №5).
Эти шаги создают log shipping пару (то есть: две базы данных участвующих в log shipping). Чтобы ещё больше повысить избыточность или установить связанный сервер, Вы можете сформировать дополнительные log shipping пары, установив log shipping для primary server с другими, дополнительными резервными серверами.

[Содержание]

Пошаговое руководство

Чтобы воспользоваться услугами специализированного визарда, выполните представленные ниже шаги. Откройте Enterprise Manager и разверните в нём primary server, перейдите в папку Management, и запустите Database Maintenance Plan Wizard. В первом экране визарда нужно выбрать промышленную базу данных, а затем поставить галочку в чекбоксе "Ship the transaction logs to other SQL Servers (log shipping)" внизу экрана. Создавать maintenance plan одновременно можно только для одной промышленной базы данных. Указанный чекбокс будет доступен только если для исходной базы данных выбрана full или bulk_logged recovery model, потому что только эти модели допускают резервирование журнала транзакций.

Следующие несколько экранов представляют параметры для определения полной резервной копии базы данных в рамках maintenance plan. Однако, планы несущие более одной функциональной нагрузки могут оказаться сложными для восприятия, так что автор статьи предлагает создать отдельный план для log shipping.
В окне Specify Transaction Log Backup Disk Directory, выберите чекбокс Use this directory, и перейдите в папку журнала транзакций primary server. Удостоверитесь в том, что указанная в Remove files older than продолжительность хранения, достаточна для сохранения журнала на primary server, пока не будут обеспечены все необходимые требования вашей стратегии резервирования. Если Вы зададите слишком короткую продолжительность, и если задача копирования журнала на secondary server окончится сбоем, другая задача SQL AGENT на primary server удалит резервную копию журнала транзакций до того, как SQL Server скопирует её на secondary server, что приведёт к сбою в работе механизма log shipping. Определите в качестве значения по умолчанию для расширений файлов журналов регистрации транзакций в виде ".trn", Эти файлы план обслуживания будет именовать в соответствии с форматом bname_tlog_yyyymmddhhmm.trn.
В следующем экране задаётся Transaction Log Share, и этот экран появляется только если определено, что план использует log shipping. В этом экране нужно идентифицировать файловый ресурс для primary server. Вы можете использовать кнопку с точками (...) для перехода к этому файловому ресурсу.
В экране Log Shipping Destinations можно добавить secondary server или несколько таких серверов по одному. Щёлкните кнопку Add, чтобы открыть диалоговое окно Add Destination Database, и в котором можно ввести всю информацию о secondary server. Текстовое поле Server Name показывает имя резервного сервера, такое, как оно зарегистрировано в Enterprise Manager при предварительной подготовке. В текстовом поле Directory, введите имя каталога резервного сервера, в который будут помещаться копии журналов транзакций исходной базы данных. Это имя - локальный путь к файловому ресурсу. Вы можете выбирать опцию Create and initialize new database на secondary server, что бы SQL Server скопировал и восстановил первоначальную резервную копию базы данных. Или Вы можете выбирать Use existing database (No initialization) если Вы уже выполнили восстановление базы данных. Если ваша база данных большая, может понадобиться выполнить резервное копирование вручную и восстановить резервную базу в удобное время.
Резервная база данных должна быть в состоянии nonrecovered, что бы SQL Server мог восстанавливать журналы транзакций. Вы имеете два параметра, относящихся к состоянию загрузки базы данных: No recovery mode или Standby mode. No recovery mode не означает, что пользователи не смогут делать запросы к базе данных; восстановление журнала транзакций будут единственным выполняемым действием. Standby mode переводит базу данных в режим read-only так, чтобы пользователи могут обращаться с запросами к базе, когда не активно восстановление журнала транзакций. Окно Add Destination Database также содержит опцию Terminate users in database (Recommended) включение которой не позволит работать пользователям, если осуществляется восстановление базы данных или журнала транзакций. Во время восстановления журнала транзакций, выполняющий эту работу процесс будет единственным, которому разрешено работать с базой данных. Поэтому Microsoft и рекомендует использовать эту опцию, потому что присутствие других пользователей в базе данных может замедлить восстановление.
Также Вы можете выбрать опцию Allow database to assume primary role, которая позволяет резервной базе данных переключаться на роль основной, промышленной базы данных, являющейся первичным источником для log shipping и, таким образом, получить возможность в будущем аннулировать первоначальные роли между промышленным и резервным серверами. Когда Вы выбираете эту опцию, определите файловый ресурс для secondary server как папку для резервной копии журнала транзакций для будущей промышленной базы данных.
В следующем окне Initialize the Destination Databases Вы можете выбирать использование уже существующей резервной копии или сделать новую. Для больших баз данных использование существующей резервной копии может быть более удобно. Однако, все журналы транзакций, которые были созданы с момента резервного копирования, должны уже находиться в файловом ресурсе для журнала транзакций на primary server, и иметь правильный порядок, чтобы визард мог скопировать и восстановить их на secondary server. Для небольших баз данных намного проще предоставить создание резервных копий визарду.
В окне Log Shipping Schedules устанавливается периодичность создания резервных копий для исходной базы данных, а также для их копирования и загрузки в заданиях для SQL AGENT, которые визард создаёт на secondary server. Периодичность работы log shipping можно сделать довольно частой, вплоть до одного раза в минуту, но задание исполнения необходимых работ один раз каждые 5 минут является более распространённым вариантом для больших баз данных.
Параметры в окне Log Shipping Thresholds нужны для того, чтобы установить приемлемые значения для времени ожидания на резервное копирование журнала транзакций и исполнение заданий на его копирование и восстановление. Если эти пороговые значения будут превышены, диалоговое окно Log Shipping Monitor на monitor server инициирует соответствующее предупреждение.
Коль уж речь зашла о monitor server, следующее окно Specify Log Shipping Monitor Server Information позволяет определить сервер, который будет использоваться в качестве monitor server. Будьте внимательны: Вы можете просто принять значение по умолчанию, но часто значением по умолчанию является primary server. Как правило, не является хорошей практикой использование в качестве monitor server промышленного или резервного сервера, потому что Вы не сможете определять текущее состояние log shipping, если любой из этих серверов станет недоступен.
После этого вы пройдёте ещё несколько окон, содержащих другие параметры визарда, и в последнем его окне нужно будет выбрать название для плана обслуживания. Автор для ясности предлагает использовать в названии фразу log shipping. Лучше не включать имя сервера в названии плана, если Вы планируете в будущем изменять роли серверов. Щёлкните Finish, и визард автоматически установит log shipping для первичного - промышленного сервера, резервных серверов и также установит Log Shipping Monitor на monitor server.

[Содержание]

Изменение конфигурации log shipping

Чтобы изменить конфигурацию log shipping, используют диалоговое окно Properties maintenance plan. Вкладка transaction log содержит параметры конфигурации резервного копирования журнала транзакций. Вкладка log shipping показывает log shipping пары, которые были созданы в рамках этого плана, а также другие пары, которые были добавлены к плану. Эта вкладка также содержит параметры, с помощью которых можно добавить новую резервную базу данных (создав новую пару log shipping) или удалить выбранную log shipping пару, а также отредактировать свойства выбранной log shipping пары или полностью удалить log shipping.
Когда Вы выбираете Edit во вкладке log shipping, открывается диалоговое окно Edit Destination Database. В диалоговом окне General tab, Вы можете просматривать и изменять каталог журнала регистрации транзакций резервного сервера и новое расположение файлового ресурса основного сервера, которые были заданы при установке. На вкладке Initialize можно изменить режим восстановления и копирования на secondary server, а также периодичность восстановления. На вкладке Thresholds можно установить пороговые значения продолжительности операций. На Sync Threshold устанавливают максимально разрешённую продолжительность операции (между самой последней резервной копией журнала транзакций промышленной базы данных и самым последним восстановлением журнала), после чего Log Shipping Monitor сгенерирует предупреждение (Вы можете установить этот параметр и через Log Shipping Monitor). Значения Load Time Delay, File Retention Period и History Retention Period относятся к secondary server.
Monitor server играет важную роль в этих параметрах конфигурации. Вкладка log shipping во многом зависит от monitor server, так что Вы не можете изменять эти значения конфигурации log shipping, когда monitor server недоступен. Когда автор запустил на monitor server утилиту SQL Server 2000 Profiler он обнаружил, что primary server подсоединился к monitor server, чтобы получить имеющуюся в таблицах monitor server информацию о планировании log shipping. Поэтому, чтобы изменить параметры настройки плана log shipping, Вы должны удостовериться, что monitor server доступен в Enterprise Manager.

[Содержание]

Мониторинг log shipping

Если Вы использовали log shipping в SQL Server 7.0 или создавали свою собственную систему для log shipping, Вы, вероятно, контролируете работу log shipping на secondary server. Однако, SQL Server 2000 для поддержки log shipping имеет специальную утилиту Log Shipping Monitor, которая обычно размещаете на отдельном monitor server.
Где SQL Server 2000 хранит информацию о log shipping? Семь таблиц для log shipping постоянно находятся в базе данных msdb. Для SQL Server 2000 Developer и Enterprise это: log_shipping_plans, log_shipping_plan_databases, log_shipping_databases, log_shipping_plan_history, log_shipping_monitor, log_shipping_primaries, log_shipping_secondaries.
Каждая из этих таблиц существует на промышленном и резервном и серверах, а также на сервере для мониторинга. Каждый сервер использует только некоторые из этих таблиц, чтобы хранить данные, связанные с его ролью в log shipping.
Рассмотрим log shipping для primary server. Из Enterprise Manager можно подключиться к primary server и контролировать работу log shipping. Если база данных включена в log shipping, на вкладке General диалогового окна Properties базы данных будет указана её роль (источник - source или адресат - destination), а также будет отмечено, если этот сервер содержит Log Shipping Monitor. Вы сможете контролировать состояние и хронологию работы заданий на резервное копирование журнала транзакций для log shipping в Enterprise Manager в разделе SQL Server Agent, папка Jobs.
Primary server использует только две таблицы для log shipping в базе msdb. В таблицу log_shipping_databases сервер вставляет строку, привязывающую идентификатор (id) соответствующего maintenance plan базы данных к базе данных, играющей в log shipping роль промышленной, т.е. основной базы. В таблицу log_shipping_monitor сервер вставляет строку, содержащую имя для monitor server и тип его логина.
Рассмотрим log shipping для secondary server. План для log shipping постоянно находится на secondary server. С этого сервера можно контролировать задания SQL AGENT, которые копируют файлы журналов транзакций на сервер и восстанавливают эти журналы поверх базы данных резервного сервера. Также можно увидеть у базы данных резервного сервера в диалоговом окне Properties отметку о её роли в log shipping.
В базе данных msdb на secondary server для log shipping используются четыре таблицы. После создания SQL сервером log shipping плана, будет вставлена строка в таблицу log_shipping_plans, которая фиксирует имена Primary server и Secondary server, а также расположение файлов и идентификаторы (ID) заданий на копирование и восстановление (который будут получены из системной таблицы sysjobs на secondary server). В таблице log_shipping_plan_databases сервер привязывает план к именам промышленных и резервных баз данных и хранит информацию о последних скопированных и загруженных файлах. Таблица Log_shipping_plan_history содержит записи для каждого задания на копирование и восстановление в рамках log shipping плана, а также информацию о порядке исполнения этих задач. В таблицу log_shipping_monitor сервер вставляет строку со ссылкой на monitor server.
Если при установке с помощью Database Maintenance Plan Wizard Вы выбрали возможность смены роли резервного сервера на промышленный, Вы увидите одну важную особенность у secondary server: появится дополнительный план обслуживания (maintenance plan) с точно таким же именем, как у плана, который Вы создали, но у него не будет инициализирован log shipping. Также Вы увидите заблокированную задачу для SQL AGENT, которая призвана создавать резервную копию журнала транзакций локальной базы данных. Хотя на первый взгляд это и вносит некоторую путаницу, имеющий такое же имя maintenance plan является дополнительным планом, который зарезервирован на тот случай, если роли серверов будут изменены.
Рассмотрим контроль log shipping с помощью monitor server. После того, как log shipping будет установлен, SQL Server запускает утилиту Enterprise Manager Log Shipping Monitor на monitor server. Кроме того, SQL Server создает два оповещения для SQL AGENT: одно для резервного копирования, а второе для состояния out-of-sync (отсутствует синхронизация).
Чтобы использовать эту утилиту, откройте Enterprise Manager и подключитесь к monitor server, перейдите в папку Management и выберите Log Shipping Monitor. Вы увидите список log shipping пар. Щёлкните правой кнопкой мыши по паре log shipping, чтобы увидеть историю её резервного копирования, копирования файлов журналов и их восстановления. История копирования и восстановления особенно полезна, потому что она даёт быстрый доступ к информации об ошибках и представляет о них более детализированную информацию, чем Вы можете получить в истории заданий SQL AGENT на secondary server.
Вкладка Status диалогового окна Properties у пары показывает состояние её резервного копирования и процессов копирования и восстанавливать. Состояние может быть нормальным (Normal) или Out-of-Sync. Если SQL Server Agent не скопировал или не восстановил transaction log, диалоговое окно отобразит имя журнала в виде first_file_000000000000.trn. Это не настоящее имя реального файла, оно просто показывает (особенность утилиты), что SQL Server Agent не обработал ни одного файла. Вкладка Status также показывает текущие дельты в минутах для Backup, Copy и Load (имеется ввиду восстановление журнала). Информация на этой вкладке не обновляется автоматически, так что Вы должны закрыть и повторно открыть это диалоговое окно, чтобы обновить данные.

Для log shipping SQL Server использует только две таблицы в базе msdb, чтобы хранить информацию о log shipping парах. В каждой таблице, SQL Server генерирует идентификатор (id) определяющий запись и ограничение внешнего ключа (foreign key constrain) для ссылок в log_shipping_secondaries на primary_id в log_shipping_primaries (только эти две таблицы в log shipping содержат ограничение внешнего ключа). Таблица log_shipping_primaries содержит строку для каждой промышленной базы данных, состояние её задачи резервного копирования журнала транзакций, а также информацию о плановых отключения электропитания (которую Вы можете использовать для предотвращения излишних оповещений). Таблица Log_shipping_secondaries содержит строку для каждой резервной базы данных, которая является подобием промышленной базы данных log shipping. Связанные строки обоих таблиц и формируют пары log shipping, которые Вы наблюдаете в Log Shipping Monitor.
Каждая log shipping пара имеет в диалоговом окне Log Shipping Pair Properties вкладки Source и Destination, которые позволяют корректировать информацию о пороговых значениях для генерации оповещений об отказах в резервном копировании и для оповещений об Out-of-Sync. Эти предупреждения относятся к двум заданиям для SQL AGENT, выполняющимся на monitor server: Log Shipping Alert Job - Backup и Log Shipping Alert Job - Restore. По умолчанию, каждое из заданий выполняется один раз в минуту. Эти задания генерируют ошибку для Windows 2000 или Windows NT Application log, когда время исполнения резервного копирования для log shipping пары превышает аварийный порог или когда процессы копирования и восстановления превышают порог длительности для Out-of-Sync.

[Содержание]

Удаление и повторная установка log shipping

Чтобы удалять log shipping из плана обслуживания базы данных, откройте у плана диалоговое окно Properties, перейдите на вкладку log shipping, и затем щёлкните по Remove log shipping. Это удалит задания для SQL AGENT на копирование и восстановление на secondary server, очистит информацию в таблицах для log shipping на этом сервере и удалит всё связанную информацию из Log Shipping Monitor. Однако, после удаления останется не тронутым задание на резервное копирование журнала транзакций для primary server. Это задание удаляется при удалении соответствующего maintenance plan для базы данных. При удалении Log Shipping Monitor на monitor server, удаляются соответствующие строки в таблицах log_shipping_primaries и log_shipping_secondaries в базе данных msdb, расположенной на monitor server.
Если при установке log shipping с помощью Database Maintenance Plan Wizard Вы предусмотрели возможность для резервной базы данных принять роль промышленной базы данных, maintenance plan базы данных на secondary server и его задача резервного копирования журнала останутся на secondary server даже после того, как Вы удаляете план на primary server. Чтобы их удалить, необходимо удалить maintenance plan для log shipping у базы данных на secondary server. Когда Вы экспериментируете с SQL Server 2000 log shipping, возможно, что Вы будет иногда прерывать процесс инсталляции. Когда Вы это сделаете, некоторые данные могут остаться в таблицах log shipping на каждом из серверов и могут мешать при последующих попытках установки log shipping. (Для дополнительной информации, см. статью Microsoft: "BUG: All Changes May Not Be Rolled Back When Log Shipping Maintenance Wizard Fails") Чтобы избежать подобной ситуации, удалите все относящиеся к прошлым попыткам данные в таблицах для log shipping в базах msdb на каждом из серверов.

[Содержание]

ССЫЛКИ НА СТАТЬИ

Отечественные статьи

Язык XML. Стилевые таблицы XSL
В предыдущем разделе для вывода элементов XML- документа на экран броузера мы применяли Java Script-сценарии Однако, как уже отмечалось, для этих целей предпочтительней использование специально предназначенного для этого средства - стилевых таблиц XSL(Extensible Stylesheet Language)...
XML Viewer. (IBM alphaWorks)
Работа, в какой-либо степени связанная с проектированием, написанием и обработкой XML-документов, требует наличия, по крайней мере, хорошего визуализатора. Т.е. инструмента, который позволял бы визуально отобразить на экране дерево элементов XML. Это в несколько раз облегчает восприятие внутренней структуры документа XML. Именно для этой цели и предназначена небольшая утилита XMLViewer...
Работа с журналом событий SQL Server
В процессе функционирования SQL Server ведет журнал, в котором регистрирует события, связанные с работой сервера. В документации этот журнал называется Error Log, что не вполне соответствует действительности. Правильнее было бы именовать его Event Log, так как в нем отмечается множество событий различного характера из разных источников, включая системные информационные и системные аварийные события, сообщения аудита регистрации и пользовательские сообщения (если сравнивать с операционной системой, то в Windows NT/2000 события регистрируются в трех журналах — Application, Security и System)...
ASP.NET и разработка Web-приложений
Многие разработчики полагают, что технология ASP.NET является чем-то вроде продолжения ASP, т. е. что это, если так можно выразиться, перенесенная на платформу .NET версия ASP 3.0, несколько усовершенствованная и дополненная поддержкой новых языков. Подобное представление в корне неверно. ASP.NET является концептуально новой современной платформой, предназначенной для создания Web-приложений. Специалистами Microsoft в ASP.NET заложено все для того, чтобы сделать цикл разработки Web-приложения более быстрым, а поддержку — более простой...
XML-акселераторы помогают Web-серверам
Традиционные сетевые акселераторы ускоряют сетевые приложения за счет перемещения информационного наполнения ближе к пользователям, как это происходит в случае локального или глобального кэширования, или за счет освобождения серверов от заботы функций шифрования, как в случае с SSL-акселераторами. Однако все более широкое использование столь динамичных XML-документов в приложениях для администраторов сетей — очередной повод для беспокойства. XML — слишком «многословный» формат, который негативно влияет на производительность. Все это создает предпосылки для разработки нового вида сетевых устройств — XML-акселераторов...
Специализированные средства доставки для XML
Поставщики сетевого оборудования приступили к разработке специализированных XML-коммутаторов для поддержки чувствительных к задержкам приложений на базе Web-служб...

[Содержание]

Новые технические статьи Microsoft

PRB: SQL Server Enterprise Manager Reports That the Replication Agent Is Suspect
PRB: SQL Server 2000 Enterprise Manager Polling May Cause ClientToken Errors in the Cluster Log File
INF: Using Extended Stored Procedures or SP_OA Stored Procedures to Load CLR in SQL Server Is Not Supported
INF: SQL Server 7.0 Security Update for Service Pack 4
INF: SQL Server 2000 Security Update for Service Pack 2
HOW TO: Use Replication with MSDE
HOW TO: Update SQL Server Data by Using XML Updategrams
HOW TO: Troubleshoot Error 15401
HOW TO: Troubleshoot DTS Packages That You Run from Visual Basic Applications
FIX: The Distribution Agent Might Shut Down with a Syntax Error or Queued Updating Subscribers Might Become Unsynchronized
FIX: The Distribution Agent May Fail After You Add an Article to an Existing Transactional Publication
FIX: Error Message: "The specified index already exists" May Occur When Re-initializing Subscription with SQL Server CE Edition
FIX: Dialog Box Opens During Backup Process Prompting You To Insert Disk in Drive A
BUG: Turning On the 'Force Protocol Encryption' Option Is Irreversible If There Is No Certificate

[Содержание]

ФОРУМ SQL.RU

Самые популярные темы недели

Ошибка синтаксиса. ASP+SQL [new]
Симпатичная блондинка ищет общения с умными Гуру
Установка EM
Как защитить исходники?
База данных - хранилище объектов.
perenos iz Dev db to Production db [new]
Проблемы с merge репликацией [new]
Подскажите с репликацией
Как Microsoft определяет версии
Киньте в меня примером разночитаемого запроса с OUTER JOIN по сравнению с *=
Как сделать из GETDATE()
Размер блока под Лог
Сохранение в файл результата запроса
XML в RDBMS: есть ли смысл?
Stop SQL Server
Не работает: exec master .. xp_cmdshell 'c:\temp\qq.exe'
Поиск в SP [new]
Запись кириллицы в SQL Server
Ну вот оно и случилось !!!! Msg 605 :-((((
Перенос базы с логинами [new]
Помогите написать запрос (маленькая поправочка).
генератор ID для нескольких таблиц
Подайте идейку по фильтрации [new]
Перенос Access БД в SQL с помощью DTS
Raiserror ?
выдача имён приложению
Сохранение output потока в файл [new]
SQL & CITRIX
Други подскажите плз. с запросом
Схема БД + сохранение комментариев
Стартует ли сервис MSSQLServer у кого-нибудь в MSDE? [new]
Дерево. Большое и сложное. Как?
ЕМ к себе не пускает
IMAGE во вложенном запросе

[Содержание]

Вопросы остались без ответа

LinkedServer [new]
Невозможно редактировать записи во внешней базе?
И опять OPENROWSET и DBF
Роль на исполнение всех пользовательских процедур?
Cognos&MSSQL2000
Хелп: Грид eXpressQuantumGrid
Параметры Alert для Joba
Как прилинковать Oracl'a к 7-му сиквелу?
Барахлят сервисы
Чё за прикол?

[Содержание]

ИНФОРМАЦИЯ АВТОРА РАССЫЛКИ

В настоящее время я рассматриваю варианты своего участия в новых проектах. Интерес представляют крупные системы баз данных, как развивающиеся, так и разрабатывающиеся "с нуля". Если Ваша организациия находиться в Москве или ближайшем подмосковье и нуждается в услугах MS SQL Server DBA, предлагаю рассмотреть моё резюме, которое всегда доступно по этой ссылке: http://www.sql.ru/subscribe/REZUME.shtml

[Содержание]