Встановлення служб SQL Server R Services (у базі даних). Перевірка роботи агента SQL Server. Застосування SQL Server Service Manager

Досить часто у розробників клієнт-серверних додатківвиникає необхідність організувати певний механізм, що дозволяє за подією на SQL-сервері повідомити того чи іншого клієнта. Ще частіше це є рожево-блакитною мрією замовника, щоб розробник реалізував такий механізм. Наприклад, при перевищенні лімітів відвантаження будь-якому споживачеві повинні бути негайно повідомлені менеджери, які працюють із цим споживачем. Деякі замовники систем вимагають (а мріють про це всі замовники без винятку), щоб при зміні даних, в інших користувачів системи ця інформація автоматично оновлювалася, причому негайно. Тут не обговорюватиметься доцільність такої вимоги (вона має багато підстав для критики), тут обговорюватимуться лише шляхи вирішення. microsoft sql-сервер має штатний засібдля організацій повідомлень - alerts, але цей засіб має дуже обмежене застосування, що, за великим рахунком, не дає можливість створити на його основі гарантовано працюючий механізм. І ось чому: Зв'язок з клієнтською програмою може бути здійснений шляхом надсилання e-mail або емуляцією посилки. net sendІ те, й інше незручно для отримання повідомлення.

Засіб e-mail незручний через:

a) немає гарантії доставки, пошта може губитися.
b) пошта може "застрягти" на проміжних вузлах.
c) потрібна обов'язково наявність протоколу tcp/ip
d) потрібна наявність smtp-сервера та налаштування поштового профілю.
e) потрібне особливе налаштування sql-сервера, щоб він міг надсилати листи.
f) потрібна наявність у кожного клієнта, що чекає на події, поштової скриньки.
g) у клієнтській програмі потрібно організувати поштового клієнта.

Здійснення шляхом «net send» незручне з наступних причин:

a) немає гарантії доставки, оскільки це організовано через mailslot, що не має такої гарантії.
b) потрібна наявність коректного дозволу імен netbios в мережі.
c) потрібна наявність на клієнті "Клієнт для мереж Мікрософт".
d) задіяний стандартний mailslot, це може мати перетин з іншими програмами.

І загалом засіб alerts незручно необхідністю реєстрації кожного клієнта як оператора і відповідним настроюванням. Тобто. для найпростіших випадків alerts можна застосувати. Але для більшості випадків воно не застосовується.

Відомі реалізації та концепції

Широкому загалу відомі кілька варіантів реалізації механізму повідомлення сервером клієнта. Це:

1. Створення об'єкта (extended stored procedure чи activex), з якого sql-сервер повідомляє клієнта через сокети tcp/ip. У цьому клієнті організована прослуховування, тобто. клієнтська програма стала сервером TCP/IP.
Недоліки цього:
a) Прив'язка до протоколу tcp/ip. У мережі, де використовується тільки ipx, netbeui або appletalk, такий механізм не застосувати.
b) Немає асинхронності. Якщо ця подія генерується із тригера, будуть проблеми продуктивності.

2. Створення об'єкта (extended stored procedure чи activex), з якого sql-сервер повідомляє клієнта через named pipes чи mailslots. При цьому на клієнті організовано прослуховування того чи іншого.
Недоліки цього:
a) потрібна наявність коректного дозволу імен netbios в мережі.
b) потрібна наявність на клієнті "Клієнт для мереж Мікрософт".
c) у разі використання mailslot немає гарантії доставки.
d) у разі використання named pipes це не можна застосувати на клієнтських комп'ютерахз операційною системою windows 95/98/me, так як named pipe можна створити тільки в операційній системіна архітектурі nt.
e) Немає асинхронності. Якщо ця подія генерується із тригера, будуть проблеми продуктивності.

3. Періодичний опитування sql-сервера клієнтом (періодичне читання спеціальної таблички евентів). Це дуже простий шлях, але вільний від більшості перелічених вище недоліків. На жаль, цей метод має свої специфічні 2 недоліки: a) отримання повідомлення може бути затримано на величину таймауту опитування і b) при маленькому таймауті виникає суттєвий трафік. Тим не менш, при невеликій кількості сесій, цей метод цілком придатний і незаслужено обійдений увагою.

Пропонований варіант рішення

Вашій увазі пропонується варіант вирішення проблеми, вільний від перерахованих вище (всіх перелічених!) проблем, але разом з тим досить простий. Ідея така: на сервер міститься якийсь двійковий об'єкт, який sql-сервер може викликати (а це може бути тільки extended stored procedure або activex-об'єкт), що має два невзаємопов'язані методи.
Перший метод створює за допомогою функції win32api createevent об'єкт ядра win32, що називається "event" з унікальним найменуванням, переданим параметром. Далі викликається функція win32api waitforsingleobject, наткнувшись на яку, потік зупиняється і стоїть в очікуванні, поки цей об'єкт ядра не засигналить. Звертаю вашу увагу на той факт, що таких об'єктів ядра може бути створено скільки завгодно. Це обмежено лише кількістю хендлів у системі.
Другий метод викликає об'єкт ядра event на ім'я, заданим параметром, за допомогою функції win32api setevent і виставляє йому властивість "signaled". Як тільки це станеться, потік з першим методом прокидається і повертає управління викликав процесу. Другий метод, не очікує результату, а повертає управління своєму викликав процесу відразу ж після виставлення властивості "signaled". У такий спосіб досягається асинхронність.
Тепер залишається тільки зробити збережені процедури t-sql, що керують цим об'єктом і потрібна функціональність "у нас у кишені". Клієнтська програма в окремому потоці запускає збережену процедуру очікування події, передаючи параметром унікальну ознаку-адресу. Це може бути ім'я користувача, ім'я комп'ютера, і будь-який рядок. Головне, щоб це був унікальний ідентифікатор у межах клієнт-серверної системи. Збережена процедура поверне результат лише у випадку, якщо для цього адресата буде згенеровано подію. При отриманні події процедура перезапускається. При закритті програми потік очікування події просто прибивається через terminatethread.
На перший погляд ця методу має "жахливий" недолік - існує постійний коннект з sql-сервером, який більшу частину часу нічого не робить. Але це лише перше враження. Насправді задіяні ресурси тут лише на підтримку коннекту — це кілька кілобайт на сесію. І все! Більше ніяких відчутних ресурсів не витрачатися, особливо на тлі переваг, описаних нижче. Про додаткові ліцензіїможна також не турбуватися, якщо вибрано модель ліцензування "per server". У цьому випадку з однієї машини може бути скільки завгодно коннектів до sql-серверу, це все одно буде займати одну клієнтську ліцензію.

Готове рішення

Рішення складається з activex-об'єкта у вигляді файлу algoevt.dll і двох процедур spwaitforevent і spraiseevent. Перед використанням цей файл потрібно помістити на сервер та зареєструвати activex-об'єкт за допомогою системної утиліти regsvr32.exe. Далі вся робота проводитиметься через процедури, що зберігаються. У готове рішенняреалізована дещо більша функціональність, ніж у описаній концепції. Крім самого факту події, можна передати довільну інформацію у вигляді рядка в розмірі до 250 символів. Кожна процедура має два параметри. Перша — це унікальна ідентифікатор-адреса, про яку йшлося вище, а другий параметр — додаткова інформація, що передається. spwaitforevent треба викликати з клієнта з окремого потоку (пріоритет потоку можна вибрати найнижчий). При отриманні події процедуру треба перезапустити. Тайм-аут виконання запиту треба поставити нескінченний.

Отже, у продовженні теми обслуговування баз 1С придивимося до системи управління реляційними базамиданих Microsoft SQL Server. Цей продукт надає нам великі можливостіобробки, зберігання, резервування та відновлення баз. Я почну невеликий цикл статей, присвячених цій темі. Все, що буде написано нижче, є особистою думкою щодо даному питаннюта підлягає критиці.

У цій статті розглянуто процес створення планів обслуговування баз. Повідомлення оператора, а також приклад відновлення бази розглянемо в наступних статтях.

У тестовій лабораторії у нас таке:

Сервер Windows Server 2008 Enterprise: SRV-1C-TEST.
Microsoft SQL Server 2008: SRV-1C-TEST.
Тестова база BuhFirma.

Як завжди, поставимо собі завдання:

Проводити обслуговування бази в період 00:30 - 01:00, при цьому обслуговування не повинно бути помітним (або помітним) для користувачів бази.

Почнемо з важливих моментів. MS SQL база даних може мати один із трьох типів моделі відновлення:

Проста.
Повна.
З неповним протоколюванням.

Також при резервному копіюванні нам надається на вибір три варіанти копіювання:

Повне.
Різнинне.
Копіювання журналу транзакцій (логів).

При повному варіантікопіювання відбувається збереження бази mdfта журналу транзакцій. Різнинне копіювання (по-іншому диференціальне) здійснює копіювання даних, що змінилися з моменту створення останньої повної резервної копії. Копіювання журналу транзакцій відповідно здійснює збереження лише самого журналу транзакцій.

При виборі простої моделі відновити базу даних можна з моменту створення останньої різної або повної резервної копії. При виборі повної моделі відновлення ми можемо відновлювати базу до хвилини, створивши повну резервну копію, наприклад вночі, і протягом дня створювати копії журналу транзакції. Нижче ми побачимо де спливає цей момент. Хотілося також навести деякі витримки з MSDN: "Модель відновлення з неповним протоколюванням призначена виключно як доповнення до моделі повного відновлення. У загальному випадку модель відновлення з неповним протоколюванням схожа на модель повного відновлення, за винятком того, що протоколювання більшості масових операцій у ній проводиться мінімальною мірою.

Модель відновлення своєї бази ви можете подивитися, зайшовши у властивості бази даних, наприклад BuhFirmaта перейшовши на рядок - Параметри.

У MSSQL 2008 за промовчанням у створених базах даних модель відновлення Повна.

Як вибрати модель відновлення? Треба лише відповісти на запитання: чи втрата інформації смертельна за час, що минув після повного резервного копіювання? Якщо так, тоді вибираємо повну модель відновлення, якщо ні, просту. Модель із неповним протоколюванням варто застосовувати лише на час масових операцій у БД.

Таким чином, якщо ви обрали просту модель, то відновити дані ви зможете тільки на момент нічного повного чи різницевого копіювання, а всю інформацію після цього користувачі відновлюватимуть вручну. Вибираючи Повну модель, Ви обов'язково повинні робити резервне копіювання журналу транзакцій, інакше логи сильно зростатимуть. За будь-якої моделі відновлення ви завжди повинні мати повну резервну копію.

На початку створимо нічний план обслуговування бази, який включатиме послідовність наступних дій:

Перевірка цілісності бази
Перебудова індексу
Оновлення статистики
Очищення процедурного кешу СУБД
Резервне копіювання бази даних
Очищення після обслуговування
Очищення журналу

Для цього підключимося до MSSQL сервера за допомогою середовища Microsoft SQLServer Management Studio . Запустити середу можна перейшовши в Пуск - Усі програми - Microsoft SQL Server 2008.

Підключимося з серверу SQLі перейдемо в Управління - Плани обслуговування. Клацніть правою кнопкоюпо Плани обслуговування та оберемо Створити план обслуговування. Дамо йому ім'я: SRV1CTEST.

Перед нами вікно SRV1CTEST, в якому ми й створюватимемо послідовність дій, позначених раніше. Відразу бачимо, що з'явилася Вкладений_План1. Праворуч від назви вкладеного плану ви побачите іконку як таблички. Натискаємо на неї та потрапляємо у властивості розкладу завдання. Тут можна змінювати назву вкладеного плану, виставити частоту повторення в Щоднята встановити час. І так тепер лишилося наповнити наш план завданнями. Для цього з Панелі інструментів, яка знаходиться справа боку, перетягуємо завдання.

Почнемо з Перевірка цілісності бази даних.

Після того, як ви перетягнули завдання, клацніть двічі. Відкриється вікно, у якому у рядку Бази даних ми вибираємо створену нашу базу BuhFirma. Далі таким же чином додаємо завдання Перебудова індексуі Оновлення статистики, не забувши вибрати в них потрібну базуданих.

Процедура Перебудова індексуперетворює індекс із новим коефіцієнтом заповнення. За рахунок цього ми збільшуємо продуктивність роботи у БД.

Завдання Оновлення статистикионовлює відомості про дані таблиці для MS SQL. Що також підвищує продуктивність. Але після цієї операції потрібно обов'язково проводити очищення кешу.

Поки що зупинимося і поговоримо про налаштування зв'язків між завданнями. Зв'язки відбивають послідовність виконання. Щоб провести зв'язок між завданнями треба натиснути один раз на завдання і побачите стрілку, що з'явилася. Її треба перетягнути наступне завдання. У зв'язку може бути 3 кольори: синій, зелений та червоний, кожен з яких означає три типи спрацьовування переходу: при простому завершенні попереднього завдання - Завершення, у разі успішного завершення - Успіх, а у разі виникнення помилки під час виконання попереднього завдання - Помилка. Всі ці параметри можна побачити, натиснувши правою кнопкою миші на проведену між завданнями стрілку. Таким чином, якщо нам треба, щоб Перебудова індексуспрацювало лише після успішного завершення завдання Перевірка цілісності бази данихми повинні зв'язати їх стрілкою. Натиснувши правою кнопкою миші на стрілку, змінимо її режим на УспішноЯк бачимо, її колір змінився на зелений.

на Наразіми маємо 3 створені завдання у нашому вкладеному плані. Як ви могли помітити, завдання Очищення процедурного кеша СУБД в панелі елементів немає. Ми скористаємося завданням Виконання інструкції T-SQL . Перетягнемо її в план, і клацнемо на ній двічі. Ми бачимо вікно, в яке впишемо наступне:

DBCC FREEPROCCACHE

Ми порівнювали ціни при використанні сервісів звітів, які доступні як сервіс у Microsoft Azure(SQL Reporting), з варіантом розгортання звичайної віртуальної машини із SQL Server (SSRS).
Знову ж таки, я не беруся стверджувати, що один сервіс кращий чи гірший. У більшості випадків рішення про те, який із сервісів використовувати у додатку, необхідно приймати згідно з тими завданнями, які стоять перед додатком, та фінансовими вимогамизамовника. Я хочу показати, що для побудови рішення з використанням сервісів звітів є два шляхи.

Варіанти використання

Припустимо, що наша програма працює в Microsoft Azure і реалізована як Cloud Service (PaaS). Воно використовує як джерело даних базу даних SQL Azure. Необхідно налаштувати послуги побудови звітів для використання в додатку. Як було розглянуто раніше, послуги побудови звітів для програми Microsoft Azure можуть бути побудовані двома способами:

PaaS: SQL Azure + SQL Reporting;

SQL Reporting буде використано як сервіс.
Гібридне рішення: SQL Azure + SQL Server Reporting Services;
SQL Azure буде використано як сервіс;
SQL Reporting Services повинні бути налаштовані на окремому віртуальній машині SQL Server (IaaS).

Давайте подивимося на детальний процес налаштування обох сервісів. Однак перш ніж ми почнемо, я припускаю, що база даних SQL Azure вже налаштована та розміщена в Microsoft Azure.

Варіант PaaS: SQL Azure + SQL Reporting

Налаштування SQL Reporting сервісу

Налаштування проекту звітів

Гібридне рішення: SQL Azure + SQL Server Reporting Services

Створення віртуальної машини

Налаштування SQL Server

Netsh advfirewall firewall add rule name="SQL Server 1433" dir=in action=allow protocol=TCP localport=1433 netsh advfirewall

Налаштування Reporting Services

Налаштування Microsoft Azure Firewall

Висновок

Після виконання всіх дій SQL Server Reporting Services будуть доступні за URL, вказаною під час створення віртуальної машини:
http://.cloudapp.net/ReportServer

Використовуйте цей URL як значення властивості “TargetServerURL” під час публікації проекту звітів через SQL Server Business Intelligent Development Studio.

Цей матеріал написаний учасником спільноти. У статті представлена думка автора, яка може не співпадати з думкою корпорації Microsoft. Microsoft не несе відповідальності за проблеми в роботі апаратного або програмного забезпечення, які могли б виникнути після використання матеріалів цієї статті.

У MS SQL Server є кілька системних базданих:

master— У цій базі даних зберігаються усі дані системного рівнядля екземпляра SQL Server.

Model— Використовується як шаблон для всіх баз даних, які створюються в екземплярі SQL Server. Зміна розміру, параметрів сортування, моделі відновлення та інших параметрів бази даних model призводить до зміни відповідних параметрів усіх баз даних, що створюються після зміни.
Msdb— Використовується агентом SQL Server для планування попереджень та завдань, також є сховищем пакетів SSIS, сховищем інформації з резервного копіювання.
tempdb— База даних для тимчасових об'єктів або проміжних результуючих наборів.
Resource— База даних лише для читання. Містить системні об'єкти, які входять до складу SQL Server. Системні об'єкти фізично зберігаються у базі даних Resource, але логічно відображаються у схемі sys будь-якої бази даних.

Завданням обслуговування даних баз даних є можливість відновлення даних баз даних під час їх пошкодження, невдалого оновлення, Виходу з ладу обладнання та інших можливих проблем.

Типові завдання обслуговування для системних баз даних (за винятком БД TempDb та resource):

— Створення резервної копії баз даних (з глибиною зберігання щонайменше 7 днів)

- Перевірка цілісності баз даних інструкцією DBCC CHECKDB

Всі ці операції можна завернути в завдання sql agent-а і виконувати щодня, благо обсяг даних баз даних зазвичай невеликий, то й операції проходять досить швидко, а спокій додає).

Але це ще не все, на базі даних msdb я хотів би детальніше зупинитися, до типових вищевказаних завдань додаються специфічні завдання обслуговування msdb.

Як відомо, у базі даних msdb зберігається історія резервних копій баз даних. Тепер уявімо сервер, у якого баз даних більше 50, кожні 10-15 хвилин проходить створення резервного копіювання файлу транзакцій, який обсяг буде таблиць з цією інформацією?

На одному місці роботи, коли я тільки туди прийшов, на сервері було більше 70 баз даних, серверу було більше 2,5 років і інформація з резервного копіювання ніколи не чистилася, в результаті обсяг бази даних msdb був понад 20 Гб! А це вже зовсім інший час і для створення резервної копії баз даних і для перевірки цілісності самої бази даних, і зайва дискова активність плюс час відновлення при аварії, в результаті маємо повно мінусів, які ми можемо спокійно вирішити.

Очищення історії резервного копіювання здійснюється через процедуру:

sp_delete_backuphistory [ @oldest_date = ] ‘oldest_date’

[ @oldest_date = ] ‘oldest_date’
Сама рання дата, збережена в таблицях журналу резервного копіювання та відновлення. Аргумент oldest_date має тип datetimeі не має значення за умовчанням
Одну інформацію почистили, що там ще зберігається?!

Пошта. Чи налаштований у вас Database Mail і чи надсилається листи, а якщо ще з вкладеннями листа?

Вся історія щодо нього так само зберігається в базі даних msdb. Для очищення цієї історії також є системні процедури:

sysmail_delete_mailitems_sp[ [ @sent_before = ] ‘sent_before’ ] [ , [ @sent_status = ] ‘sent_status’ ]

де
[ @sent_before = ] ‘sent_before’
Видаляє повідомлення електронної поштидо дати та часу, вказаних аргументом sent_before. Аргумент sent_before має тип datetime і не має значення за умовчанням. Значення NULLвідповідає всім дат.

[ @sent_status = ] ‘sent_status’

Видаляє повідомлення електронної пошти, тип яких вказаний аргументом sent_status. Аргумент sent_status має тип varchar(8) і немає значення за умовчанням. Допустимі значення: sent, unsent, retrying та failed. Значення NULL відповідає всім станам.

sysmail_delete_log_sp[ [ @logged_before = ] ‘logged_before’ ] [, [ @event_type = ] ‘event_type’ ]

[ @logged_before = ] ‘logged_before’

Видаляє записи аж до дати та часу, вказаних у аргументі logged_before. Аргумент logged_before має тип datetime і значення замовчуванням NULL. Значення NULL відповідає всім датам.

[ @event_type = ] 'event_type'

Видаляє журнальні записи певного типу, Заданого аргументом event_type. Аргумент event_type має тип varchar(15) і немає значення за умовчанням. Допустимі записи: success, warning, error та informational. NULL відповідає всім типам подій.

З поштою ми вирішили, видалив стару інформаціющо ще може бути там?

А чи є у вас пакети SSIS і як часто вони запускаються? Історія їх виконання зберігається в таблиці ...

Для очищення її налаштована проста інструкція:

FROM .. where starttime<@dt

Де @dt – дата, записи якої слід видалити.

Після цього вище зазначені операції:

- Видалення історії резервного копіювання
— очищення журналу Database Mail
- Очистка таблиці історії ..

Ми загортаємо в ms sql agent завдання та запускаємо пару разів на місяць, і в результаті маємо наші компактні системні бази даних:).

Частина даних операцій реалізуються автоматично під час створення Maintenance Plans, але я їх рідко використовую, тому я завжди маю скрипт завдання обслуговування системних баз даних, який просто розгортаю на новому сервері при налаштуванні.

Можливо щось пропустив, тож буду радий коментарям.

Будьте обережні, тримайте робоче місце в чистоті!:).

Анотація: Керувати службами SQL Server – справа дуже тонка і потребує специфічних знань про принципи роботи компонентів служби: – SQL Server Agent, Microsoft Distributed Transaction Coordinator та Microsoft Search. Розглядаються доступ до параметрів системи, що часто змінюються. Інструментальні засоби SQL Server Service Manager, SQL Server Enterprise Manager та Windows 2000 Service Control Manager дозволяють розширити можливості керування службами. Наведено примітки, які захищають адміністраторів від некоректних дій.

Встановивши Microsoft SQL Server 2000, можна почати ним користуватися. Але перш ніж ви зможете входити в систему і почнете будувати свою базу даних, потрібно навчитися запускати службу SQL Serverта її компоненти – SQL Server Agent, Microsoft Distributed Transaction Coordinatorі Microsoft Search. Ці компоненти, описані в цій лекції, виконуються як окремі служби, які доповнюють SQL Server . У цій лекції ми також розповімо, як запускати, зупиняти та керувати цими службами за допомогою трьох інструментальних засобів – і .

Примітка. У цій лекції наголошується на описі роботи SQL Server 2000 в операційній системі Microsoft Windows 2000, хоча SQL Server 2000 може працювати і в Microsoft Windows NT 4. В операційній системі Microsoft Windows 98 SQL Server запускається як виконуваний файл, тому що Windows 98 не підтримує служби.

Важливо, щоб ви навчилися керувати SQL Server 2000 за допомогою Enterprise Manager. Зверніть увагу, що ця лекція дає лише коротке знайомство з Enterprise Manager. Багато завдань, які вирішуються за допомогою Enterprise Manager, будуть розглянуті в наступних лекціях. Це, наприклад, такі завдання, як створення баз даних та об'єктів, конфігуруванняналаштувань сервера, конфігуруванняреплікації та управління реплікацією, управління резервним копіюванням. А в іншій лекції основна увага буде приділена застосуванню Enterprise Manager для керування SQL Server та іншими службами.

Служби SQL Server

Служба– це програма або процес, який виконує специфічні функції підтримки інших програм. Коли ви запускаєте SQL Server, в операційній системі Windows NT або Windows 2000 запускається служба SQL Server. Ця служба керує файлами баз даних, виконує оператори Transact-SQL (T-SQL) , розподіляє ресурси серед з'єднань, що виконуються одночасно, перевіряє несуперечність даних і виконує ще багато інших завдань. Якщо ви інсталюєте один або кілька екземплярів SQL Server, служби для окремих екземплярів SQL Server будуть мати імена MSSQL$Ім'яЕкземпляра, де Ім'яЕкземпляра – ім'я примірника, призначене вами при інсталяції. Відповідно, служби SQL Server Agent для екземплярів SQL Server матимуть імена SQLAGENT$Ім'яЕкземпляра. Однак для всіх екземплярів SQL Server буде лише по одній інсталяції Microsoft Distributed Transaction Coordinator та Microsoft Search.

Програмні компоненти цих трьох служб ви отримуєте в рамках ліцензії на копію SQL Server. Інсталяція SQL Server Agent проводиться за умовчанням під час інсталяції SQL Server. Якщо у вас не інстальовано Microsoft Distributed Transaction Coordinator і Microsoft Search, ви можете знову запустити інсталяційну програму SQL Server, щоб встановити ці компоненти, які мають там назви DTC Client Supportі Full-Text Searchвідповідно. А зараз ми розповімо, що робить кожна із цих трьох служб.

SQL Server Agentздійснює планування та виконання завдань, оповіщень, сповіщень та планів обслуговування бази даних. Без цієї служби робота адміністратора баз даних стане набагато складнішою, а може взагалі неможливою. Завдяки SQL Server Agent можна автоматизувати рутинні процедури обслуговування бази даних. Наприклад, ви можете створити завдання, яке автоматично виконуватиме резервне копіювання бази данихщодобово о 1 годині півночі, та інше завдання, яке автоматично виконуватиме резервне копіювання журналу транзакцій кожні півгодини. Щоб стежити за продуктивністю вашої системи, можна створити сповіщення про стан продуктивності, яке інформуватиме вас, якщо завантаженість центрального процесора сервера перевищить 90%. Для вирішення таких завдань потрібно запускати службу SQL Server Agent, яку можна налаштувати на автоматичний запуск під час запуску SQL Server, а можна запускати і вручну. Вам слід налаштувати її на автоматичний запуск, що гарантуватиме виконання ваших запланованих завдань, оповіщень та сповіщень. В "Адміністрація Microsoft SQL Server" буде розказано, як створити план обслуговування бази даних, а в "Автоматизація адміністративних завдань" - як за допомогою SQL Server Agent призначати завдання, оповіщення та сповіщення.

Microsoft Distributed Transaction Coordinator- це адміністратор транзакцій (transaction manager), за допомогою якого в транзакції ваших програм можна включати дані з різних джерел, у тому числі дані з баз даних з віддалених комп'ютерів. Це означає, що з допомогою однієї транзакції можна оновлювати дані багатьох серверах, доступних через мережу. Адміністратор транзакцій гарантує, що всі оновлення стануть постійними для всіх джерел даних (якщо транзакція зафіксована) або, у разі помилки, що для всіх джерел даних буде здійснено відкат усіх змін. (Про адміністратора транзакцій Microsoft Distributed Transaction Coordinator див. "Служби компонентів та Microsoft Distributed Transaction Coordinator" .)

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

Як ми вже говорили, є кілька інструментальних засобів для зупинки та запуску служб SQL Server: SQL Server Service Manager, SQL Server Enterprise Managerі Windows 2000 Service Control Manager. Давайте спочатку розглянемо, за допомогою якого можна керувати службами SQL Server, SQL Server Agent, Microsoft Distributed Transaction Coordinatorі Microsoft Search.