SQL Server 2000 [ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати. скачати <170> Введення. 2 Коротка характеристика редакції 8 SQL Server 2000 8 Developer Edition 9 Enterprise Evaluation Edition 9 Можливості редакцій 10 Апаратні вимоги 10 Взаємодія з операційними системами 11 Взаємодія з програмним забезпеченням Інтернету 12 Планування конфігурації сервера 13 Вибір зіставлення 14 Вибір методу установки 16 Автоматична установка 18 Створення облікових записів 19 Вибір типу установки 23 Встановлення мережних бібліотек і протоколів 25 Встановлення мережних протоколів в Windows 2000 25 Мережева бібліотека Опис 26 Встановлення та конфігурування клієнтів 27 Запуск, зупинка і припинення служб 29 Автоматичний старт 30 Ручний запуск SQL Server 1931 Запуск SQL Server в одного користувача режимі 32 Запуск SQL Server з мінімальними вимогами 32 Додаткові режими запуску 33 Призупинення SQL Server 1934 Зупинка SQL Server 1934 Правила Безпеки 35 Загальні правила розмежування доступу 36 Архітектура системи безпеки SQL Server 2000 1937 Режими аутентифікації 37 Режим аутентифікації SQL Server 1938 Компоненти структури безпеки 39 Користувачі 40 Ролі сервера 42 Ролі баз даних 42 Ролі докладання 44 Захист даних 45 Шифрування даних 45 Обмеження доступу до файлів SQL Server 1946 Права доступу 46 Права на доступ до об'єктів баз даних 47 Заборона доступу 49 Створення та обслуговування баз даних 50 Використання неформатованих розділів 51 Збільшення бази даних 53 Використання Transact-SQL 53 Створення баз даних 53 Управління базами даних 57 Зменшення розміру бази даних 60 Управління властивостями бази даних 64 Приєднання і від'єднання бази даних 67 Передача прав володіння 68 Зміна імені бази даних 69 Перегляд властивостей бази даних 69 Видалення бази даних 76 Управління користувацькими типами даних 76 Керування правилами 79 Управління умовчання 80 Список літератури 84 Введення. SQL Server 2000 є досить складним продуктом, роботу з яким можна розглядати з різних сторін. Зокрема, можна виділити два основні розділи роботи з сервером, кожен з яких при найближчому розгляді може бути легко розділений на більш дрібні блоки: Про адміністрування; Про програмування. Адміністрування SQL Server 2000 в свою чергу можна розділити на дві частини: адміністрування власне сервера і адміністрування баз даних. Таким чином, адміністрування баз даних являє собою окрему область роботи з SQL Server 2000. Воно включає розробку структури бази даних, її реалізацію, проектування системи безпеки, створення користувачів бази даних, надання їм прав доступу, створення об'єктів і т. д. Крім того, адміністратор бази даних повинен періодично створювати резервні копії, перевірку цілісності даних і стежити за розміром файлів, як самої бази даних, так і журналу транзакцій. Вказаний список можна легко продовжити, тому що ми перерахували далеко не всі завдання адміністрування. Перше завдання, яке постає перед адміністратором або розробником, це проектування структури бази даних. Невірно спроектована база даних згодом доставить багато клопоту як адміністратору, так і програмістам і користувачам. Тому необхідно відповідально поставитися до розробки бази даних, відразу ж продумуючи різні варіанти використання даних, а також можливості інтеграції з додатковими системами і доступу до даних за допомогою різних технологій. Існує безліч технологій і методів розробки баз даних, розгляд яких гідно окремої книги. Для більш детального знайомства з теорією реляційних баз даних і побудовою баз даних з використанням ER-діаграм необхідно звернутися до спеціалізованої літератури, присвяченої цим питанням. Для розуміння теорії реляційних баз даних, яка є домінуючою в даний час, необхідно добре знання математики, тому що в основі реляційної моделі даних лежать математичні об'єкти. ... ,, Зауважу, що літератури російською мовою, присвяченій теоретичним основам систем управління базами даних, дуже мало. Основні праці по цій темі були написані понад 10 років тому, але продовжують залишатися актуальними до цього дня. У широкому сенсі слова база даних - це сукупність відомостей про конкретні об'єкти реального світу в будь-якої предметної області. Під предметною областю прийнято розуміти частину реального світу, що підлягає вивченню для організації управління і, в кінцевому рахунку, автоматизації. Прикладом може служити підприємство, вуз і т.д. Створюючи базу даних, користувач прагне впорядкувати інформацію за різними ознаками і швидко знаходити потрібні відомості з довільним поєднанням ознак. Зробити це можна, тільки якщо дані структуровані. База даних - пойменована сукупність взаємопов'язаних даних, що знаходяться під управлінням системи управління базами даних (СКБД). СУБД - це комплекс програмних і мовних засобів, необхідних для створення баз даних, підтримання їх в актуальному стані та організації пошуку в них необхідної інформації. Основне завдання бази даних - зберігати і при необхідності представляти на першу вимогу користувачів всі необхідні дані в одному місці, виключаючи їх повторення і надмірність. Централізований характер управління даними в базі даних передбачає існування деякого особи (групи осіб), на яке покладаються функції адміністрування даних, що зберігаються в базі. Розрізняють централізовані та розподілені бази даних. Про Розподілена база даних складається з декількох частин, які зберігаються в різних ЕОМ обчислювальної мережі. Цей спосіб обробки має на увазі наявність декількох серверів, на яких може зберігатися перетинається або навіть дублирующаяся інформація. Для роботи з такою базою даних використовується система управління розподіленими базами даних (СУРБД). "Про Централізована база даних зберігається у пам'яті однієї обчислювальної системи, тобто база даних розташовується на одному комп'ютері. Якщо для цього комп'ютера встановлена ​​підтримка мережі, то безліч користувачів з клієнтських комп'ютерів можуть одночасно звертатися до інформації, що зберігається в центральній базі даних. У локальних мережах найчастіше використовується саме такий спосіб обробки даних. Системи централізованих баз даних можуть суттєво відрізнятися в залежності від їхньої архітектури. »Файл-сервер. БД розташовується на файл-сервері (або декількох файл-серверах), за який може використовуватися найбільш потужна з ПЕОМ, об'єднаних у мережу. Функції файл-сервера полягають, в основному, у зберіганні БД і забезпечення доступу до них користувачів, що працюють на різних комп'ютерах. Файли бази даних відповідно до призначених для користувача запитами передаються на робочі станції, де в основному і проводиться обробка. Передані дані обробляються СУБД, яка знаходиться знову ж на комп'ютерах користувачів. Після того як користувачі виконають необхідні зміни даних, вони копіюють файли назад на файл-сервер, де інші користувачі, у свою чергу, можуть знову їх використовувати. Крім того, кожен користувач може створювати на локальному комп'ютері свої власні бази даних, які використовуються ним монопольно. Ця схема працює при не дуже великих обсягах даних. При збільшенні числа комп'ютерів в мережі або зростанні БД продуктивність різко падає. Це пов'язано із збільшенням обсягу даних, переданих по мережі, так як вся обробка відбувається на комп'ютері користувача. Явним недоліком такого підходу є висока ймовірність втрати змін, виконаних одними користувачами, при збереженні змінених файлів на центральний сервер. Справа в тому, що користувачі можуть і не підозрювати, що крім них ще хтось змінював дані. Прикладами СУБД, призначеними безпосередньо для розробки локальних користувальницьких додатків БД, тобто додатків, що працюють на одному локальному комп'ютері або в комп'ютерній, мережі є: Microsoft Visual FoxPro, Microsoft Access, Paradox, fpr Windows, dBase for Windows і ін • Клієнт-сервер. Технологія клієнт-сервер передбачає, що крім зберігання бази даних центральний комп'ютер (сервер бази даних) має забезпечувати виконання основного обсягу обробки даних. При технології клієнт-сервер запит на виконання операції з даними (наприклад, звичайна вибірка), що видається клієнтом (робочою станцією), породжує на сервері пошук і вилучення даних. Витягнуті дані (але не файли) транспортуються по мережі від сервера до клієнта дж. Система, що використовує технологію клієнт-сервер, поділяється на дві частини: клієнтська частина (front-end) забезпечує графічний інтерфейс і стоїть на комп'ютері користувача; серверна частина (back-end), яка знаходиться на спеціально виділених комп'ютерах, забезпечує управління даними, поділ інформації , адміністрування і безпека. Прикладами СУБД технології клієнт-сервер є Microsoft SQL Server, Oracle, IBM DB2, Sybase та ін Специфікою архітектури клієнт-сервер є використання спеціальної мови структурованих запитів (Structured Query Language, SQL), що забезпечує користувача простим і ефективним інструментом доступу до даних. Крім підрозділу баз даних за методами обробки можна класифікувати їх за використовуваної моделі (або структурі) даних. Модель даних - сукупність структур даних та операцій з їх обробці. За допомогою моделі даних можна наочно уявити структуру об'єктів і встановлені між ними зв'язки. Для термінології моделей даних характерні поняття «елемент даних» та «правила зв'язування». Елемент даних описує будь-який набір даних, а правила зв'язування визначають алгоритми взаємозв'язку елементів даних. До теперішнього часу розроблено безліч різних моделей даних, але на практиці використовується три основних. Виділяють ієрархічну, мережну і реляційну моделі даних. Відповідно говорять про ієрархічних, мережевих і реляційних СУБД. Про Ієрархічна модель даних. Ієрархічно організовані дані зустрічаються в повсякденному житті дуже часто. Наприклад, структура вищого навчального закладу - це багаторівнева ієрархічна структура. Ієрархічна (деревоподібна) БД складається з упорядкованого набору елементів. У цій моделі вихідні елементи породжують інші елементи, причому ці елементи в свою чергу породжують наступні елементи. Кожен породжений елемент має тільки один породжує елемент / Організаційні структури, списки матеріалів, зміст у книгах, плани проектів та багато інших сукупності даних можуть бути представлені в ієрархічному вигляді. Автоматично підтримується цілісність посилань між предками і нащадками. Основне правило: ніякої нащадок не може існувати без свого батька. Основним недоліком даної моделі є необхідність використання тієї ієрархії, яка була закладена в основу БД при проектуванні. Потреба в постійній реорганізації даних (а часто неможливість цієї реорганізації) призвели до створення більш загальної моделі - мережевий. Про Мережева модель даних. Мережевий підхід до організації даних є розширенням ієрархічного підходу. Дана модель відрізняється від ієрархічної тим, що кожен породжений елемент може мати більше одного породжує елемента. Розглянемо предметну область для бази даних, в якій зберігається інформація про замовлення магазину. Замовники беруть напрокат фільми, використовуючи два носії: відеострічку і компакт-диски. Обслуговування замовників виконують продавці. Кожен продавець обслуговує багатьох замовників. Кожен продавець може користуватися послугами декількох магазинів і навпаки. Існує багато копій одного й того ж фільму і т. д. Оскільки мережна БД може представляти безпосередньо всі види зв'язків, властивих даними відповідної організації, за цими даними можна переміщатися, дослідити і запитувати їх всілякими способами, тобто мережева модель не пов'язана всього лише однією ієрархією. Однак для того щоб скласти запит до мережевої БД, необхідно досить глибоко вникнути в її структуру (мати під рукою схему цієї БД) і виробити механізм навігації по базі даних, що є істотним недоліком цієї моделі БД. Про Реляційна модель даних. Основна ідея реляційної моделі даних полягає в тому, щоб представити будь-який набір даних у вигляді двовимірної таблиці. У найпростішому випадку реляційна модель описує єдину двовимірну таблицю, але частіше за все ця модель описує структуру і взаємини між кількома різними таблицями. Отже, метою інформаційної системи є обробка даних про об'єкти реального світу, з урахуванням зв'язків між об'єктами. У теорії БД дані часто називають атрибутами, а об'єкти - сутностями. Об'єкт, атрибут і зв'язок - фундаментальні поняття ІС. Об'єкт (або сутність) - це щось існуюче і помітне, тобто об'єктом можна назвати те «щось», для якого існують назву і спосіб відрізняти один подібний об'єкт від іншого. Наприклад, кожна школа - це об'єкт. Об'єктами є також людина, клас у школі, фірма, сплав, хімічна сполука і т. д. Об'єктами можуть бути не тільки матеріальні предмети, але й більш абстрактні поняття, що відображають реальний світ. Наприклад, події, регіони, твори мистецтва; книги (не як поліграфічна продукція, а як твори), театральні постановки, кінофільми; правові норми, філософські теорії та ін. Атрибут (або дане) - це певний показник, який характеризує якийсь об'єкт і приймає для конкретного екземпляра об'єкта деякий числове, текстова чи інше значення. Інформаційна система оперує наборами об'єктів, спроектованими стосовно даної предметної області, використовуючи при цьому конкретні значення атрибутів (даних) тих чи інших об'єктах. Наприклад, візьмемо в якості набору об'єктів класи в школі. Число учнів у класі - це дане, яке приймає числове значення (у одного класу 28, в іншого - 32). Назва класу - це дане, що приймає текстове значення (в одного - 10А, в іншого - 9Б і т. д.). Атрибут деякого набору об'єктів сам може бути набором об'єктів, що мають власні атрибути. Наприклад, атрибутом особи (як примірника набору об'єктів «Лица») є вуз, який ця особа закінчило (МДУ, МІФІ і т. п.). З іншого боку, конкретний вуз - це екземпляр набору об'єктів «Вища освіта» і характеризується безліччю даних: прізвищем ректора, адресою, спеціалізацією, числом студентів і т.д. Нарешті, ректор в свою чергу є екземпляром набору об'єктів «Лица». Таким чином, виникає можливість встановлення зв'язку між екземплярами об'єктів з різних наборів. Розвиток реляційних баз даних розпочалося в кінці 60-х років, коли з'явилися перші роботи, в яких обговорювалися можливості використання при проектуванні баз даних звичних і природних способів подання даних - так званих табличних даталогіческіх моделей. Основоположником теорії реляційних баз даних вважається співробітник фірми IBM доктор Е. Кодд, що опублікував 6 червня 1970 статтю A Relational Model of Data for Large Shared Data Banks (Реляційна модель даних для великих колективних банків даних). У цій статті вперше був використаний термін «реляційна модель даних», що й поклало початок реляційних баз даних. Теорія реляційних баз даних, розроблена в 70-х роках в США доктором Е. Коддом, має під собою потужну математичну Основу, що описує правила ефективної організації даних. Розроблена Е. Коддом теоретична база стала основою для розробки теорії проектування баз даних. Е. Кодд, будучи математиком за освітою, запропонував використовувати для обробки даних апарат теорії множин (об'єднання, перетин, різниця, декартово твір). Він довів, що будь-який набір даних можна представити у вигляді двовимірних таблиць особливого виду, відомих у математиці як «відносини». Реляційної вважається така база даних, в якій всі дані представлені для користувача у вигляді прямокутних таблиць значень даних, і всі операції над базою даних зводяться до маніпуляцій з таблицями. Таблиця складається із стовпців (полів) та рядків (записів); має ім'я, уні ве всередині бази даних. Таблиця відображає тип об'єкта реального світу (сущ ність), а кожна її рядок-конкретний об'єкт. Так, таблиця Спортивна секція містить відомості про всіх дітей, що займаються в даній спортивній секції, а її рядки являють собою набір значень атрибутів кожного кон кретного дитини. Кожен стовпець таблиці - це сукупність значень конк дах атрибута об'єкта. Стовпець Вага, наприклад, являє собою сукупність всіх вагових категорій дітей, які займаються у секції. У стовпці Пол можуть міститися тільки два різних значення: «чоловік.» І «дружин.». Ці значення вибираються з множини всіх можливих значень атрибута об'єкта, яке називається доменом (domain). Так, значення в стовпці вибираються з множини всіх можливих ваг дітей. У найзагальнішому вигляді домен визначається завданням деякого базового 'типу даних, до якого належать елементи домену, і довільного логічного виразу, який застосовується до елементів даних. Якщо при обчисленні логічного умови щодо елемента даних у результаті отримано значення «істина», то цей елемент належить домену. У найпростішому випадку домен визначається як допустимий потенційне безліч значень одного типу. Наприклад, сукупність дат народження всіх співробітників складає «домен дат народження», а імена всіх співробітників складають «домен імен співробітників». Домен дат народження має тип даних, що дозволяє зберігати інформацію про моменти часу, а домен імен співробітників повинен мати символьний тип даних. В один домен можуть входити значення з декількох стовпців, об'єднаних, крім однакового типу даних, ще й логічно. Наприклад, домен може складатися з шпальти з датою пйступленія на роботу і стовпця з датою звільнення. Але в цей домен можна включити стовпець з датою народження, так як дата надходження або звільнення з роботи не пов'язана з датою народження. Якщо два значення беруться з одного і того ж домена, т, о можна виконувати порівняння цих двох значень. Наприклад, якщо два значення взяті з. Домену дат народження, то можна порівняти їх і визначити, хто із співробітників старше. Якщо ж значення беруться з різних доменів, то їх порівняння не допускається, так як, по всій вірогідності, воно не має сенсу. Наприклад, з порівняння імені та дати народження співробітника нічого певного не вийде. У більшості систем управління реляційними базами даних поняття домену не реалізовано.Каждий елемент даних у відношенні може бути визначений із зазначенням його адреси у форматі A [i, j], де А - елемент даних, i - рядок відносин, j - номер атрибуту відносини. Кількість атрибутів у відношенні визначає його порядок (або ступінь). Порядок відносини, наведеного в табл., Дорівнює 4. Створення та обслуговування баз даних Будь-яка база даних SQL Server 2000 складається з набору таблиць, що містять дані, і додаткових об'єктів, що створюються для обробки даних. До таких об'єктів належать, наприклад, уявлення, тригери і процедури. Дані зберігаються в таблицях відповідно до їх логічним визначенням, наприклад, дані про наявні на складі товари зберігаються в одній таблиці, а список персоналу - в іншій. SQL Server дозволяє одночасно підтримувати безліч баз даних, які можуть мати зв'язки з іншими базами даних або існувати незалежно. Перш ніж приступити до створення бази даних, необхідно чітко уявляти всі складові її частини і вміти грамотно використовувати їх. Дотримання цієї вимоги гарантує, що ваша база даних буде мати оптимальну структуру. Настійно рекомендую не створювати в системній базі даних master ніяких користувача об'єктів, хоча це і можливо. База даних master містить системні таблиці, які зберігають дані про параметри функціонування SQL Server. Тому пошкодження даних у цій базі може призвести до непередбачуваних наслідків. SQL Server 2000 пропонує кілька шляхів створення баз даних. Про Використання Enterprise Manager. Для створення бази даних за допомогою Enterprise Manager в контекстному меню папки Databases на потрібному сервері. виберіть пункт New Database (нова база даних). ; Про Використання майстра Create Database Wizard. На панелі інструментів Enterprise Manager клацніть на кнопці Run a Wizard (запустити майстра) і виберіть потрібного майстра. Про Використання Transact-SQL. Цей метод передбачає виконання команди CREATE DATABASE. Крім перерахованих методів є ще кілька способів створення баз даних, наприклад засобами SQL-DMO. Робота з цими механізмами є темою окремої книги і тут розглядатися не буде. Один сервер може підтримувати, максимум, 32 767 баз даних. Для створення бази даних необхідно вказати її назву, власника (їм буде користувач, який створює базу даних), розмір, визначити файли і групи файлів, з яких буде складатися створювана база даних. Перед створенням бази даних необхідно усвідомити такі моменти: О за замовчуванням бази даних дозволено створювати членам фіксованих ролей сервера sysadmin і dbcreator, хоча дозвіл на створення баз даних можна надавати й іншим користувачам; Про користувач, що створює базу даних, автоматично стає її власником; Про ім'я (назва) бази даних повинне відповідати правилам іменування об'єктів. Для зберігання бази даних використовується три типи файлів. Про Primary - первинний файл. Кожна база даних обов'язково має такий файл, причому тільки один. У цьому файлі зберігається системна інформація про базу даних та її об'єктах. Тут же розміщуються системні таблиці. Крім того, в первинному файлі можуть зберігатися і призначені для користувача дані. За замовчуванням цей файл має розширення. Mdf. Про Secondary - вторинний файл. Тут містяться дані користувача, що не помістилися в первинному файлі. Якщо база даних невелика й немає потреби створювати вторинні файли, то всю інформацію можна зберігати в первинному файлі. Проте якщо база даних має великі розміри, можна мати декілька вторинних файлів, причому для зручності роботи з даними ці файли можна зберігати на різних дисках. За замовчуванням вторинні файли мають розширення. Ndf. Про Transaction Log - файл журналу транзакцій. Мінімальний розмір такого файлу -512 Кбайт. База даних повинна мати, принаймні, один файл журналу транзакцій. У цьому файлі зберігатиметься інформація про транзакції, які виконуються в базі даних. За замовчуванням файлів журналу транзакцій присвоюється розширення. Idf. Відзначимо, що файл журналу транзакцій не може бути поміщений на стислий диск або віддалений мережевий диск (загальнодоступний мережевий каталог). На основі сказаного вище можна зробити висновок, що будь-яка база даних складається, принаймні, з двох файлів - одного первинного файлу даних і одного файлу журналу транзакцій. Використання неформатованих розділів SQL Server 2000 дозволяє використовувати для створення файлів бази даних так звані неформатовані (або «сирі» - raw) розділи. Неформатований розділ - це розділ диску, який був створений за допомогою утиліти fdisk (MS DOS, Windows 95/98) або Disk Administrator (Windows NT, Windows 2000), але не був відформатований. На такому розділі не існує файлової системи (FAT або NTFS), тому там неможливо зберігання файлів операційної системи. Тим не менш, якщо при створенні бази даних як фізичного імені файлу в конструкції вказати неформатований розділ, то SQL Server 2000 створить у цьому розділі блок даних (назвемо його файлом), який займе весь вільний простір. Так як при створенні файлу буде зайнято все доступне простір, то збільшення розміру файлу в даному випадку неможливо. Отже, зазначення параметрів MAXSIZE і FILEGROW не обов'язково. Також не обов'язкова вказівка ​​початкового розміру файлу. Як фізичного імені файлу необхідно вказати тільки букву розділу, наприклад F:. Завдання неформатованого розділу іншим способом (а такі є - наприклад формат, який використовується у файлі boot.ini) не допускається. Тобто, щоб мати можливість розмістити файл бази даних на неформатований розділі, потрібно присвоїти цього розділу конкретну букву, сконфігурував його, таким чином, в якості логічного диска. Отметчу, що на неформатований розділі можна розмістити лише один файл бази даних. Навіть після того як SQL Server створить в цьому розділі файл, операційна система буде сприймати розділ як неформатований або як розділ з невідомою файлової системою. Звичайні операції роботи з файлами, що виконуються операційною системою, будуть недоступні. Тобто не можна буде виконувати копіювання, видалення, зміну або переміщення створеного файлу. Крім того, операції резервного копіювання за допомогою утиліти Windows NT Backup також будуть недоступні. Однак допускається створення резервних копій бази даних і журналу транзакцій засобами SQL Server 2000. При використанні неформатованих розділів недоступні інструменти перевірки цілісності диска. Більш того, неможлива «гаряча» заміна пошкоджених кластерів, яка виконується для файлової системи NTFS на дисках SCSI. Шляхом використання неформатованих розділів можна забезпечити високий рівень безпеки інформації в базі даних. При розміщенні файлів бази даних на звичайних дисках з файловою системою завжди є можливість скопіювати ці файли і підключити до іншого сервера SQL Server 2000. Вирішити цю проблему в тій чи іншій мірі може допомогти файлова система NTFS. Якщо ж ви використовуєте файлову систему FAT, то у випадку зупинки SQL Server 2000 файли баз даних можуть бути скопійовані без жодних труднощів. Я окремо відзначив, що для копіювання файлів баз даних необхідно зупинити SQL Server 2000, а точніше, службу MSSQLServer. В іншому випадку файли баз даних блокуються і до них не вдасться отримати доступ. При наявності неформатованих розділів скопіювати дані буде практично неможливо, так як в операційних системах сімейства Windows не реалізовані механізми роботи з неформатований розділами. Якщо ви хочете забезпечити максимальну конфіденційність інформації, то можливість використання неформатованих розділів є досить потужним інструментом вирішення завдання. У цьому випадку рекомендується створити базу даних з одного файлу даних, розташованого на неформатований розділі. В ідеалі файли журналу транзакцій також можуть бути розташовані на неформатованих розділах. Проте відзначимо, що для кожного файлу бази даних буде потрібно окремий неформатований розділ. Збільшення бази даних У міру того як користувачі вносять інформацію в базу даних, кількість вільного простору в ній зменшується. Коли весь вільний простір вичерпано, сервер видає повідомлення про помилку з номером 1105. У попередніх версіях SQL Server необхідно було вручну додавати нове вільний простір в базу даних, спочатку створюючи нові пристрої або розширюючи існуючі, а потім збільшуючи саму базу даних або журнал транзакцій. Починаючи з SQL Server 7.0, реалізована можливість автоматично го збільшення розмірів бази даних (auto grow). Ця можливість реалізується на рівні файлів бази даних, для яких можна дозволити автоматичне збільшення розміру при повному заповненні бази даних. Якщо можливості автоматичного зростання вичерпані (наприклад, скінчилося вільне місце на диску або розмір файлу досяг максимальної величини) або підтримка автоматичного збільшення файлів взагалі не була задіяна, то адміністратор повинен вручну збільшити розмір бази даних (expanding database). Для цього він або збільшує розмір існуючих файлів, або створює нові файли. Це стосується як файлів самої бази даних, так і файлів журналу транзакцій. Особливу увагу адміністратор повинен приділити системної базі даних tempdb, в якій створюються всі тимчасові об'єкти. За замовчуванням максималь-, ний розмір файлів бази даних не обмежений. Тим не менш, якщо місця на диску мало, то через якийсь час можливості збільшення бази даних tempdb будуть вичерпані. Сервер не зможе створювати тимчасові об'єкти і, отже, користувачі не зможуть успішно працювати з будь-якою базою даних, розташованої на цьому сервері. Адміністратор повинен своєчасно відслідковувати наявність необхідного вільного простору і при необхідності додавати до бази даних файли, розташовані на дисках з достатньою кількістю вільного простору. Використання Transact-SQL У цій главі докладно розглядаються різні аспекти створення баз даних і управління ними в SQL Server 2000. Як вже було сказано, для праці з базами даних в SQL Server 2000 можуть бути використані різні засоби - майстер Create Database Wizard, утиліта Enterprise Manager і команди Transact-SQL. У цьому розділі ми познайомимося з створенням і зміною баз даних, а також з управлінням базами даних засобами Transact-SQL. Цей метод є найбільш складним з усіх перерахованих, але володіє максимальними можливостями. По суті, два інших методу надають всього-на-всього графічних інтерфейс для виконання відповідних системних збережених процедур. Для ефективного управління базами даних SQL Server 2000 зовсім не обов'язково віртуозно володіти системними збереженими процедурами. У більшості випадків цілком достатньо коштів, пропонованих Enterprise Manager. Тим не менш справжній професіонал повинен вміти добитися потрібного результату і в тому випадку, коли в його розпорядженні є лише прості засоби виконання запитів, а використання красивих графічних оболонок на зразок Enterprise Manager з тих чи інших причин виявляється неможливим. Створення баз даних Перше, з чим стикається адміністратор при реалізації бази даних, це її створення. Здавалося б, що може бути простіше, ніж вказати ім'я бази даних, і на цьому справа б закінчилося. Однак база даних SQL Server 2000 є досить складною структурою. Більше того, процес створення бази даних може являти собою не тільки власне створення нової бази, але і приєднання готових файлів даних. У Enterprise Manager не завжди користувачі отримують всі можливі засоби створення баз даних, пропоновані SQL Server 2000. Доступ до цих засобів забезпечують тільки команди Transact-SQL. Етапу створення безпосередньо передує фаза планування, яка включає в себе проектування складу файлів та груп файлів, з яких складатиметься база даних. Це планування фізичної частини. Невід'ємною частиною процесу створення бази даних є і планування логічної архітектури, в яку входить проектування таблиць з використанням нормалізації. Проте створення власне бази даних не вимагає попереднього проектування таблиць. Отже, почнемо розгляд роботи з базами даних з її створення. У Transact-SQL створення бази даних виконується за допомогою команди CREATE DATABASE, що має наступний синтаксис: CREATE DATABASE databasejiame [ON [PRIMARY] [<Filespec> [.... n]] [, <Filegroup> [, ... n]] ] [LOG ON {<filespec> [, ... n]}] [COLLATE collationjiame] [FOR LOAD | FOR ATTACH] Розглянемо докладно призначення кожного з аргументів. Про database_name. За допомогою цього аргументу вказується ім'я, яке буде присвоєно створюваної базі даних. При виборі імені слід слідувати загальним правилам іменування об'єктів. Якщо ім'я бази даних містить пробіли або інші неприпустимі символи, воно має бути укладена в обмежувачі (подвійні лапки або квадратні дужки). Ім'я бази даних повинне бути унікальним у межах сервера і не може перевищувати 128 символів. Якщо ім'я журналу транзакцій явно не вказано, то сервер вкорочує ім'я бази даних таким чином, щоб воно не перевищувало 123 символів. Це робиться через те, що сервер за замовчуванням використовує для імені журналу транзакцій ім'я бази даних і додає до нього в кінці символи _Log. О О N. Це ключове слово означає, що далі слідує визначення файлів бази даних. Про PRIMARY. Це ключове слово означає, що далі йде опис первинного файлу бази даних. Нагадаємо, що в цьому файлі зберігаються всі системні дані і таблиці. Тільки один файл у базі даних може бути визначений як первинний. Якщо первинний файл не визначений явно, то в цій якості буде використовуватися перший файл, вказаний в конструкції первинної груп співай файлів (primary file group). Первинна група призначається групою файлів за умовчанням (default file group), і в неї будуть включені всі файли, для яких явно не вказана користувальницька група файлів (user file group). Про LOG ON. Це ключове слово означає, що файли журналу транзакцій будуть визначені явно. Після LOG ON має слідувати визначення файлів журналу транзакцій. Якщо це ключове слово не використовується, тобто користувач не задає явно файли журналу транзакцій, то сервер автоматично створює єдиний файл розміром 25% від загальної суми розмірів файлів даних. Ім'я файлу генерується на основі імені бази даних, але в кінці до нього додаються символи _Log. Про FOR LOAD. Цей аргумент на більшою мірою для забезпечення зворотної сумісності з попередніми версіями SQL Server (до SQL Server 7.0). Він наказує сервера створити базу даних у режимі використання власником (dbo use only). Це робиться, якщо необхідно виконати відновлення бази даних з резервної копії. Справа в тому, що в ранніх версіях SQL Server відновлення бази даних було можливо тільки у вже існуючу базу даних, встановлену в режим FOR LOAD. Починаючи з SQL Server 7.0, при необхідності база даних може бути створений автоматично в ході виконання команди RESTORE. Більше того, допускається відновлення резервної копії поверх існуючої бази даних. Про FOR ATTACH. Цей аргумент використовується, коли необхідно виконати присое динения (attach) бази даних. У цьому випадку на диску вже повинні існувати файли з даними. Таким чином, створення бази даних відбувається тільки на логічному рівні - в системну таблицю sysdatabases бази даних master вносяться відповідні записи, але створення власне файлів не виконується. Для підключення бази даних буває достатньо вказати тільки розміщення первинного файлу бази даних. Інформація про місце розташування всіх інших файлів бази даних (вторинних і журналу транзакцій) зберігається у первинному файлі бази даних. Однак якщо місце розташування файлів бази даних з моменту її від'єднання змінилося, то необхідно буде вказати повний шлях до кожного файлу бази даних. Приєднання бази даних можна також виконати і за допомогою системної збереженої процедури sp_attach_db, яка безпосередньо працює з системною таблицею sysdatabases і таблицями самої бази даних, вносячи в неї необхідні зміни. Якщо приєднання бере участь у реплікації бази даних виконується не на «рідному» сервері, то необхідно видалити підтримку реплікації. Для цього використовується збережена процедура sp_removedbreplication [@ dbname =] "dbname". Про collation_name. За допомогою цього аргументу вказується зіставлення за замовчуванням для всіх об'єктів, що створюються в базі даних. Це ж зіставлення буде використовуватися і для системних таблиць. Дозволено як зіставлення Windows, так і зіставлення SQL Server. Якщо порівняння не вказується, то для бази даних буде використовуватися зіставлення, визначене на рівні сервера, тобто те зіставлення, яке було обрано при установці SQL Server 2000. Як видно з синтаксису команди CREATE TABLE і вже розглянутих аргументів цієї команди, при створенні бази даних можна визначити набір файлів, з яких буде складатися створювана база даних. Вже було сказано, що файл визначається за допомогою конструкції , Синтаксис якої наведено нижче. Ця конструкція має однаковий формат для всіх типів файлів (первинного, вторинного і журналу транзакцій). Щоб відповідний файл був первинним, перед його визначенням необхідно вказати ключове слово PRIMARY. Журнал транзакцій визначається за допомогою ключового слова LOG ON. Якщо ні одне з цих ключових слів не вказується (вказується тільки слово ON), то відповідний файл буде вторинним. Додатково файли даних можуть бути включені в групи. Це буде розглянуто декілька пізніше в цьому ж розділі. <Filespec> ([NAME = Iogica1_file_name,] FILENAME = "os_file_name" [, SIZE = size] [. MAXSIZE = {max_size | UNLIMITED}] [. FILEGROWTH = growthj increment]) [. ... N] Розглянемо призначення використовуваних аргументів. Про NAME = logical_file_name. Логічне ім'я файлу, під яким він буде орієнтуватися при виконанні різних команд Transact-SQL. Логічне ім'я файлу повинна бути унікальним в межах бази даних. Ім'я файлу журналу транзакцій не повинно збігатися з ім'ям файлу самої бази даних. Використання ключового слова NAME не потрібно, якщо виконується приєднання бази даних, однак таким чином можна вказати нове логічне ім'я для фізичного файлу. Про FILENAME = "os_f 11 e_name". Якщо за допомогою попереднього аргументу вказувалося логічне ім'я файлу, то аналізований аргумент призначений для вказівки повного шляху і назви відповідного фізичного файлу, який буде створений на жорсткому диску. Це ім'я буде мати файл на рівні операційної системи. Якщо ви скористаєтеся якою-небудь програмою перегляду диска, то після успішного виконання команди CREATE DATABASE зможете побачити файл з вказаним ім'ям. Нагадаємо, що SQL Server 2000 не дозволяє створювати файли бази даних на стиснутих томах і мережевих дисках. За замовчуванням для файлів баз даних використовуються розширення. Mdf,. Ndf і. Idf відповідно для первинного, вторинних файлів і файлів журналу транзакцій. У принципі, ви можете вказати будь-яке інше розширення, але навряд чи знайдеться серйозна причина робити це. Щоб не створювати плутанини, радимо залишати значення за замовчуванням, тобто при описі файлу не вказувати розширення. Про SIZE = size. За допомогою цього аргументу вказується початковий розмір, який буде мати відповідний файл. Розмір може бути вказаний або в мегабайтах, або в кілобайтах. Для явного завдання величини можна використовувати приставки М b і К Ь. За умовчанням вважається, що розмір задається в мегабайтах. Мінімальний розмір файлу складає 512 Кбайт. Якщо розмір файлу не вказується явно, то за замовчуванням буде створений файл розміром> 1 Мбайт. Відзначимо, що в якості розміру файлу дозволяється задавати тільки цілочисельні значення. Таким чином, якщо необхідно задати дробову кількість мегабайт, слід вказати відповідне значення в кілобайтах. Про FILEGROWTH = growth_iincrement. При описі фізичної архітектури бази даних у розділі 4 було сказано, що починаючи з SQL Server 7.0 підтримується автоматичне збільшення (auto grow) розміру бази даних, що реалізується шляхом послідовного автоматичного збільшення розмірів файлів, що входять до складу бази даних. SQL Server 2000 дозволяє контролювати величину приросту кожного з файлів бази даних окремо від інших, задаючи крок приросту не на рівні бази даних, а на рівні окремого файлу. За допомогою розглянутого аргументу задається величина приросту файлу бази даних. Крок приросту може бути вказаний як в абсолютному виразі у вигляді конкретної кількості мегабайт (М Ь) або кілобайт (Kb), так і у відносному у вигляді певного відсотка (%) від первісного розміру файлу. За умовчанням передбачається, що вказується значення в мегабайтах. Якщо аргумент FILEGROWTH опущений, то файл буде збільшуватися на 10% від початкового об'єму. Мінімальний розмір, на який може бути збільшений файл, становить 64 Кбайт. Відзначимо, що в сумі початковий розмір файлу і вибраний крок приросту не повинні перевищувати зазначений максимальний розмір файлу. Про MAXSIZE = {max_size | UNLIMITED}. Автоматичне збільшення файлів пов'язане з певними проблемами. Зокрема, якщо диск з файлом бази даних використовується для зберігання тимчасових файлів різних програм, то збільшення файлу бази даних до великого розміру може призвести до порушення працездатності додатків. Для уникнення цієї та інших подібних проблем SQL Server 2000 дозволяє обмежувати зростання файлів конкретним розміром. Для цього і потрібно розглянутий аргумент. Максимальний розмір може бути вказаний в мегабайтах (Mb-використовується за замовчуванням) або кілобайтах (Kb). Відзначимо, що обмеження зростання окремого файлу не обмежує можливість збільшення зростання всієї бази даних, так як розмір бази даних може збільшуватися за рахунок пророста інших файлів. Якщо обмежувати максимальний розмір файлу не потрібно, то необхідно вказати значення UNLIMITED або взагалі опустити аргумент MAXSIZE, так як за замовчуванням розмір файлу не обмежується, і він буде рости, поки не заповнить весь доступний простір на диску. Ми розглянули синтаксис конструкції , Яка використовується для опису файлів бази даних. Як вже було сказано, файли даних (mdf і ndf) можуть об'єднуватися у так звані групи файлів. Таке об'єднання виконується з метою спрощення управління файлами. Наприклад, при створенні резервних копій можна виконувати архівування не всієї бази дан-• них цілком, а лише певної групи файлів. Основним же призначенням груп файлів є розміщення в них даних певних таблиць або їх окремих стовпців, а також зберігання індексів. При створенні таблиці ви можете явно зазначити, в якій групі файлів повинні зберігатися дані того чи іншого стовпця. Як наслідок, подібним чином можна наказати зберігати дані стовпців на різних логічних або фізичних дисках. Файли, не включені явно ні до якої групи, будуть включені в групу файлів за замовчуванням, якою поступка є первинна група файлів. Проте якщо є необхідність у додаткових групах файлів з тими чи іншими файлами, необхідно скористатися конструкцією , Що має наступний синтаксис: :: = FILEGROUP filegroupjiame [,..'. N] Аргумент fi1egroup_name визначає ім'я групи файлів, під яким вона буде розпізнаватися при виконанні команд Transact-SQL. Після імені групи файлів йде визначення включаються в неї файлів. Як видно з синтаксису, в одну групу файлів може бути включено безліч файлів. Ми розглянули створення звичайної бази даних, робота з якою проводиться на локальному сервері. Іноді буває необхідно перенести базу даних на новий сервер або розіслати копії бази даних (наприклад, каталог або річний звіт компанії). SQL Server 2000 має інструменти для виконання таких завдань. Перенесення виконується шляхом від'єднання і подальшого приєднання бази даних. Далі в цій главі буде докладно описаний механізм цих операцій, а також будуть розглянуті збережені процедури для виконання від'єднання та приєднання бази даних. Якщо база даних записується на компакт-диск і цей компакт-диск розсилається користувачам, то якщо виконати звичайне приєднання, файли бази даних не можна буде змінювати. Отже, не можна буде змінити параметри системи безпеки, щоб дозволити користувачам доступ до бази даних. Крім того, журнал транзакцій також буде недоступний для запису. Спеціально для вирішення подібних проблем SQL Server 2000 дозволяє створювати стерпні бази даних. При приєднання такої бази даних сервер створює на жорсткому диску файл, що містить системні таблиці та журнал транзакцій. Користувальницькі ж дані використовуються безпосередньо с. Носія і не можуть бути змінені. Для створення стерпної бази даних використовується збережена процедура sp_create_removable. Щоб після створення бази даних перевірити, чи відповідає вона вимогам стерпної бази даних, можна використовувати збережену процедуру sp_certify_removable. Управління базами даних До управління базою даних на фізичному рівні відноситься вся робота зі зміни імен, розміру, кількості, положення файлів бази даних, усікання бази даних і журналу транзакцій, створення груп файлів, зміна групи файлів за замовчуванням, зміна імені і власника бази даних, приєднання і від'єднання баз даних, зміна параметрів бази даних за допомогою збережених процедур, а також виконання інших дій. Більшість дій щодо зміни конфігурації бази даних виконується за допомогою команди ALTER DATABASE: ALTER DATABASE database {ADD FILE <filespec> [, ... n] [TO FILEGROUP filegroupjiame] | ADD LOG FILE <filespec> [.... n] j REMOVE FILE logicaljfilejiame [WITH DELETE] | ADD FILEGROUP filegroupjiame j REMOVE FILEGROUP filegroupjiame j MODIFY FILE <filespec> j MODIFY NAME = new_dbname j MODIFY FILEGROUP filegroupjiame NAME = new_filegroup_name | MODIFY FILEGROUP filegroupjiame filegroupjproperty} j SET <optionspec> [.. . '. N] [WITH <termination>] j COLLATE <collationjiame> } Як видно з синтаксису, за один виклик команди може бути змінено не більше одного параметра конфігурації бази даних. Якщо необхідно виконати декілька змін, доведеться розбити процес на кілька окремих кроків. Розглянемо більш детально призначення кожного з аргументів. Про database. Ім'я бази даних, яку необхідно модифікувати. Природно, зазначена база даних повинна існувати на сервері. Щоб мати можливість змінити базу даних, необхідно, щоб з нею не працював ні один користувач. Якщо ж у базі даних є хоч одна активна транзакція, то спроба виконання команди ALTER DATABASE завершиться помилкою. У цьому випадку потрібно дочекатися, поки будуть завершені всі транзакції, або скористатися аргументом WITH TERMINATION, який буде розглянуто далі. Про ADD FILE [,. . . N]. Цей аргумент використовується, коли до бази даних необхідно додати нові файли даних. Як видно з синтаксису, одночасно можна додати безліч файлів. Як і при роботі з командою CREATE DATABASE, файли описуються за допомогою конструкції , Синтаксис і використання якої були розглянуті в попередньому розділі при розгляді створення бази даних. • ТО FILEGROUP f 11 egroup_name. Використовується в поєднанні з попереднім аргументом для додавання файлів у певну групу файлів. Якщо аргумент ТО FILEGROUP не вказується, то файли будуть додані до групи файлів за замовчуванням. Про ADD LOG FILE [,. . . N]. Якщо за допомогою двох попередніх аргументів можна додавати в базу даних файли даних, то аргумент ADD LOG FILE використовується для додавання в базу даних одного або більше файлів журналу транзакцій. Про REMOVE FILE 1 ogica1_fi 1 e_name. На противагу попереднім, з допомогою розглянутого аргументу здійснюється видалення з бази даних одного з файлів. Відзначимо, що за одну команду ALTER DATABASE можна видалити лише один файл. Аргумент REMOVE FILE використовується як для видалення файлів даних, так і для видалення файлів журналу транзакцій. Однак перш ніж стане можливим видалення файлу, він повинен бути звільнений від даних. В іншому випадку сервер не дозволить його видалення. Звільнити файл від даних можна за допомогою команди DBCC SHRINKFILE (file_name, EMPTYFILE). Аргумент EMPTYFILE наказує розподілити всі дані з файлу між іншими файлами групи. Додавання нових даних у файл не дозволяється. Про ADD FILEGROUP f i legroup_name. Використовується для створення в базі даних групи файлів з вказаним ім'ям. Як видно з синтаксису, при створенні групи не вказується, які файли повинні в неї увійти. Перенесення існуючих файлів в нову групу виконується окремо. У базі даних може бути створено до 256 груп файлів. Нагадаємо, що групи файлів створюються лише для файлів даних. Файли журналу транзакцій не можуть бути організовані в групи. Про REMOVE FILEGROUP filegroup_name. Використовується для видалення з бази даних зазначеної групи файлів. При цьому також будуть видалені всі файли, включені в цю групу. Однак перед виконанням цієї операції необхідно заздалегідь видалити з файлів всі дані. Про MODIFY FILE . Використовується для зміни параметрів файлу бази даних, таких як логічне ім'я (NAME), початковий розмір (SIZE), максимальний розмір (MAXSIZE) і крок збільшення (FILEGROWTH). За один виклик команди ALTER DATABASE може бути змінений тільки один параметр одного з файлів. Хоча для опису файлу і використовується конструкція , Її синтаксис дещо інший, ніж при створенні бази даних. Відмінною особливістю є наявність аргументу NEWNAME, за допомогою якого можна змінити логічної ім'я файлу. В іншому ж синтаксис і використання конструкції аналогічні розглянутим раніше. :: = (NAME = logical_file_narne [. NEWNAME = new_log1cal_name] [, FILENAME = "os_file_name"] [. SIZE = size] [. MAXSIZE = {max_s1ze | UNLIMITED}] [. FILEGROWTH = growthjncrement]) Про MODIFY NAME = new_dbname. Як неважко здогадатися, цей аргумент дозволяє змінювати ім'я бази даних. Для цього достатньо всього-навсього вказати нове ім'я за допомогою параметра new_dbname. Про MODIFY FILEGROUP fi1egroup_name NAME = new_fi1egroup_name. Крім зміни імені бази даних також можна перейменувати і окрему групу файлів. Це і робиться з допомогою розглянутого аргументу. Все, що потрібно для зміни імені групи, - вказати поточне ім'я за допомогою параметра fi I egroup_name і нове ім'я-за допомогою параметра new_fiIegroup_name. Про MODIFY FILEGROUP fi1egroup_name filegroup_property. Цей аргумент дозволяє управляти властивостями групи файлів. Ім'я групи файлів, свій-• ства якої передбачається змінити, задається параметром fi I egroup_name, тоді як параметр fi I egroup_property призначений для вказівки властивості, яке повинно бути призначене для групи файлів. Підтримуються такі значення f ilegroup_property. * READONLY. При вказівці цього значення група файлів переводиться в режим «тільки для читання». У цьому режимі забороняється виконання будь-яких модифікацій даних у файлах, що належать відповідній групі. Переключення групи файлів у режим «тільки для читання» можуть виконувати лише користувачі, які мають монопольний доступ до бази даних. Не можна встановлювати в режим «тільки для читання» первинну групу файлів, так як в цьому випадку системні таблиці будуть заблоковані і виконання будь-яких змін в базі даних (у тому числі і скасування для групи файлів режиму «тільки для читання») стане неможливим. * READWRITE. Дія цього значення назад попередньому. Використовується для вирішення змін до групи файлів, в режим «тільки для читання». Робота з цим значенням, як і з попереднім, дозволена лише користувачам, які мають монопольний доступ до бази даних. * DEFAULT. Використовується для маркування зазначеної групи файлів, як групи файлів за умовчанням (default filegroup). У цю групу файлів будуть включатися всі файли даних, які явно не включені ні в яку іншу групу файлів. Більш того, всі об'єкти (індекси, таблиці та їх стовпці), для яких явно не вказано, в якій групі файлів вони повинні розташовуватися, будуть розміщені в групі файлів за замовчуванням. Група файлів, яка до цього була групою файлів за замовчуванням, стає звичайною групою. Про WITH . Цілком можлива ситуація, коли спроба зміни бази даних відбувається при виконанні якої-небудь транзакції. Як вже говорилося, ці дві операції несумісні і одна з них повинна бути відкладена до закінчення іншої. Тобто адміністратор повинен або почекати завершення всіх активних транзакцій, або примусово перервати їх виконання. У першому випадку адміністратор може досить довго чекати завершення всіх транзакцій. Більше того, ніщо не перешкодить користувачам починати нові транзакції. У попередніх версіях, в тому числі і в SQL Server 7.0, це було єдиним рішенням. На щастя, в SQL Server 2000 з'явилася можливість примусового переривання всіх призначених для користувача транзакцій. Саме для цього і використовується аргумент WITH , Який визначає метод переривання транзакцій. Синтаксис конструкції наступний: <Termination>:: = ROLLBACK AFTER integer [SECONDS] | ROLLBACK IMMEDIATE | NO WAIT »ROLLBACK AFTER num_second [SECONDS] - в цьому випадку сервер буде очікувати вказану кількість секунд, перш ніж перерве всі активні та обслуговування баз даних транзакції. Попередньо можна відправити користувачам повідомлення по мережі, що через стільки-то секунд всі транзакції будуть примусово відкачали. За цей час користувачі повинні або зафіксувати, або відкотити свої транзакції. * ROLLBACK IMMEDIATE - у цьому випадку відкат користувальницьких транзакцій виконується негайно без будь-яких пауз. »NO WAIT-як і в попередньому випадку, відкат відбувається відразу ж. Про COLLATE <conation_name>. За допомогою цього аргументу вказується зіставлення за замовчуванням для всіх об'єктів, що створюються в базі даних. Зміна зіставлення за замовчуванням не впливає на зіставлення, використовуваними вже створеними об'єктами бази даних. Дозволяється зазначатися як зіставлення Windows, так і зіставлення SQL Server. Визначає зіставлення для бази даних. За замовчуванням задається зіставлення SQL Server. Про SET [,. . . n]. За допомогою аргументу SET користувач може управляти різними властивостями бази даних. Властивості вказуються за допомогою конструкції , Яка має досить об'ємну структуру. Більш докладно управління властивостями бази даних буде розглянуто далі в цій главі в розділі «Управління властивостями бази даних». У попередніх версіях SQL Server, включаючи і SQL Server 7.0, не підтримувалася можливість зміни властивостей бази даних за допомогою команди ALTER DATABASE. Зменшення розміру бази даних В одному з попередніх розділів цієї глави було розказано про можливості SQL Server 2000 автоматично збільшувати розмір баз даних. Однак нерідко потрібно виконати і зворотний процес - зменшення розміру бази даних. Дійсно, якщо з бази даних видаляється значна частина даних або після декількох днів напруженої роботи користувачі істотно знижують навантаження на сервер і в журналі транзакцій утворюється багато вільного простору, часто виникає необхідність повернути невикористовуване дисковий простір в операційну систему. Як і збільшення бази даних, процес зменшення розміру бази даних, званий також стисненням бази даних (shrinking database), являє собою зменшення розміру окремих файлів, з яких складається база даних. Операції стиснення бази даних по можливості повинні виконуватися в період найменшої активності користувачів, щоб доставляти їм якомога менше незручностей. Як і збільшення, стиснення бази даних може виконуватися автоматично. Однак при автоматичному стисненні немає можливості контролювати розмір, на який необхідно зменшити розмір файлів бази даних. Сервер намагається звільнити як можна більшу, але не всю вільну частину бази даних. Тобто в деяких випадках сервер може залишити у файлі зайве вільний простір, тоді як в інших звести його до мінімуму. Таке неконтрольоване зведення до мінімуму вільного простору дуже швидко приводить до необхідності нового збільшення розміру файлу. Звичайно, розумніше було б залишити у файлі якийсь відсоток вільного простору, але, на жаль, сервер цього не робить. Автоматичне зменшення розміру бази даних відбувається в тому випадку, коли сервер виявляє в базі даних занадто багато невикористаного простору. Незважаючи на деякі недоліки автоматичного зменшення розміру бази даних, не можна не відзначити і незаперечна перевага - адміністратор звільняється від необхідності стежити за розміром бази даних, а також за обсягом використовуваного і вільного простору, переклавши цей обов'язок на сервер. Для дозволу чи заборони автоматичного зменшення бази даних використовується збережена процедура sp_dboption: sp_dboption "database_name", "autoshrink". ("True" | "false") За допомогою першого аргументу вказується ім'я бази даних, властивості якої передбачається змінювати. Другий аргумент повинен залишатися таким, як він наведений вище. Вказуючи значення "true" або "f al se", можна відповідно дозволяти і забороняти автоматичне зменшення файлів бази даних. Автоматичне зменшення розміру бази даних можна вирішити і за допомогою команди ALTER DATABASE, скориставшись аргументом SET. Більш докладно управління властивостями бази даних буде розглянуто в наступному розділі. Крім автоматичного можна також виконувати ручне зменшення розміру бази даних. Це робиться за допомогою команди контролю узгодженості (або цілісності) бази даних (database consistency check, DBCC): DBCC SHRINKDATABASE (Databasejname [, target_percent] [, {NOTRUNCATE | TRUNCATEONLY}] ) Розглянемо призначення аргументів. Про database_name. Ім'я бази даних, яку необхідно стиснути. Про target_percent. Кількість відсотків вільного простору, яке бажано залишити в базі даних після виконання її стиснення. Кажучи точніше, з допомогою розглянутого аргументу вказується відсоток від загального об'єму файлів бази даних, який повинен бути порожнім. Наприклад, якщо у файлі розміром 10 Мбайт є 4 Мбайта вільного простору, то для зменшення кількості незайнятого простору до 2 Мбайт необхідно вказати значення аргументу target_percent рівним 25. Спочатку сервер обчислює об'єм вільного і зайнятого простору (відповідно 4 і 6 Мбайт). Щоб отримати шукані 25 відсотків, співвідношення вільного і зайнятого простору має бути 3 до 1. Шляхом нехитрих обчислень сервер приходить до висновку, що потрібний результат буде отримано при розмірі файлу, що дорівнює 8 Мбайт. Після цього сервер переносить всі дані з останніх 2 Мбайт файлу в перші 8 Мбайт, поміщаючи їх у будь-незайняте місце на сторінці. Після того як всі дані будуть перенесені, виконується зменшення розміру файлу. Зауважимо, що в аргументі target_percent не можна вказувати розмір, що перевищує поточний відсоток вільного простору. В іншому випадку зменшення розміру файлу виконано не буде. Таким чином, виконуючи команду DBCC SHRINKDATABASE г з дуже великим значенням аргументу target_percent, можна отримати ситуацію, коли зменшення розміру бази даних взагалі не відбувається. Про NOTRUNCATE. При завданні цього аргументу вільний простір не повертається операційній системі, а резервується в файлах для майбутнього використання, тобто фізично зменшення розміру бази даних не відбувається. Тим не менш, сервер все ж виконує перенесення даних в початок файлу, як це було описано для попереднього аргументу. Про TRUNCATEONLY. При завданні цього аргументу сервер видаляє весь вільний простір у файлі за останнім використовуваним екстент. Значення аргументу target_percent при цьому ігнорується. Не робиться жодної спроби переміщення даних для більш ефективного їх розподілу у файлі. Якщо у файлі розміром 2 Мбайт виділено всього два екстент на початку і в середині файлу, то при використанні команди DBCC SHRINKDATABASE буде звільнена тільки половина файлу, починаючи від другого екстент і до кінця файлу. Розмір файлу буде становити близько 1 Мбайт, хоча в принципі він міг бути зменшений до 128 Кбайт. Права на стиск бази даних за допомогою команди DBCC SHRINKDATABASE видані тільки членам фіксованого ролі сервера sysadmin та фіксованого ролі бази даних dbowner. Ці права не можуть бути передані користувачеві ніяким іншим способом, окрім як включенням його в одну з цих ролей. Щоб зменшити кількість вільного простору в базі даних pubs до 15% з резервуванням звільненого простору для подальшого використання, необхідно виконати наступну команду: DBCC SHRINKDATABASE (pubs. 15. NOTRUNCATE) He має значення, в контексті якоїсь бази даних виконується команда DBCC SHRINKDATABASE, так як при її виклику явно вказується ім'я потрібної бази даних. Після виконання команди сервер видасть приблизно таке повідомлення: Dbld Fileld CurrentSize MinSize UsedPages EstimatedPages 5 2 96 63 96 56 (1 row (s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. Розглянемо призначення стовпців в отриманому результаті. Про Dbld - ідентифікаційний номер бази даних. Цей номер-буде однаковий для всіх відображуваних рядків. Про Fileld-ідентифікаційний номер файлу бази даних, розмір якого був зменшений в процесі стиснення бази даних. Якщо деякі файли не були стиснуті, то інформація про них не виводиться. Про CurrentSize-кількість сторінок, що є у файлі, причому враховуються як заповнені, так і вільні сторінки. Про MinimumSize-мінімальна кількість сторінок, до якого може бути зменшений файл. Це значення може обмежуватися початковим розміром файлу, встановленим при його створенні. В іншому випадку воно дорівнює значенню у стовпці EstimatedPages. Про UsedPages-кількість сторінок, що містять дані. Про EstimatedPages-кількість сторінок, до якого може бути стиснутий файл. Однак не завжди файл може бути стиснутий до зазначеного розміру, так як не можна встановити розмір файлу менше початкового. Список баз даних і відповідних ідентифікаційних номерів зберігається в таблиці sysdatabases системної бази даних master. Для отримання ідентифікаційного номера бази даних можна використовувати команду DB_ID ("databasename"). Якщо ж необхідно визначити ім'я бази даних за ідентифікаційним номером, то можна скористатися командою DB_NAME (database_id). Команда DBCC SHRINKDATABASE працює з цілою базою даних. Якщо ж необхідно зменшити розмір конкретного файлу бази даних, то для цього слід використовувати команду DBCC SHRINKFILE, що має наступний синтаксис: DBCC SHRINKFILE ({Filejname | fllejd} {[. target_size] j [. {EMPTYFILE | NOTRUNCATE | TRUNCATEONLY}] Виконання цієї команди, на відміну від команди DBCC SHRINKDATABASE, повинно здійснюватися в контексті тієї бази даних, файл якої передбачається зменшити. Нагадаємо, що для перемикання баз даних використовується команда USE. Розглянемо призначення аргументів команди DBCC SHRINKFILE. Про f i 1 e_name | fi 1 e_i d. Ім'я файлу, який необхідно стиснути, або його іден- тіфікаціонний номер. Для отримання ідентифікаційного номера файлу бази даних можна використовувати команду FILE_ID: FILE ID ("filename") ПРИМІТКА Список файлів бази даних, їх ідентифікаційних номерів, логічних і фізичних імен зберігається в таблиці sysfiles кожної бази даних. Про target_size. Бажаний розмір (ціле число в мегабайтах), який повинен мати файл після виконання стиснення. Якщо розмір не вказується, то файл стискається до мінімально можливого розміру. При виконанні команди DBCC SHRINKFILE сервер при необхідності виконує переміщення даних з частини файлу, що має бути вилучена, в ту частину, яка буде залишена. Якщо розмір target_size менше, ніж мінімально можливий розмір файлу, то стиснення файлу буде виконуватися тільки до мінімально можливого розміру. Наприклад, якщо файл розміром 20 Мбайт містить 14 Мбайт даних, а користувач намагається стиснути його до 10 Мбайт, то файл буде стиснутий тільки до 14 Мбайт. Якщо розмір файлу після стиснення стає менше початкового розміру, то новий розмір стає мінімальним розміром файлу. Про EMPTYFILE. При використанні цього аргументу сервер виконує перенесення даних з файлу в інші файли, включені в ту ж групу, що і стискається файл. Сервер не буде додавати нові дані в файл, стиснутий з аргументом EMPTYFILE. Такий файл може бути знищений за допомогою команди ALTER DATABASE REMOVE FILE. Про NOTRUNCATE. Використання цього аргументу наказує сервера не повертати місце, що звільнилося операційній системі. Таким чином, розмір файлу насправді не зменшується. Дані у файлі розташовуються більш компактно і зміщуються до початку файлу. Якщо аргумент NOTRUNCATE не вказаний, то простір, що звільнився повертається операційній системі, тобто розмір файлу зменшується. Про TRUNCATEONLY. При вказівці цього аргументу сервер виконує урізання частини файлу, починаючи від останньої використовуваної сторінки до кінця файлу. Значення аргументу target_size в цьому випадку ігнорується. Ніякого переміщення даних для більш компактного їх розташування не робиться. Для стиснення файлу даних бази даних pubs до 1 Мбайт введіть наступну команду: USE Pubs DBCC SHRINKFILE (pubs, 1) У результаті сервер видасть таблицю, подібну до тієї, яка видається за виконанні команди DBCC SHRINKDATABASE. Склад і призначення стовпців у обох випадках аналогічні: Dbld Fileld CurrentSize MinimumSize UsedPages EstimatedPages 5 1 296 80 288 288 (1 row (s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. Переконався, що файлом з ідентифікаційним номером 1 є файл pubs: SELECT FILE_ID ("pubs") SELECT FILE_NAME (1) У результаті буде отримано наступний результат: 1 (1 row (s) affected) pubs (1 row (s) affected) Права на виконання команди DBCC SHRINKFILE видаються таким же чином, як і для команди DBCC SHRINKDATABASE. Для журналу транзакцій або його файлів стиск відбувається не відразу, а при подальшому виконанні операції усічення (truncate) або резервного копіювання. Управління властивостями бази даних Крім перерахованих вище фізичних параметрів (описують в основному імена, розміри, стан та інші характеристики файлів) база даних має ще й логічні параметри. До цих параметрів відносяться виконання автоматичного усікання журналу транзакцій, автоматичне створення та оновлення статистики, можливість виконання вкладених тригерів та інші. Управління цими параметрами конфігурації бази даних зводиться до їх розв'язання або заборони і здійснюється за допомогою системної збереженої процедури sp_dboption. Призначення основної частини параметрів було розглянуте в главі 11. Синтаксис процедури, що зберігається sp_dboption наступний: sp_dboption [[@ dbname =] "database"] [. [@ Optname =] "optionjiame"] [. [@ Optva "lue =]" value "] Аргумент "database" містить ім'я бази даних, в якій необхідно виконати зміну конфігурації. Аргумент "value" визначає значення параметра. Можливі два варіанти: значення ON або TRUE (параметра заданий) і значення OFF або FALSE (параметра не заданий). Аргумент "option_name" визначає ім'я параметра, який необхідно змінити. Можливі значення цього аргументу наведено в табл. короткий опис призначення кожного параметра. Таблиця. Параметри конфігурації бази даних Параметр Призначення ' a uto create statistics auto update statistics autoclose autoshrink ANSI null default ANSI nulls ANSI warning concat null yields null cursor close on commit dbo use only default to local cursor merge publish offline published quoted identifier read only recursive triggers select into / bulk copy Автоматичне створення статистики Автоматичне оновлення статистики Автоматичне закриття бази даних Автоматичний стиск бази даних Дозвіл значення NULL за замовчуванням для стовпця Управління порівнянням величин NULL Поява повідомлень про помилку Значення ON означає, що результатом об'єднання величин NULL буде значення NULL Закриття курсору при завершенні транзакції Використання бази даних лише власником Створення за замовчуванням локального курсору База даних може публікуватися для реплікації зведенням Відключення бази даних Дозвіл публікації бази даних Дозвіл використання подвійних кавучек для вказівки ідентифікаторів Використання бази даних лише для читання Дозвіл виконання вкладених тригерів Дозвіл виконання команд копіювання, не реєструються в журналі транзакцій ___________________________ продовження А даних Таблиця (продовження) Параметр Призначення subscribed Дозвіл підписки на публікацію single user Використання бази даних в режимі підтримки одного користувача torn page detection Виявлення пошкоджених сторінок trunc. log on chkpt ____ Усічення журналу транзакцій при виконанні контрольної точки Наприклад, для перемикання бази даних pubs у однокористувацький режим потрібно виконати наступну команду: ЕХЕС sp_dboption "pubs", "single user", "true" Частина встановлених адміністратором параметрів конфігурації бази даних може бути змінена користувачем за допомогою команди SET на рівні з'єднання, транзакції, збереженої процедури, пакета команд і т. д. Ці зміни діють лише в межах з'єднання (транзакції, збереженої процедури і т. д.) і будуть втрачені відразу ж після від'єднання користувача. При подальшому з'єднанні знову будуть використовуватися параметри, встановлені адміністратором. Використання системної збереженої процедури sp_dboption для керування властивостями бази даних було єдиним варіантом у попередніх версіях. Навіть при роботі з SQL Server 7.0 адміністратор мав у своєму розпорядженні тільки цю процедуру. У SQL Server 2000 зміна параметрів бази даних також може виконуватися за допомогою команди ALTER DATABASE з аргументом SET . Як неважко здогадатися, властивості бази даних, які передбачається змінити, вказуються за допомогою конструкції , Що має наступний синтаксис: :: = <State_option> [<Cursor_option> | <Auto_option> | <Sql_option> | <Recovery_option> <State_option> .- .- = {SINGLEJJSER | RESTRICTED_USER | MULTIUSER} | {OFFLINE | ONLINE} | {READJ3NLY | READ_WRITE} <Termination> ROLLBACK AFTER integer [SECONDS] | ROLLBACK IMMEDIATE | NO WAIT <Cursor_option>:: = CURSOR_CLOSE_ON_COMMIT {ON | OFF} | (CURSOR_DEFAULT {LOCAL | GLOBAL} <Auto_option> {AUTO_CLOSE ON | OFF} | {AUTO_CREATE_STATISTICS ON | OFF} | {AUTO_SHRINK ON | OFF} | {AUTO_UPDATE_STATISTICS ON | OFF} <Sql_option>:: = ANSI_NULL_DEFAULT {ON | OFF} | ANSI_NULLS {ON | OFF} j ANSI_PADDING {ON | OFF} j ANSIJIARNINGS {ON | OFF} | ARITHABORT {ON | OFF} | CONCAT_NULL_YIELDS_NULL {ON | OFF} | NUMERIC_ROUNDABORT {ON | OFF} | QUOTEDJDENTIFIER {ON J OFF} | RECURSIVEJRIGGERS {ON | OFF} <Recovery_option>:: = RECOVERY {FULL | BULK_LOGGED | SIMPLE} | TORN_PAGE_DETECTION {ON | OFF} Практично всі перераховані аргументи були розглянуті небудь в цій главі, або в розділі 11. Тому ми не буде зайвий раз на них зупинятися. Приєднання і від'єднання бази даних SQL Server 2000 дозволяє від'єднувати (detach) бази даних від сервера. Користувачі не можуть звертатися до вщ'еднаним баз даних. Опис отсоединенной бази даних, включаючи опис файлів журналу транзакцій і самої бази даних, видаляється з системних таблиць SQL Server і, таким чином, сервер перестає її сприймати. Пізніше цю базу даних можна приєднати (attach) на цьому ж або іншому сервері. Від'єднання і приєднання в основному використовуються для перенесення баз даних з одного диска або сервера на інший. Якщо потрібно скопіювати базу даних на один або декілька віддалених серверів, можна виконати резервне копіювання бази даних і розіслати копії. Інший спосіб - виконати від'єднання бази даних і розіслати користувачам всі її файли. У себе на сервері користувачі зможуть виконати приєднання бази даних і відразу ж почати працювати з нею. Процедура від'єднання та приєднання займає набагато менше часу, ніж створення і відновлення резервної копії. Крім того, від'єднаних базу даних можна записати на компакт-диски та розіслати користувачам. Користувачі зможуть працювати з базою даних безпосередньо з компакт-диска в режимі «тільки для читання». Такий підхід особливо ефективний при розсилці каталогів, які не повинні змінюватися. Якщо планується скопіювати базу даних на компакт-диск, попередньо необхідно встановити всі її групи файлів у режим «тільки для читання». Для цього використовується команда ALTER DATABASE MODIFY FILEGROUP filegroup_name READONLY. Виконувати операції приєднання і від'єднання бази даних можуть тільки члени фіксованого ролі сервера sysadmin. Ці права не можуть бути передані ніяким іншим способом, окрім як включенням користувачів у цю фіксовану роль сервера. Для від'єднання бази даних використовується наступна збережена процедура: sp_detach_db [@ dbname =] "dbname" [, [@ skipchecks =] "skipchecks"] Аргумент "dbname" вказує назву бази даних, яку необхідно від'єднати. Аргумент "skipchecks" управляє оновленням статистики при від'єднаний- нії. Якщо значення цього аргументу одно TRUE, то оновлення статистики пропускається, якщо ж вказується FALSE, то оновлення статистики буде виконано. Для від'єднання бази даних pubs потрібно використовувати наступну команду: ЕХЕС sp_detach_db "pubs" Після від'єднання бази даних ви отримуєте в своє розпорядження набір звичайних файлів, з якими можна виконувати звичайні операції, в тому числі і архівування з використанням утиліти NT Backup. Для приєднання отсоединенной бази даних використовується системна збережена процедура sp_attach_db: sp_attach_db [@ dbname =] "dbname", [(Pfilenamel =] "filenameji" [,... 16] Аргумент "filename_n" повинен містити повний шлях до первинного файлу приєднуваної бази даних. Опис інших файлів бази даних зберігається у первинному файлі. Якщо положення цих файлів було змінено, то необхідно явно вказати їх положення при виклику процедури, що зберігається - через кому в аргументі "fi ​​lename_n". Кількість файлів, яке можна приєднати за допомогою збереженої процедури sp_attach_db, обмежується 16. Якщо необхідно виконати підключення бази даних з великою кількістю файлів, використовується команда CREATE DATABASE FOR ATTACH. Для приєднання бази даних pubs потрібно виконати наступну команду: sp_detach_db "pubs". "D: \ mssql \ data \ pubs.mdf". "D: \ mssql \ data \ pubs_log.Idf" Якщо база даних складається з одного файлу даних і одного файлу журналу транзакцій, то її можна приєднати, вказавши тільки первинний файл. База даних повинна бути від'єднано від сервера з допомогою збереженої процедури sp_detach_db. Для приєднання такої бази даних використовується наступна збережена процедура: sp_attach_sing1e_file_db [@ dbname =] "dbname". [@ Physname =] "physicaljiame" Сервер автоматично створить для бази даних файл журналу транзакцій і виконає видалення з бази даних підтримку реплікації, якщо вона була встановлена. Для приєднання бази даних pubs з використанням тільки первинного файлу необхідна наступна команда: sp_attach_single_file_db "pubs", "d: \ mssql \ data \ pubs.mdf" Передача прав володіння Якщо адміністратор баз даних вашої компанії звільняється і йому на зміну приходить інша людина, необхідно передати права володіння всіма об'єктами, включаючи бази даних, новому адміністратору. Для передачі прав володіння базою даних від одного користувача іншому використовується наступна збережена процедура: sp_changedbowner [(Ploginame =] "login" [, [@ Map =] remap_al1as_f1ag] Розглянемо призначення кожного з аргументів збереженої процедури. О [Ologiname =] "login". Ім'я облікового запису користувача, якого потрібно зробити власником бази даних. Цей обліковий запис не повинна мати доступу до бази даних ні через псевдонім, ні через відображення у користувача бази даних. В іншому випадку перед виконанням процедури, що зберігається необхідно видалити всі відображення облікового запису в користувача бази даних. О [map =] remap_al i as_fl ag. Цей аргумент може приймати значення TRUE або FALSE. Значення TRUE означає, що обліковий запис старого власника бази даних буде відображатися в обліковий запис нового власника. Якщо задано FALSE, обліковий запис старого власника знищується. Якщо цей аргумент опускається, тобто приймає значення NULL, то всі існуючі dbo будуть відображені в обліковий запис нового власника бази даних. Процедура, що зберігається sp_changedbowner повинна виконуватися в контексті бази даних, власника якої потрібно змінити. Наприклад, для зміни власника бази даних KHSU необхідно виконати наступну команду: USE khsu EXEC sp_changedbowner "MATRIXXAdmlnistrator" Зміна імені бази даних При розгляді команди ALTER DATABASE ми вже говорили, що вона дозволяє змінити ім'я бази даних. Однак для зміни імені бази даних також можна використовувати наступну збережену процедуру: sp_renamedb [@ old_name =] "old_name". [@ New_name =] "new_name" Аргумент "old_name" повинен містити старе ім'я бази даних. Нове ж ім'я вказується за допомогою аргументу "new_name". Права на виконання цієї процедури, що зберігається мають тільки члени фіксованого ролі сервера sysadmin. Перегляд властивостей бази даних Часто буває необхідно отримати вичерпну інформацію про структуру і параметри бази даних. У цьому розділі будуть розглянуті засоби Transact-SQL, за допомогою яких можна отримати різну інформацію про базу даних. Для перегляду значення параметрів конфігурації бази даних, встановлених за допомогою збереженої процедури sp_dboption або засобами Enterprise Manager, можна використовувати системну збережену процедуру sp_dboption із зазначенням тільки імені бази даних. Наприклад, для отримання інформації про параметри бази даних pubs можна виконати наступну команду: EXEC sp_dbopt1on "pubs" Буде повернуто приблизно наступний результат: The following options are set: published trunc. log on chkpt. torn page detection auto create statistics auto update statistics Як видно, повертається список тільки тих параметрів, які були встановлені. Для отримання значення конкретного параметра необхідно вказати не тільки ім'я бази даних, а й ім'я цікавить параметра конфігурації: ЕХЕС spjboption "pubs", "ANSI null default" В результаті виконання цієї команди буде отриманий приблизно наступний результат: OptionName CurrentSetting ANSI null default off Якщо виконати збережену процедуру sp_dboption взагалі без аргументів, то вона видасть список всіх доступних параметрів конфігурації: Settable database options: ANSI null default ANSI nulls ANSI padding ANSI warnings arithabort auto create statistics auto update statistics autoclose autoshrink concat null yields null cursor close on commit dbo use only default to local cursor merge publish numeric roundabort offline published quoted identifier read only recursive triggers select into / bulkcopy single user subscribed torn page detection trunc. log on chkpt. Крім збереженої процедури sp_dboption для отримання значення тих же і деяких додаткових параметрів конфігурації можна використовувати наступну команду: DATABASEPROPERTY ("database_name". "Property") Аргумент database_name повинен містити ім'я бази даних, властивості якої потрібно переглянути. Можливі значення аргументу property і їх призначення перераховані в табл. 14.2. Таблиця Аргументи команди DATABASEPROPERTY Аргумент IsAnsiNullDefault IsAnsiNullEnabled IsAnsiWarningEnabled IsAutoClose IsAutoShrink IsAutoUpdateStatistics IsBulkCopy IsCloseCursorOnCommit-Enabled IsDboOnly IsDetached IsEnergencyMode IsFulltextEnabled IsInLoad IsInRecovery IsInStandby IsLocalCursorsDefault IsNotRecovered IsNullConcat IsOffline IsQuotedldentifiersEnabled leReadOnly IsRecursiveTriggersEnabled IsShutDown Призначення Аналог аргументу "ANSI null default" процедури sp_dboption Аналог аргументу "ANSI nulls" процедури sp_dboption Аналог аргументу "ANSI warning" процедури sp_dboption Аналог аргументу "autoclose" процедури sp_dboption Аналог аргументу "autoshrink" процедури sp_dboption Аналог аргументу "auto update statistic" процедури sp_dboption Аналог аргументу "select into / bulk copy" процедури sp_dboption Аналог аргументу "cursor close on commit" процедури spjdboption Аналог аргументу "dbo use only" процедури sp_dboption База даних відокремлювалася командою sp_detach Дозвіл роботи з «підозрілою» базою Підтримка повнотекстового пошуку База даних була завантажена з резервної копії Виконується відновлення бази даних База даних працює в режимі «тільки для читання» Аналог аргументу "default to local cursor" процедури sp_dboption Відновлення бази даних завершилося з помилкою Аналог аргументу "concat null yields null" процедури sp_dboption Аналог аргументу "offline" процедури sp_dboption Аналог аргументу "quoted identifier" процедури sp_dboption Аналог аргументу "read only" процедури sp_dboption Аналог аргументу "recursive triggers" процедури sp_dboption У базі при запуску сервера виникають ошібкі__ продовження & Таблиця (продовження) Аргумент Призначення IsSingleUser Аналог аргументу "single user" процедури sp_dboption IsSuspect Є сумніви в цілісності бази даних IsTruncLog Аналог аргументу "trunc. Log on chkpt." процедури sp_dboption Version Внутрішній номер версії сервера SQL Server, ________________________ На якому була створена база даних _________ Результатом виконання команди DATABASEPROPERTY буде або значення О, яке відповідає значенню FALSE або OFF збереженої процедури sp_dbopt1 on, або значення 1, яке відповідає значенню TRUE або ON. Винятком з правила є значення, що повертає для параметра Version. Для цього параметра повертається значення типу int, що може приймати будь-яке позитивне значення. Якщо значення параметра не визначено, то команда поверне значення NULL. Наведемо приклад використання команди DATABASEPROPERTY для отримання інформації про режим злиття двох значень NULL, встановленому для бази даних pubs: SELECT DATABASEPROPERTY ("pubs", "IsNullConcat") Сервер поверне приблизно наступний результат: Про (1 row (s) affected) Для отримання деякої загальної інформації про базу даних можна використовувати наступну збережену процедуру: spjielpdb [[@ dbname =] "name"] Ця збережена процедура видає інформацію про поточний розмірі бази даних з точністю до десятків кілобайт, ім'я облікового запису, що є власником бази даних, ідентифікаційний номер бази даних, дату створення бази даних та її поточний статус. Крім того, ця збережена процедура видає інформацію про файли бази даних: логічне та фізичне ім'я файлу бази даних, його ідентифікаційний номер у базі даних, поточний і максимальний розмір, крок збільшення, а також належність до тієї чи іншої групи файлів. Для отримання інформації про файли бази даних з збереженої процедури spjielpdb відбувається виклик збереженої процедури sp_helpfile, яка і видає інформацію про параметри файлу. Тому формат результату виконання цих процедур, що зберігаються однаковий. Більш докладно формат даних буде розглянуто нижче. Для отримання інформації про базу даних pubs можна використовувати наступну команду: ЕХЕС spjielpdb "pubs" Обсяг інформації, що повертається цією командою, досить великий, тому можливості привести цю інформацію в книзі немає. Однак ви можете виконати вказану команду в Query Analyzer і подивитися, що ж буде видано у відповідь. Для отримання інформації про конкретний файлі бази даних можна використовувати наступну збережену процедуру: sp_helpfile [[^ filename =] "name"] Ця процедура видає інформацію про фото в наступних стовпцях: Про Name - логічне ім'я файлу в базі даних; Про Filename-фізична ім'я файлу в операційній системі, що включає повний шлях до файлу; Про Filegroup-ім'я групи файлів, до якої належить файл; Про Si ze - поточний розмір файлу; Про Maxsize-максимальний розмір файлу, встановлений при його створенні; Про Growth - крок приросту розміру файлу; Про Usage-тип використання файлу; можливе одне з двох значень: data only (файл використовується для зберігання даних) або log on! У (файл використовується для зберігання журналу транзакцій). Для отримання інформації про групу файлів можна використовувати наступну збережену процедуру: sp_helpfilegroup [[Ofilegroupname =] "name"] Ця збережена процедура виконується в контексті бази даних, інформацію про яку необхідно отримати. В результаті виконання процедури буде видана інформація про ідентифікаційний номер групи, кількість включених до неї файлів, а також інформація про самих файлах. Для отримання інформації про групу файлів PRIMARY бази даних pubs можна використовувати наступну команду: ЕХЕС sp_helpf11egroup "primary" Буде отримано приблизно наступний результат: groupname groupid fllecount PRIMARY 1 січня f11e_in_group fileid filename size maxsize growth pubs 1 pubs.mdf 2688 KB Unlimited Ш У стовпці Filename буде зазначено повний шлях до файлу. Для перегляду інформації про використання простору всередині бази даних можна застосувати таку, системну збережену процедуру: sp_spaceused [[@ objname =] "objname"] [, [@ updateusage =] "updateusage"] Аргумент "objname" містить ім'я таблиці бази даних, про яку необхідно отримати інформацію. Аргумент "updateusage" управляє виконанням команди DBCC UPDATEUSAGE і може приймати значення TRUE або FALSE. Якщо процедура sp_spaceused запускається без аргументів, то буде виведена інформація про використання простору в поточній базі даних. В результаті виконання sp_spaceused в контексті бази даних pubs буде отриманий приблизно наступний результат: database_name pubs reserved data database_s1ze 3.63 MB Index size unallocated space 1.10 MB unused 2584 KB 1120 KB 1288 KB 176 KB Як видно, результат складається з двох наборів. У стовпці database_name вказано ім'я бази даних, про яку виводиться інформація, у стовпці database_s1 ze - початковий розмір бази даних, а в стовпці unal I ocated space-простір, яке було звільнено при стисканні. У стовпці reserved відображається сума зарезервованого для бази даних простору (database_size - "unallocated space" = data + index_size + unused). У стовпці data зазначений обсяг пам'яті, займаний даними, а в стовпці index_size-обсяг пам'яті, займаний індексами. Розмір вільного простору в базі даних виводиться в стовпчику unused. Щоб отримати інформацію про використання простору в таблиці titleauthor, можна використовувати наступну команду: ЕХЕС sp_spaceused "titleauthor" У результаті процедура видасть приблизно наступне: name rows reserved data index_size unused titleauthor 25 48 KB 8 KB 40 KB 0 KB У стовпці name вказано ім'я таблиці, про яку виводиться інформація, а в стовпці rows - число рядків даних, яке введено в таблиці. Об'єм пам'яті, виділений в базі даних для таблиці, вказується в стовпці reserved (data + index_s1ze + unused). У стовпці data зазначений обсяг пам'яті, займаної даними, що зберігаються в таблиці, а в стовпці i ndex_si ze - обсяг пам'яті, відведений для індексу. Обсяг вільного простору вказується в стовпці unused Для отримання інформації про журнал транзакцій Transact-SQL пропонує команду DBCC SQLPERF, видає інформацію про використання журналів транзакцій в кожній з баз даних, створених на сервері. Для отримання інформації про використання журналів транзакцій потрібно виконати наступну команду: DBCC SQLPERF (LOGSPACE) У результаті буде видана наступна інформація: DatabaseName LogSize (MB) Log Space Used (%) Status Samp! e_3 1.9921875 33.039215 0 Sample_2 1.9921875 34.264706 0 Sample 1 1.9921875 33.553921 0 Distribution 0.9921875 56.98819 0 Abba 0.9921875 38.877953 0 Northwi nd 0.9921875 46.948818 0 Pubs 0.9921875 55.610237 0 Msdb 2.4921875 35.442791 0 Tempdb 0.4921875 85.079521 0 Model 0.7421875 45.328949 0 Master 1.2421875 34.709118 0 (12 row (s) affected) DBCC execution completed. If DBCC printed error messages, contact your system administrator. Вся інформація про файли і групах файлів бази даних зберігається в системних таблицях. Збережені процедури звертаються до цих таблиць і повертають користувачеві результат в зручному вигляді. Хоча в деяких випадках буває простіше безпосередньо вважати дані з системних таблиць, ніж виконувати збережені процедури, Microsoft настійно радить не вдаватися до прямого звернення до системних таблиць, так як їх структура може бути змінена в наступних версіях, і тому програми, які успішно працюють з однією з версій SQL Server, можуть працювати неправильно або взагалі не працювати з наступними версіями цієї СУБД. При використанні збережених процедур Microsoft гарантує, що сумісність буде збережена. Все-таки для повноти картини наведемо структуру системних таблиць, в яких зберігається опис фізичної структури бази даних. Список файлів бази даних зберігається в системній таблиці sysfiles. Кожний рядок цієї таблиці відповідає одному файлу бази даних. Таблиця sysfiles є віртуальною і не може бути змінена безпосередньо за допомогою команд DELETE, UPDATE або INSERT. Тим не менше, користувачі можуть зчитувати дані з цієї таблиці, використовуючи команду SELECT. Структура таблиці sysf i I es наведена в табл. 14.3. Таблиця. Структура системної таблиці sysfiles Ім'я стовпця Тип даних Призначення Field Smallint Ідентифікаційний номер (ID) файлу в базі даних GroupID Smallint ID групи файлів, до якої належить файл Size Int Поточна кількість сторінок у файлі Maxsize Int Максимальний розмір файлу. Значення -1 означає, що розмір файлу не обмежений Growth Int Крок збільшення Status Int Поточний статус файлу Perf Int Зарезервовано Name Nchar (128) Логічне ім'я файлу Filename Nchar (260) Фізичне ім'я файлу Таблиця sysf lies описує докладну структуру файлів. Більш компактне опис файлів зберігається в таблиці sysfilesl, яка містить стовпці status, field, name і filename, призначення яких аналогічно. Для перегляду інформації про файли бази даних за допомогою таблиці sysfilesl можна виконати наступну команду: SELECT * FROM sysfilesl У результаті буде повернений наступний результат: status fileid name filename 3 січня pubs ... \ data \ pubs.mdf 49218 лютого pubsjog ... \ data \ pubs_log.ldf (2 row (s) affected) Опис груп файлів, створених в базі даних, зберігається в системній таблиці sysfilegroups. Кожний рядок цієї таблиці відповідає одній групі. Структура цієї таблиці наведено в табл. Таблиця. Структура таблиці sysfilegroups Ім'я стовпця Тип даних Призначення GroupID Allocpolicy Status Groupname Smallint Smallint Ins Sysname Ідентифікаційний номер групи файлів Зарезервовано Поточний статус групи: 0x8-READONLY, 0x10 - Ім'я групи файлів DEFAULT Наприклад, для отримання інформації про групи файлів, визначених у базі даних pubs, можна використовувати наступний запит: SELECT * FROM sysfilegroups Буде повернуто приблизно наступний результат: groupld allocpolicy status groupname 1 0 16 PRIMARY (1 row (s) affected) Видалення бази даних Для видалення бази даних використовується наступна команда: DROP DATABASE databasejiame [,... n] Аргумент database_name вказує ім'я бази даних, яку необхідно видалити. Однією командою можна видалити кілька баз даних, перерахувавши їх імена через кому. Наприклад, для видалення баз даних Pubs і Northwind потрібно виконати наступну команду: DROP DATABASE Pubs. Northwind Управління користувацькими типами даних У розділі 5 у Типи даних »були розглянуті вбудовані в SQL Server 2000 типи даних. Ці типи даних завжди є в розпорядженні користувачів і можуть бути використані для стовпців таблиць, уявлень, змінних і т. д. Однак крім вбудованих типів даних користувачі можуть на їх основі створювати свої власні типи даних - так звані користувацькі типи даних. Користувальницькі типи даних (user-defined data type) - це типи даних, що створюються користувачами. Вони створюються на основі системних типів даних. Користувальницькі типи даних часто використовуються, коли в кількох таблицях необхідно зберігати однотипні значення, причому гарантувати, що стовпчики в таблиці будуть мати однаковий розмір, тип даних і чутливість до даних NULL. Наприклад, за допомогою користувальницького типу даних можна зберігати номери та серії паспорта. Щоб створити власний типу даних використовується системна збережена процедура sp_addtype: sp_addtype [@ typename =] type. [@ Phystype =] system_data_type [. [@ Nulltype =] "null_type"] [, [@ owner =] "owner name"] Якщо необхідно зробити для користувача тип даних доступним у всіх створюваних базах даних, додайте цей тип в базу даних model. Тут використовуються такі аргументи. Про type - ім'я створюваного типу даних. При виборі імені створюваного типу даних необхідно дотримуватися встановлених правил іменування об'єктів. Ім'я повинно бути унікальним в межах власника, тобто не збігатися з іменами інших об'єктів. Різні користувачі можуть вживати однакові імена для створюваних об'єктів. Про system_data_type - системний тип даних, на основі якого створюється користувача тип даних. Можна вибрати один з наступних типів даних: "Binary (n)" Image smalldatetime Bit Int smallint "Char (n)" "nchar (n)" 'text Datetime Ntext tinyint Decimal Numeric uniqueidentifier "Decimal [(p [, s])]" "numeric [(p [, s])]" "varbinary (n)" Float "nvarchar (n)" "varchar (n)" "Float (n)" Real Лапки необхідні, коли, крім самого типу даних потрібно вказівка ​​додаткових параметрів. Аргумент п ідентифікує довжину системного типу даних в призначеному для користувача типі даних, аргумент р - максимальну сумарну (до і після десяткової точки) кількість цифр для числових типів даних в призначеному для користувача типі даних, аргумент s - максимальна кількість десяткових цифр після коми в користувальницькому типі даних. Не можна створити користувальницький тип даних на основі системного типу timestamp. Про "null _type". Значення цього аргументу визначає, чи буде користувача тип даних зберігати значення NULL Аргумент null_type має тип varchar (S) і може приймати одне з трьох наступних значень: NULL (дозволяється зберігання NULL), NOT NULL (зберігання NULL забороняється) або NONULL (використовується значення за замовчуванням). Якщо аргумент null_type не вказується, то при створенні користувацького типу використовується значення за замовчуванням, установленим для бази даних за допомогою системної збереженої процедури sp_dboption. Поточне значення, встановлене в базі даних, можна отримати за допомогою функції GETANSINULL Значення аргументу null_type потрібно для користувальницького типу даних лише як значення за замовчуванням при створенні стовпця таблиці. Якщо при створенні стовпця явно визначено властивість NULL або NOT NULL, то значення аргументу null_type ігнорується. Про "owner_name". Визначає власника або творця нового типу даних. За замовчуванням власником нового типу даних вважається поточний користувач. Параметр owner_name має тип даних sysname. Наприклад, при створенні призначених для користувача типів даних для опису номерів факсу та телефону можна використовувати наступний код: ЕХЕС sp_addtype telephone, "varchar (24)", "NOT NULL" EXEC sp_addtype fax, "varchar (24)", "NULL" Процедура, що зберігається sp_addtype додає опис типу в системну таблицю systypes поточної бази даних. У принципі, якщо подивитися на цю таблицю, то можна помітити, що в ній також перераховані убудовані типи даних. Тобто і типи даних, що виглядають вбудованими, на рівні конкретної бази даних є одними, але мають ті ж властивості і імена, що і вбудовані. Наприклад, виберемо з таблиці systypes бази даних pubs список доступних типів даних: SELECT name FROM systypes Буде повернуто наступний результат: name image text uniqueidentifier tinyint smallint int smalldatetime real money datetime float sql_variant ntext bit decimal numeric small money bigint varbinary varchar binary char timestamp nvarchar nchar sysname id tid empid (29 row (s) affected) Як видно, в одній таблиці перераховані і вбудовані, і призначені для користувача типи даних (id, ti d і emi d). Керування правилами Правила (rules) є одним із засобів забезпечення цілісності даних, що зберігаються в базі. Правила залишені для забезпечення зворотної сумісності з попередніми версіями SQL Server. У новій версії вони замінені обмеженнями цілісності CHECK, які є більш потужним засобом і визначаються при створенні таблиці. Правила ж створюються як окремі об'єкти, які згодом зв'язуються з конкретними полями таблиць. У цьому розділі будуть розглянуті правила як самостійні об'єкти бази даних. Для стовпця таблиці можна визначити тільки одне правило, але кілька обмежень цілісності CHECK. Якщо для одного стовпця визначені обмеження цілісності і правило, то будуть враховуватися як обмеження цілісності, так і правило. Створення правила не може виконуватися в одному пакеті з іншими командами Transact-SQL. Для створення правила використовується наступна команда Transact-SQL: CREATE RULE rule AS condition_exdivssion Розглянемо аргументи команди. Про rule-ім'я правила. При виборі імені необхідно дотримуватися загальних правил іменування об'єктів. При необхідності можна вказати ім'я власника. Про condition_exdivssion - логічне вираження, що визначає умову, що накладається на значення. В якості умови можна використовувати будь-які логічні команди, арифметичні оператори, вбудовані функції і предикати (наприклад IN, BETWEEN, LIKE). У виразі condition_exdivssion не можна посилатися на стовпці таблиць або на будь-які інші об'єкти бази даних. Вбудовані функції також не повинні посилатися на об'єкти бази даних. У виразі допустима одна локальна змінна, що починається з символу @. Як ім'я змінної можна використовувати довільну рядок. При виконанні правила змінна буде містити значення, яке користувач намагається ввести в стовпець з допомогою команди INSERT або UPDATE. Змінна може використовуватися в будь-яких логічних операціях. Наведемо приклад створення правила: CREATE RULE rule_one AS @ val> = 100 AND (ava1 <170 CREATE RULE rule_two AS (Plist IN ("MATRIX". "ACC", "SIS", "KIT") Правило може бути створено тільки в поточній базі даних. Саме по собі правило не виконує контролю даних. Створене правило необхідно пов'язати зі стовпцем таблиці або користувальницьким типом даних. Правило не може бути пов'язано з системним типом даних і стовпцями, що мають типи даних timestamp, text і image. При зв'язуванні правила зі стовпцем таблиці або користувальницьким типом даних слід переконатися, що тип даних у правилі і в об'єкті прив'язки збігаються. Сервер не відстежує відповідності типів даних при зв'язуванні. Помилка видається тільки тоді, коли користувач змінює значення і сервер починає виконання правила. Строго кажучи, сервер взагалі не виконує перевірки відповідності типів, він лише констатує помилку при порівнянні величин, що мають несумісний тип. Для зв'язування правила зі стовпцем таблиці або користувальницьким типом даних використовується збережена процедура sp_bindru1e з наступним синтаксисом: sp_b1ndrule [@ ru1ename =] "rule". [@ Objname =] "objectjname" [. [@ Futureonly =] "futureonlyjflag"] Призначення параметрів процедури sp_bindrule відповідає призначенню аналогічних параметрів збереженої процедури sp_bindef ault, описаної в попередньому розділі. Для «отвязиванія» правила використовується збережена процедура sp_unbindrule: sp_unb1ndrule [@ objname =] "object_name" [. [@ Futureonly =] "futureonly_flag"] Для отримання відомостей про правило (імені власника і дати створення) використовуйте збережену процедуру sp_hel p з зазначенням в якості аргументу імені правила: sp_he1p "rule_name" Для отримання тексту коду Transact-SQL, що визначає правило, використовуйте збережену процедуру sp_helptext: sp_helptext "rule_name" Для зміни імені правила використовуйте збережену процедуру sp_rename: sp_rename @ objname = 'rule_one' @ newname = 'rule_two' Управління умовчання Умовчання (default) - це значення, яке буде присвоєно стовпцю таблиці при вставці рядка, якщо в команді вставки явно не вказано значення для цього стовпця. Як і правила, умовчання залишені в SQL Server 2000 для забезпечення зворотної сумісності з попередніми версіями продукту (до версії SQL Server 7.0). Версія SQL Server 2000 дозволяє задавати умовчання для стовпців таблиці або користувальницького типу даних при їх створенні, використовуючи ключове слово DEFAULT. Застосування замовчувань і правил як окремих об'єктів бази даних було викликане неможливістю зміни таблиць до версії SQL Server 7.0. Було набагато простіше створити нове правило або замовчування, ніж видаляти таблицю і створювати її заново. Так як версії SQL Server 7.0 і 2000 дозволяють вільно змінювати структуру таблиць, то потреба в правилах і умовчання як окремих об'єктах відпала сама собою. Тому, якщо ви ще тільки створюєте власну базу даних, немає необхідності використовувати застарілі конструкції, подібні правилами і умовчання. До того ж немає абсолютно ніякої гарантії, що Microsoft буде підтримувати ці об'єкти в наступних реалізаціях SQL Server, так що при використанні правил і замовчувань перед вами рано чи пізно постане питання про зміну структури бази даних. Зараз ми розглядаємо умовчання, які існують у базі даних як самостійні об'єкти. Умовчання надають зручний спосіб швидко призначати однакові значення за замовчуванням безлічі стовпців таблиць бази даних. Тим не менше задавати значення за замовчуванням для стовпців рекомендується, використовуючи синтаксис команд CREATE TABLE і ALTER TABLE. Створене замовчування саме по собі не виконує ніяких дій. Його необхідно пов'язати з яких-небудь стовпцем таблиці або користувальницьким типом даних. Тип даних умовчання повинен відповідати типу даних, встановленому для стовпця, з яким пов'язується замовчування. Для створення умовчання використовується наступна команда: CREATE DEFAULT default AS constant_exdivssion Тут default-ім'я умовчання, a constant_exdivss1on - його значення. При виборі імені умовчання слід дотримуватися встановлених правил іменування об'єктів. Крім того, ім'я умовчання повинна бути унікальною для кожного власника. Вказівка ​​імені власника умовчання при його створенні не обов'язково. Як значення constant_exdivssion можна використовувати не тільки константи, а й будь-які математичні вирази і вбудовані функції. Рядки символів і дати мають полягати в одиночні лапки. Перед бінарними даними повинен вказуватися префікс Ох, а перед грошовим типом - символ $. Якщо розмір значення за замовчуванням перевищує розмір, встановлений для даних у стовпці, виконується усікання значення за замовчуванням до потрібного розміру. Наведемо приклад створення текстового умовчання: CREATE DEFAULT default one AS "RIAC Industries" Створення умовчання не може виконуватися в одному пакеті з іншими командами Transact-SQL. Умовчання може бути створено тільки в поточній базі даних. Після того як замовчування створено, його можна пов'язати зі стовпцем таблиці або користувальницьким типом даних. Для зв'язування умовчання з об'єктом бази даних використовується збережена процедура sp_bindefault, що має наступний синтаксис: sp_bindefault [@ defname =] "default", [(Pobjname =] "objectjiame" [. [@ Future] only =] "futureonly_flag"] Тут використовуються такі аргументи. Про "default" - ім'я умовчання. Це ім'я, вказане при створенні умовчання в команді CREATE DEFAULT. Про "object_name" - ім'я об'єкта, до якого прив'язується замовчування. Для зв'язування умовчання зі стовпцем таблиці ім'я об'єкта вказується у формі col umn. tab! e. Якщо ж використовується інша форма імені, то вважається, що замовчування зв'язується з призначеним для користувача типом даних. Умовчання не може бути пов'язане зі стовпцем типу timestamp, стовпцем з встановленим обмеженням цілісності IDENTITY або зі стовпцем, пов'язаним з іншим замовчуванням. В останньому випадку необхідно відв'язати від стовпця старе замовчування, а вже потім прив'язувати нове. Якщо умовчання пов'язується зі стовпцем, що мають користувальницький тип даних, і з цим типом даних пов'язана інша замовчування, то замовчування, визначений для стовпця, має пріоритет над замовчуванням, встановленим для користувальницького типу даних. Якщо в імені об'єкта присутні неприпустимі символи, то в аргументі ob ject_name необхідно використовувати роздільники [і] для вказівки імені об'єкта. Про "futureonly_flag" - цей аргумент потрібно тільки при зв'язуванні умовчання з призначеним для користувача типом даних і не потрібний при зв'язуванні з стовп- цом таблиці. При вказівці цього аргументу в стовпці, що мають користувальницький тип даних, з яким пов'язується замовчування, не буде внесено ніяких змін. Якщо ж аргумент f utureonl у не вказується, то для всіх стовпців користувальницького типу даних застосовується значення за замовчуванням, пов'язане з цим типом даних. Приклад зв'язування умовчання зі стовпцем таблиці: ЕХЕС sp_b1ndefault "default_one", "[Employes 013]. [Company name]" Приклад зв'язування умовчання з призначеним для користувача типом даних: ЕХЕС sp_bindefault "default_one". "Emp_data". "Futureonly" Якщо тип даних, визначений у замовчуванні, не відповідає типу даних, визначеного для пов'язаного стовпця, то при спробі вставки рядка в таблицю сервер видасть повідомлення про помилку. При зв'язуванні умовчання зі стовпцем таблиці повідомлення про невідповідність типів не видається, і зв'язування проходить успішно. Коли замовчування пов'язується зі стовпцем таблиці, інформація про зв'язуванні зберігається в системній таблиці бази даних syscolumns. При зв'язуванні умовчання з призначеним для користувача типом даних інформація зберігається в таблиці systypes. Якщо умовчання пов'язується зі стовпцем таблиці або користувальницьким типом даних, для яких визначено правило, то слід переконатися, що замовчування не конфліктує з правилом. В іншому випадку сервер буде видавати повідомлення про помилку кожного разу при додаванні в таблицю нового рядка без вказівки значення для стовпця. При зв'язуванні правила і умовчання зі стовпцем сервер не відстежує можливість подібних конфліктів, тому адміністратор повинен сам подбати про їх відсутність. При вставці нового рядка без вказівки значень для стовпчиків цим стовпцях присвоюється небудь значення за замовчуванням (якщо таке визначено), або значення NULL (якщо для стовпця дозволене зберігання значень NULL). Якщо для стовпця не визначено значення за замовчуванням і заборонено зберігання значень NULL, то при вставці порожнього рядка сервер видасть повідомлення про помилку. Якщо для стовпця дозволене зберігання значень NULL і встановлено значення за замовчуванням, то при вставці порожнього рядка значення за замовчуванням буде мати пріоритет над значенням NULL. Для видалення умовчання з бази даних використовується наступна команда: DROP DEFAULT {default} [,... n] Тут аргумент default визначає ім'я умовчання, яке необхідно видалити. Використовуючи одну команду DROP DEFAULT, можна видалити кілька замовчувань. Для цього необхідно перерахувати їх через кому. Не можна видалити замовчування, пов'язане зі стовпцем таблиці або користувальницьким типом даних. Перед видаленням необхідно відв'язати замовчування від усіх об'єктів, а вже потім виконувати команду DROP DEFAULT. Для отвязиванія умовчання використовується збережена процедура sp_unbindefault з наступним синтаксисом: sp_unbindefault [@ objname =] "object_name" [, [@ Futureonlу =] "futureonly_flag"] Тут використовуються такі аргументи. Про "object_name" - ім'я стовпця таблиці або користувальницького типу даних, від яких необхідно відв'язати замовчування. Коли замовчування відв'язується від призначеного для користувача типу даних, воно автоматично відв'язується від усіх стовпців, що мають цей тип даних, якщо тільки замовчування не було пов'язано з цими стовпчиками явно і в команді не вказано аргумент "futureonly". Про "f utureonl y_f 1 ag" - вказується тільки для користувача типів даних. Якщо цей аргумент має значення "futureonly", то замовчуванням не відв'язується від стовпців, які мають для користувача тип даних. Якщо цей аргумент відсутній, сервер автоматично відв'яже замовчування від всіх стовпців. Для отримання відомостей про подання (імені власника і дати створення) використовуйте збережену процедуру sp_help із зазначенням в якості аргументу імені умовчання: spjielp "default_one" Для отримання тексту коду Transact-SQL, що визначає замовчування, використовуйте збережену процедуру sp_helptext: sp_helptext "default_one" Для зміни імені умовчання використовуйте збережену процедуру sp_rename: sp_rename @ objname = 'defaul t_one' @ newname = 'default_two' Список літератури Мамаєв Є., Шкаріна Л. «Microsoft SQl Server 2000 для професіоналів» .- СПб: Питер, 2001 Хоторн Роб «Розробка баз даних, Micrososoft SQL Server 2000» .- Вільямс, 2001 Шарон Б., Мейбл Грег «Sql Server 2000, Енциклопедія програміста» .- ДіаСофт, 2001 33

Взаємодія з програмним забезпеченням Інтернету

Для встановлення всіх редакцій Microsoft SQL Server 2000 необхідно наявність в операційній системі Microsoft Internet Explorer 5.0. Винятком є ​​установка в режимі Connectivity Only (тільки з'єднання), яка вимагає Microsoft Internet Explorer 4.01 з Service Pack 2 і забезпечує тільки можливість встановлення з'єднання з SQL Server 2000.

Наявність Internet Explorer необхідно для роботи програми Microsoft Management Console (MMC), за допомогою якої реалізований інструмент адміністрування Enterprise Manager, а також для роботи електронної довідкової системи Books Online, реалізованої у вигляді скомпільовані HTML-файлу. При установці SQL Server 2000 на комп'ютер з Windows 2000 встановлювати окремо броузер Internet Explorer 5.0 не доведеться, тому що він безпосередньо вбудований в цю операційну систему.

У SQL Server 2000 була додана підтримка технології XML. Однак доступ до даних з використанням цієї технології здійснюється засобами Microsoft Internet Information Server (US). Таким чином, якщо передбачається забезпечити користувачам можливість роботи з даними за допомогою технології XML, слід додатково встановити Internet Information Server. У цьому випадку необхідно врахувати, що це накладає додаткові вимоги до ресурсів комп'ютера.

При роботі з операційною системою Windows 2000 установка Internet Information Server не потрібно, тому що ця операційна система поставляється разом з п'ятою версією цього продукту.

Взаємодія з мережевим програмним забезпеченням

Всі сучасні операційні системи сімейства Windows мають вбудовану підтримку можливості роботи з мережею. У більшості випадків ніяке додаткове забезпечення не потрібно. Винятком є ​​протоколи Banyan VINES або AppleTalk ADSP, робота з якими забезпечується продуктами третіх виробників.

Якщо планується використання SQL Server 2000 в якості корпоративного сервера баз даних, до которолгу передбачається звернення безлічі користувачів мережі, то в операційній системі необхідно встановити відповідні мережеві протоколи. Майстер установки SQL Server 2000 не виконує установку мережевих протоколів, тому ця частина роботи повинна бути виконана користувачем. SQL Server 2000 підтримує всі основні протоколи Windows 2000: NetBEUI, IPX / SPX і TCP / IP. Крім того, можлива робота по протоколах AppleTalk ADSP, Banyan VINES і деяким іншим рідко використовуваних протоколів.

Встановлення мережних протоколів ще не дає можливості працювати з SQL Server 2000. Для забезпечення цієї можливості необхідно наявність програмного інтерфейсу, який би дозволяв працювати з SQL Server 2000. Таким інтерфейсом є так звані мережеві бібліотеки (network libraries). Ці бібліотеки поставляються у складі SQL Server 2000 і автоматично встановлюються в операційній системі при установці сервера. Більш докладно архі-

тектура та конфігурування мережевих бібліотек будуть розглянуті далі в цьому розділі в розділі «Встановлення мережних бібліотек та протоколів».

В якості клієнтів SQL Server 2000 можуть виступати не тільки програми, що працюють під управлінням операційних систем сімейства Windows, а й додатки операційних систем Apple Macintosh, OS / 2, UNIX і т. д. Проте в даний час Microsoft не надає драйверів ODBC під UNIX, хоча зв'язок з клієнтами UNIX можлива. Зазначені драйвери можуть бути розроблені незалежними виробниками.

Взаємодія з продуктами Microsoft

Для взаємодії Microsoft Access 2000 з SQL Server 2000 необхідно встановити Microsoft Office 2000 Service Release 1 або Access 2000 Service Release 1. Тільки в цьому випадку ви зможете звертатися до діаграм бази даних, що зберігаються процедурами, даними про структуру таблиць і уявлень, проте ніяких внесених користувачем змін не зберігається.

При роботі з Microsoft Visual Studio ® 6.0, ви не зможете отримати доступ до діаграм бази даних, що зберігаються процедурами, даними про структуру таблиць і уявлень в SQL Server 2000. Хоча встановлення Visual Studio 6.0 Service Pack 4 і дозволить виконувати зміни, все ж таки зберегти їх не вдасться.

Планування конфігурації сервера

Якщо у вашій організації передбачається наявність декількох серверів баз даних, що взаємодіють між собою і обмінюються даними, то необхідно розробити єдину конфігурацію, яка буде реалізована на всіх серверах SQL Server вашого підприємства. Існує декілька параметрів встановлення сервера, які суттєво впливають на функціонування SQL Server і не можуть бути змінені в процесі роботи. У SQL Server 7.0 до них ставилися наступні: Про набір символів (character set); Про зіставлення Unicode (Unicode collation); Про порядок сортування (sort order).

Щоб змінити будь-яку з цих налаштувань, необхідно було перебудувати системну базу даних master за допомогою утиліти rebuildm.exe, яка дозволяє змінити порядок сортування, набір символів і зіставлення Unicode. Однак при виконанні подібного перестроювання втрачається будь-яка інформація, накопичена на сервері. У цьому плані перестроювання бази даних master можна порівняти з видаленням і встановлювати сервера. Якщо ж було необхідно зберігати власні бази даних і об'єкти, доводилося спочатку створювати сценарії (script), що описують створення всіх об'єктів, а потім копіювати дані, використовуючи можливості служб перетворення даних (Data Transformation Services, DTS) або утиліту масового копіювання (bulk copy program, bcp).

У SQL Server 2000 більше не потрібно окремо визначати кодову сторінку, використовувану для символьних даних, порядок сортування символьних даних і зіставлення для даних Unicode. Замість цього ви просто вказуєте необхідні назва зіставлення та сортування.

Фізичне зберігання символьних рядків і операції їх порівняння в SQL Server 2000 залежать від зіставлення. Зіставлення визначає виконавчі зразки, які представляють кожен символ, і правила, за якими символи сортуються і порівнюються. При роботі з SQL Server 7.0 ці параметри задавалися при установці сервера і були єдині для всіх об'єктів і даних, наявних в базах даних цього сервера.

У SQL Server 2000 значення зіставлення, вказаний при установці сервера, розглядається лише як значення за замовчуванням, яке використовується при створенні всіх об'єктів. Дозволяється створення різних зіставлень в одній і тій же базі даних одного і того ж сервера об'єктів. Більш того, в одній таблиці можуть бути стовпчики, які використовують різні зіставлення.

SQL Server 2000 підтримує два види зіставлень.

Про Зіставлення Windows (Windows Collation). Цей вид зіставлення визначає набір правил для зберігання і сортування символьних даних, заснованих на правилах, визначених для операційної системи Windows.

Про Зіставлення SQL (SQL Collation). Цей вид зіставлення забезпечує сумісність з більш ранніми версіями Microsoft SQL Server.

Кожне зіставлення SQL включає в себе наступну інформацію.

Про Порядок сортування для даних Unicode (nchar, nvarchar і ntext). Порядок сортування визначає послідовність, в якій сортуються символи, і те, як оцінюються символи при операціях порівняння.

Про Порядок сортування для символьних даних, що не відносяться до Unicode (char, varchar-і text).

Про Кодова сторінка, яка використовується для сортування символьних даних, що не відносяться до Unicode.

Щоб при установці провести зміни заданих за замовчуванням параметрів налаштування зіставлення, використовуйте вікно Collation Settings (параметри зіставлення). Варіант Collation Designator (призначення зіставлення) забезпечує настроювання параметрів зіставлення Windows, а варіант SQL Collations (зіставлення SQL) - настройку параметрів зіставлення, сумісних з SQL Server 7.0, SQL Server 6.5 або більш ранніми версіями.

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

Вибір зіставлення

На одному з етапів установки у вікні Collation Settings (параметри зіставлення) майстер установки SQL Server 2000 пропонує вибрати зіставлення (collation), яке буде використовуватися за замовчуванням на сервері. Цей вибір здійснюється за допомогою списку, з варіантами допустимих зіставлень. Наприклад.

Про Варіант Latinl_General призначений для американізованого англійської набору символів (кодова сторінка 1252).

Про Варіант Modern_Spanish призначений для всіх різновидів іспанског мови, в якому використовується той же набір символів, що і в англійське (кодова сторінка 1252).

Про Варіант Arabic призначений для всіх різновидів арабської мови довая сторінка 1256).

Про Для Росії за умовчанням пропонується використовувати зіставлення Windows, що називається Cyrillic_General, тим не менш можна вказати будь-яке інше зіставлення. Також можна вибрати зіставлення SQL. У цьому випадку в розпорядженні користувача є безліч різних зіставлень, кожне з яких має свої відмінні характеристики. Зіставлення для Росії використовують набір символів 1251, тобто закінчуються на рядок for use the 1251 (Cyrillic) Character Set. На рівні сервера зазначені зіставлення відносяться до сімейства зіставлень SQL_Latinl_General. Зокрема, при виборі зіставлення Windows з ім'ям Cyrillic_General на рівні сервера буде використовуватися зіставлення SQL_Latinl_General_Cpl_CI_AS. Це зіставлення влаштує більшість користувачів. Зокрема, при порівнянні символів не враховується регістр.

Вибір порядку сортування

Зіставлення Windows визначає тільки набір символів, який буде доступний користувачам. Однак власне порівняння не визначає правила порівняння і сортування символьних даних. Тому ці параметри повинні бути налаштовані окремо. Для цього у вікні Collation Settings (параметри зіставлення) використовується набір прапорців Sort Order (порядок сортування), за допомогою яких дозволяється той чи інший метод сортування. У табл. 7.5 вказано призначення прапорців.

Таблиця. Типи сортування

Тип сортировки______Описание________________________________

Binary Order (двійкова сортування)

Case-sensitive (з урахуванням регістру)

Accent-sensitive (з урахуванням діакритичних знаків)

Двійкова сортування є найшвидшим методом порівняння даних і завжди враховує регістр. Однак при використанні цієї сортування прапорці Case-sensitive (з урахуванням регістру) і Accent-sensitive (з урахуванням діакритичних знаків) будуть недоступні.

Як вже було сказано, вибрані при установці сервера параметрами? Ри зіставлення впливають на багато аспектів функціонування SQL Server 2000. Наприклад, порядок сортування грає велику роль при порівнянні пароля, введеного користувачем, з паролем, збереженим в системній базі даних. Якщо застосовується порядок сортування, чутливий до регістру символів, то при введенні пароля користувач повинен в точності дотримуватися регістр. Якщо ж використовується нечутлива до регістру сортування, то користувач може не піклуватися про регістрі, в якому він набирає пароль.

Коли ви передаєте дані користувачів (включаючи паролі) між серверами, мають різний порядок сортування, можливо два варіанти поведінки сервера, на який переносяться дані (сервера призначення).

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

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

Вибір методу установки

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

Система SQL Server 2000 може бути встановлена ​​з використанням одного з таких методів установки: Про Local Installation (локальна установка); Про Remote Installation (віддалена установка); Про Unattended Installation (автоматична установка).

Розглянемо більш детально використання кожного типу установки.

Локальна установка

При локальній установці всі файли SQL Server встановлюються на той комп'ютер, на якому вона ініційована.

Локальний метод установки є найпростішим з усіх підтримуваних. У цьому випадку майстер установки послідовно видає користувачеві набір вікон, в яких той повинен вказати параметри конфігурації. У процесі установки вам буде необхідно ввести своє ім'я, найменування організації і серійний номер, отриманий при купівлі SQL Server 2000. Ця інформація також необхідна, якщо ви звертаєтеся до служби технічної підтримки Microsoft. На наступних етапах необхідно ввести інформацію про розміщення файлів сервера і баз даних, кодовій сторінці, порядку сортування, зіставленні, мережевих протоколах і бібліотеках, а також відомості про облікові записи, під якими буде запускатися SQL Server. Для запуску майстра установки SQL Server 2000 необхідно запустити програму Setupsql.exe.

За замовчуванням для установки сервера вибирається папка \ Program Files \ Mic SQL Server, а бази даних розміщуються в панку \ Data настановної папки SQL Server 2000 (Mssql). У процесі установки програма збирає всі дані про параметри конфігурації, що вводяться користувачем, і зберігає їх у файлі Setup.iss. Файл Setup.iss ви можете знайти в папці \ Install настановної папки SQL Server 2000.

Файл Setup.iss згодом може виявитися дуже корисним для повторної локальної установки, а також для виконання видаленою або автоматичної установки.

Крім того, в процесі установки ведеться журнал, в якому відображається інформація про кожну фазу установки. Журнал представляє собою звичайний файл з ім'ям Sqlstp.log, який зберігається в кореневій папці операційної системи, наприклад у папці \ WinNT. Інформація про помилки у процесі установки записується у файли Errorlog і зберігається в папці \ l_og настановної папки SQL Server 2000.

Після того, як всі файли сервера скопійовані і всі підготовчі операції виконані, програма установки приступає до налаштування параметрів роботи сервера.

Віддалена установка

Windows NT і Windows 2000 надають нам справді приголомшливі можливості, дозволяючи не тільки виробляти віддалене адміністрування комп'ютерів домену, але і встановлювати програмне забезпечення на комп'ютері, що знаходиться в сусідній кімнаті, не встаючи з-за робочого столу.

Віддалена установка запускається також програмою Setupsql.exe на тому комп'ютері, з якого виробляється віддалена установка. Однак крім даних, необхідних при локальній установці, від вас буде потрібно ввести ще й додаткову інформацію - це й зрозуміло, оскільки в цьому випадку використовується ще й мережа: Про Username (ім'я користувача) - ім'я користувача, обліковий запис якого

буде використана на віддаленому комп'ютері для виконання установки SQL Server 2000;

Про Password (пароль) - пароль користувача;

Про Domain (домен) - ім'я домену, до якого належить обліковий запис користувача;

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

Про Target Computer (цільовий комп'ютер) - ім'я віддаленого комп'ютера, на який буде проводитися встановлення SQL Server 2000;

Про Target Path (UNC) (цільової шлях у форматі UNC) - повний опис шляху в форматі UNC до папки, в яку планується встановити SQL Server '.

Про Setup Source Files (настановні файли) - повний шлях у форматі UNC до установочних файлів SQL Server 2000 в мережі.

Після того як будуть введена інформація для зазначених вище параметрів, подальша робота майстра установки вельми нагадує локальну установку. Майстер збирає інформацію про всі параметри установки, таких як зіставлення, імена і паролі облікових записів для запуску служб SQL Server 2000, настановна папка для самого сервера і папка для зберігання баз даних, список встановлюваних компонентів і т. д. Після того як вся необхідна для установки SQL Server 2000 інформація введена, вона, як і при виконанні локальної установки, зберігається у файлі Setup.iss. Однак власне встановлення сервера при цьому майстер установки не виконує. Він лише запускає на віддаленому комп'ютері програму remsetup.exe, яка і буде виконувати установку SQL Server 2000. На цьому робота майстра установки Installation Wizard (програми setup.sql) закінчується.

Для віддаленої установки можна використовувати готовий файл Setup.iss, згенерований раніше при виконанні локальної установки. При необхідності в цей файл можна внести деякі зміни. Для цього можна використовувати звичайний текстовий редактор.

На віддаленому комп'ютері програма remsetup.exe копіює файли, необхідні для установки, в мережеву папку Admin $, в тому числі і файл Setup.iss, з якого зчитує дані про установку. Після цього починається власне установка SQL Server 2000.

Дистанційна установка дозволяє встановити SQL Server на велику кількість вилучених комп'ютерів з одного центрального комп'ютера. Для того щоб віддалена установка пройшла успішно, майстру установки необхідно мати такі права:

О на локальному комп'ютері - права на запуск майстра установки і збереження файлу Setup.iss;

О на віддаленому комп'ютері - права доступу з адміністративними повноваженнями.

Не обов'язково, щоб користувач, який запускає програму установки, мав права адміністратора на віддаленому комп'ютері. Майстер установки дозволяє явно вказати обліковий запис, яка буде використана на віддаленому комп'ютері для запуску програми Remsetup.exe. Крім того, підійде будь-яка обліковий запис, в тому числі обліковий запис користувача, що запускає програму Setupsqi.exe на локальному комп'ютері. Також може бути використана одна з облікових записів, сконфігурованих для запуску служб SQL Server 2000. Єдиною вимогою є наявність необхідних прав доступу.

Виконання віддаленої установки можливе тільки в тому випадку, якщо локальний і віддалений комп'ютери працюють під управлінням операційної системи Windows NT або Windows 2000.

Автоматична установка

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

Автоматична установка може бути виконана двома способами: О з використанням Microsoft Systems Management Server (SMS); Про з використанням файлу автоматичної установки Setup.iss.

Використання Microsoft Systems Management Server

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

Microsoft System Management Server - сервер управління системою - є ключовою ланкою пакету Microsoft BackOffice, дозволяючи істотно полегшити життя системних адміністраторів. Однією з можливостей сервера SMS є його здатність виконувати типову установку програмного забезпечення на велике число комп'ютерів мережі з мінімальною участю користувача.

Ви можете використовувати Microsoft System Management Server версії 1.2 або вище для автоматичної установки Microsoft SQL Server 2000 на великій кількості комп'ютерів мережі підприємства.

Компакт-диск з SQL Server поставляється з файлом Smssql.pdf, який автоматично створює інсталяційний пакет SMS. Після цього сервер можна встановлювати за допомогою SMS на багатьох комп'ютерах. Файли. Pdf представляють собою звичайні текстові файли, в яких міститься інформація про дії, які повинні бути виконані Microsoft SMS. Файл Smssql.pdf містить команди для запуску bat-файлів, що поставляються на компакт-диску з дистрибутивом SQL Server 2000. Файл smscli.bat призначений для виконання автоматичної установки утиліт адміністрування SQL Server 2000 з використанням пакету SMS. Файл smssqins.bat призначений для виконання звичайного встановлення утиліт адміністрування SQL Server 2000 з використанням пакету SMS. При необхідності користувач може скопіювати файл smssql.pdf і внести до нього необхідні зміни.

Використання файлу автоматичної установки

Автоматична установка SQL Server може бути зроблена за допомогою спеціального файла-сценарію, що містить опис всіх параметрів, які користувач повинен вказати в процесі установки, позбавляючи його тим самим від особистої присутності при установці. Автоматична установка також використовується при віддаленій установці.

Створення файлу автоматотеской установки Setup.iss можливо одним з двох способів. По-перше, можна використовувати для цього будь-який текстовий редактор, наприклад Notepad. Другий альтернативою буде запуск програми Setupsql.exe з ключем k = Rc. Цей ключ вказує програмі установки спочатку зібрати всі відомості про конфігурації, а потім почати копіювання файлів. Коли збір відомостей закінчується, з'являється діалогове вікно, яке попереджає про початок копіювання файлів. Якщо клацнути на кнопці Cancel (скасування), то програма установки збереже всі введені дані в папці операційної системи у файлі Setup.iss. Необхідно лише додати секції [SdStartCopy-О] і [SdFinish-0] вкінець файлу

Файл Setup.iss також створюється і в разі звичайного встановлення. При створенні файлу автоматичної установки слід враховувати, що можливість його використання для встановлення SQL Server на безліч комп'ютерів залежить від конкретної ситуації. Наприклад, якщо при створенні файлу Setup.iss ви використовували локальну обліковий запис, а на віддаленому комп'ютері не існує користувача з таким же ім'ям і паролем, установка може не вдатися. Конфігурація дисків на комп'ютерах також повинна бути однаковою.

SQL Server 2000 постачається з п'ятьма виконуваними bat-файлами: Про sqlcli.bat - встановлює тільки засоби управління SQL Server 2000, використовує у своїй роботі файл автоматичної установки sqlcli.iss;

Про sqlins.bat - виконує типову установку, встановлюючи локальну обліковий запис системи для запуску служб, використовує файл sqlins.iss;

Про sqlcst.bat - виконує замовну встановлення усіх компонентів, встановлюючи локальну обліковий запис системи для запуску служб, запускає програму Setupsql.exe з файлом sqlcst.iss;

Про sqlupg.bat - виконує автоматичне оновлення до SQL Server 2000 на операційній системі Windows NT;

Про sqlrem.bat - видаляє SQL Server 2000.

Ви також можете скопіювати та відредагувати будь-який з цих файлів на свій розсуд. Наприклад, дозволити використання доменної облікового запису користувача у файлі sqlins.iss для виконання типової установки.

Якщо ви не впевнені, що готові пуститися в самостійне плавання, найкраще скористатися розробленої Microsoft стандартною установкою, що підходить більшості користувачів.

Створення облікових записів

SQL Server 2000 під управлінням операційних систем Windows NT і Windows 2000 функціонує як служба операційної системи, або, точніше, як дві служби - MSSQLServer і SQLServerAgent. Система захисту Windows NT і Windows 2000 вимагає, щоб будь-який доступ до ресурсів був підтверджений наявністю відповідних прав. Хоча всі служби і є частиною однієї програми, все ж перед тим як почати роботу, вони зобов'язані пройти перевірку прав доступу подібно звичайним користувачам. Як відомо, права та дозволи призначаються на основі облікових записів. Таким чином, деякі служби SQL Server 2000, які звертаються до ресурсів мережі, зобов'язані мати власні облікові записи, причому різні служби можуть мати різні облікові записи.

Цей розділ має відношення тільки до операційних систем сімейства Windows NT і Windows 2000. В операційній системі Windows 98 не реалізована можливість виконання при-1 положень у вигляді служб операційної системи. При запуску SQL Server 2000 під керуванням цієї j операційної системи використовується обліковий запис поточного користувача. Як наслідок, SQL 'Server 2000 буде мати ті ж права доступу, що і користувач, що запустив цей додаток. '

Різниться три види облікових записів, під якими може стартувати SQL;

Server.

Про Local System (локальна система). Обліковий запис локальної системи створюється автоматично при установці операційної системи. Під цим обліковим записом служба SQL Server запускається з правами операційної системи. Всі дії з управління цим обліковим записом, в тому числі й зміни пароля, виконує сама операційна система. Навіть адміністратор не може керувати нею. Цей обліковий запис має права адміністратора і зазвичай за умовчанням їй надається доступ до всіх файлів. Проте якщо ви вирішили для запуску SQL Server 2000 використовувати локальну обліковий запис, переконайтесь в тому, що вона має повний доступ до всіх необхідних файлів і папок SQL Server 2000, і якщо буде потрібно, то надайте самі цього облікового запису доступу до тих чи інших ресурсів.

Про Local User (локальний користувач). Цей обліковий запис створюється на окремому комп'ютері. Відповідно, область дії таких облікових записів обмежується одним цим комп'ютером. При запуску SQL Server 2000 під обліковим записом локального користувача, який не входить до групи локальних адміністраторів, слід надати цього облікового запису повний доступ до всіх файлів і папок SQL Server 2000, а також дозволити їй реєструватися локально і стартувати в якості служби операційної системи.

Про User for Domain (користувач домену). Принциповою відмінністю облікових записів користувача домену є можливість роботи в мережі. Облікові записи цього типу зберігаються централізовано на контролері домену (domain controller) Windows NT або Windows 2000 і доступні з будь-якого комп'ютера, що входить до домену.

Облікові записи локальної системи і локального користувача не підтримують мережні операції. Отже, коли сервер SQL Server 2000 працює під локальної обліковим записом, то він матиме обмежені можливості. Зокрема, не можна буде виконувати наступні дії: Про виклик віддалених процедур (Remote Procedure Calls, RPC); Про реплікація; Про резервне копіювання даних на мережний диск;

Про використання різнорідних джерел даних, що вимагають мережевого з'єднання;

Про підтримка електронної пошти.

Таким чином, вибираючи тип облікового запису, враховуйте ті можливості, які вона надає.

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

Основним компонентом SQL Server 2000 є служба MSSQLServer. Всі інші компоненти (SQLServerAgent, Microsoft Search і MSDTC) встановлюють з'єднання з MSSQLServer. При цьому облікові записи, під якими стартують служби SQLServerAgent і MSDTC, повинні мати відповідні права на самому сервері. Для цього необхідно призначити відповідним облікових записів вбудовану роль сервера (fixed server role) Sysadmin.

Служба Microsoft Search може стартувати тільки під локальної обліковим записом системи. Для встановлення з'єднання зі службою MSSQLServer вона використовує ім'я та пароль учетнбй запису, під якою стартує служба MSSQLServer.

Як вже говорилося вище, кожна служба SQL Server 2000 може стартувати під власною обліковим записом. Але якщо немає особливих на те причин, то для того щоб уникнути проблем з правами доступу, рекомендується запускати всі служби під одним обліковим записом. Також можна надати облікових записів служб права адміністратора локальної операційної системи, включивши їх до групи Administrators. Це дасть можливість SQL Server 2000 перезапускати сервер і допоможе уникнути деяких проблем з автоматичним виконанням завдань (jobs). Однак такий підхід відкриває потенційну можливість злому системи з використанням SQL Server 2000. Якщо ви хочете максимально убезпечити систему, то краще витратити деякий час на конфігурування прав доступу, не надаючи облікового запису адміністративних прав.

Незалежно від того, під який обліковим записом передбачається запуск служб SQL Server 2000, необхідно переконатися в тому, що ця обліковий запис має такі права:

Про доступ і зміна файлів в папці \ Program Files \ Microsoft SQL Server \ Mssql; Про доступ і зміна файлів баз даних - mdf, ndf і Idf;

Про читання і запис наступних ключів реєстру:

* HKEY_LOCAL_MACHINE \ Software \ Microsoft \ MSSQLServer; »HKEY_LOCAL_MACHINE \ System \ CurrentControl set \ Services \ MSSQLServer. . Якщо властивості запуску служб SQL Server 2000 сконфігуровані некоректно, то згодом їх можна змінити за допомогою утиліти Services (служби) з вікна Control Panel (панель управління) або за допомогою інтерфейсу Enterprise Manager

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

Основним компонентом SQL Server 2000 є служба MSSQLServer. Всі інші компоненти (SQLServerAgent, Microsoft Search і MSDTC) встановлюють з'єднання з MSSQLServer. При цьому облікові записи, під якими стартують служби SQLServerAgent і MSDTC, повинні мати відповідні права на самому сервері. Для цього необхідно призначити відповідним облікових записів вбудовану роль сервера (fixed server role) Sysadmin.

Служба Microsoft Search може стартувати тільки під локальної обліковим записом системи. Для встановлення з'єднання зі службою MSSQLServer вона використовує ім'я та пароль учетнбй запису, під якою стартує служба MSSQLServer.

Як вже говорилося вище, кожна служба SQL Server 2000 може стартувати під власною обліковим записом. Але якщо немає особливих на те причин, то для того щоб уникнути проблем з правами доступу, рекомендується запускати всі служби під одним обліковим записом. Також можна надати облікових записів служб права адміністратора локальної операційної системи, включивши їх до групи Administrators. Це дасть можливість SQL Server 2000 перезапускати сервер і допоможе уникнути деяких проблем з автоматичним виконанням завдань Gobs). Однак такий підхід відкриває потенційну можливість злому системи з використанням SQL Server 2000. Якщо ви хочете максимально убезпечити систему, то краще витратити деякий час на конфігурування прав доступу, не надаючи облікового запису адміністративних прав.

Незалежно від того, під який обліковим записом передбачається запуск служб SQL Server 2000, необхідно переконатися в тому, що ця обліковий запис має такі права:

Про доступ і зміна файлів в папці \ Program Files \ Microsoft SQL Server \ Mssql; Про доступ і зміна файлів баз даних - mdf, ndf і Idf; Про читання і запис наступних ключів реєстру:

«HKEY_LOCAL_MACHINE \ Software \ Microsoft \ MSSQLServer;

»HKEY_LOCAL_MACHINE \ System \ CurrentControlset \ Services \ MSSQLServer.

Якщо властивості запуску служб SQL Server 2000 сконфігуровані некоректно, то згодом їх можна змінити за допомогою утиліти Services (служби) з вікна Control Panel (панель управління) або за допомогою інтерфейсу Enterprise Manager.

Створення облікових записів в Windows 2000

Створення облікових записів в Windows 2000 відрізняється від створення облікових записів в Windows NT 4.0. Для керування обліковими записами користувачів домену Windows 2000 використовується оснастка (у термінології Windows NT-утиліта) Active Directory Users and Computers. Коли ж виконується конфігурування облікових записів локальних користувачів, то використовується оснастка Computer Management (рис. 7.4). У цьому розділі буде розглянуто створення облікових записів для локальних користувачів Windows 2000. Створення користувачів домену відрізняється лише тим, що потрібна інша утиліта і введення кілька більшої кількості інформації про користувача. Однак ми не будемо розглядати конфігурування додаткових відомостей про користувача, таких як адресу його електронної пошти, профіль, можливість використання RAS і т. д.

При роботі з оснащенням Computer Management інформація про локальні користувачів зберігається в папці System Tools \ Local Users and Groups \ Users. При виборі в лівій частині вікна цієї папки в правій частині буде відображений список всіх користувачів, створених на обраному для адміністрування комп'ютері. Для створення нового користувача необхідно в контекстному меню папки Users вибрати пункт New User (новий користувач). У відповідь відкриється однойменне діалогове вікно (рис. 7.5), за допомогою якого необхідно вказати основні відомості про створюваної облікового запису.

Якщо комп'ютер, на який передбачається встановити SQL Server 2000, є контролером домену Windows 2000, то використання локальних облікових записів користувачів на цьому комп'ютері неможливо, тому відповідні пункти оснащення Computer Management будуть недоступні.

Розглянемо призначення елементів управління, наявних у вікні New User

(Новий користувач).

Про User name (ім'я користувача). Ім'я облікового запису, яке буде використовуватися при реєстрації користувача в домені. Це ім'я може бути довільним і не завжди відображати ім'я самого користувача.

Про Full name (повне ім'я). У цьому полі вказується повне ім'я власника облікового запису.

Про Description (опис). Це поле призначене для невеликого коментарю, який допомагає ідентифікувати обліковий запис або її власника. Допускається короткий запис будь-яких інших відомостей.

Про Password (пароль). У цьому полі вказується пароль, під яким користувачеві буде вирішуватися вхід в домен.

Про Conform Password (підтвердження пароля). У цьому полі необхідно повторити той же пароль, що і в попередньому полі. Це робиться, щоб гарантувати введення правильного пароля і уникнути помилок.

Про User must change password at next logon (користувач повинен змінити пароль при наступному вході в систему). Встановивши цей прапорець, адміністратор тим самим зажадає від користувача зміни пароля при наступному вході в домен.

Про User cannot change password (користувач не повинен міняти пароль). Якщо адміністратор встановить для користувача цей прапорець, то користувач не зможе самостійно змінити пароль і буде змушений звернутися до адміністратора. Така ситуація необхідна, якщо крім цього користувача під тим же самим паролем працює ще хто-небудь. У цьому випадку адміністратор зможе сповістити другого користувача про те, що пароль був змінений.

Про Password never expires (термін дії пароля не закінчується). Установка цього прапорця дозволяє уникнути частої зміни пароля користувачем.

Про Account disabled (блокування облікового запису). При установці цього прапорця обліковий запис блокується і не допускає реєстрації в домені ні господаря облікового запису, ні кого-небудь ще. Ця можливість часто використовується, якщо передбачається тривала відсутність користувача на робочому місці. Такий підхід допоможе уникнути несанкціонованого доступу до ресурсів. Щоб використовувати облікові записи користувачів Windows 2000 для запуску служб Server 2000, як і при конфігуруванні облікових записів Windows NT 4.0, їм необхідно надати додаткові права. У Windows 2000 управління правами здійснюється окремо від управління обліковими записами. Для управління правами в межах локального комп'ютера використовується оснастка Local Security Policy (рис. 7.6).

Для надання облікової запису необхідних прав виконайте такі дії.

1. В оснащенні Local Security Policy виберіть папку Local Policies.

2. У папці Local Policies виберіть вкладену папку User Right Assignment. У правій частині вікна буде виведений список прав, які можуть бути присвоєні користувачам.

3. Для присвоєння користувачеві того чи іншого права двічі клацніть на назві права і в діалоговому вікні Local Security Policy Settings (параметри локальної політики безпеки) клацніть на кнопку Add (додати), після чого виберіть ім'я потрібного користувача.

Як і при роботі з Windows NT, для того щоб облікова запис Windows 2000 могла використовуватися для запуску служб SQL Server 2000, їй необхідно надати такі права:

Про Act as a part of the operating system (діяти як частина операційної системи); Про Log on as a service (реєструватися в якості служби операційної системи);

Про Increase quotas (право змінювати квоти процесів);

Про Replace a process level token (право замінювати рівень маркера процесу).

Після того як всі зазначені права будуть надані облікового запису (або всіх облікових записів), яку передбачається використовувати для запуску служб SQL Server 2000, підготовку облікових записів можна вважати закінченою.

Вибір типу установки

При установці SQL Server 2000 в редакціях Enterprise, Standard, Personal edition майстер установки запропонує вам вибрати один з трьох типів установки. Про Звичайний тип установки (Typical). Встановлюються задані за замовчуванням компоненти. Такий тип установки рекомендується для більшості користувачів.

Про Мінімальний тип установки (Minimum). Встановлюється мінімальна конфігурація, необхідна для роботи SQL Server. Цей тип рекомендується для користувачів, що мають комп'ютер з невеликим доступним дисковим простором.

Про Вибірковий тип установки (Custom). Цей тип установки дозволяє вибрати необхідні саме для вас компоненти. Виробляти вибіркову установку рекомендується досвідченим користувачам.

Якщо ви запускаєте програму установки SQL Server для редакцій, які не підтримуються вашою операційною системою, наприклад, якщо встановлюється SQL Server Standard Edition під Microsoft Windows 98, програма не буде пропонувати вам вибрати тип установки. Натомість відразу пропонується обрати інструменти адміністрування в діалоговому вікні Select Components (вибір компонентів).

Встановлення мережних бібліотек і протоколів

Як вже було сказано раніше в цьому розділі, для забезпечення мережної взаємодії серверів SQL Server і їх клієнтів потрібні так звані мережеві бібліотеки (network library), що використовують певні мережні протоколи для передачі даних. Ці бібліотеки реалізовані у вигляді dll-файлів (Dynamic-link library, DLL), що підключаються до операційної системи. Сама по собі мережева бібліотека не забезпечує можливості комунікації, для цього необхідно встановити відповідний мережевий протокол. Бібліотека являє собою програмний інтерфейс, який реалізує роботу з SQL Server 2000. Мережеві бібліотеки встановлюються як на сервері, так і на клієнті.

SQL Server 2000, як: і SQL Server 7.0, може використовувати більшість мережевих протоколів операційної системи. Операційні системи сімейства Windows мають вбудовану підтримку мережі, тобто до складу цих операційних систем входить набір стандартних протоколів і служб, за допомогою яких можна виконувати базові мережеві операції роботи з файлами і принтерами. Управління мережевими протоколами можуть розрізнятися при роботі з різними операційними системами. Конфігурування же мережевих бібліотек практично не залежить від використовуваної операційної системи, так як ця операція здійснюється на рівні SQL Server 2000.

Встановлення мережних протоколів в Windows 2000

В операційній системі Windows 2000 установка і конфігурування мережевих протоколів дещо інша в порівнянні з Windows NT 4.0. Для управління налаштуваннями локальної мережі використовується вікно Local Area Connection Properties (властивості локального з'єднання).

1. У головному меню операційної системи виберіть пункт Start> Settings * Network and Dial-Up Connections (пуск> настройка> мережеві з'єднання).

2. У вікні (рис. 7.11) двічі клацніть на значку Local Area Connection (локальне з'єднання), після чого відкриється вікно Local Area Connection Status (стан локального з'єднання), показане на рис. 7.12.

1. Тепер залишається тільки клацнути на кнопці Properties (властивості), що і призведе до відкриття вікна Local Area Connection Properties (властивості локального з'єднання).

У вікні Local Area Connection Properties (властивості локального з'єднання) відображається назва мережевої карти і нижче наведений список мережевих протоколів і служб, встановлених для зазначеної мережевої карти. Щоб додати або видалити

протоколу використовуйте кнопки Install (встановити) або Uninstall (видалити). Щоб додати нового протоколу необхідно виконати наступні кроки.

1. Клацніть на кнопці Install (встановити). Після цього відкриється діалогове вікно Select Network Component Type (вибір типу мережевого компонента), яке призначене для вибору тина встановлюваного мережевого компонента

2. Для установки нового протоколу виділіть пункт Protocol (протокол) і клацніть на кнопці Add (додати). У результаті відкриється діалогове вікно Select Network Protocol (вибір мережевого протоколу), за допомогою якого, власне, і вибирається встановлюваний протокол (рис. 7.14). р мережевого протоколу) міститься перелік протоколів, що поставляються разом з операційною системою Windows 2000 і ще не встановлені у системі. Якщо передбачається встановити протокол стороннього виробника, то необхідно явно вказати папку, в якій містяться відповідні файли. Для цього потрібно скористатися кнопкою Have Disk (встановити з диска).

Після того як потрібний протокол обраний, залишається тільки клацнути на кнопці ОК. Для деяких протоколів (наприклад, NetBEUI) на цьому їх установка закінчується. Однак при роботі зі складними протоколами (наприклад, TCP / IP) може знадобитися конфігурування властивостей встановлюваного протоколу.

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

Одночасно SQL Server 2000 може працювати з декількома мережевими бібліотеками. У табл. 7.7 наведено список і призначення мережевих бібліотек, що поставляються в складі SQL Server 2000.

Мережева бібліотека Опис

AppleTalk ADSP Дозволяє клієнтам Apple Macintosh підключатися до серверів SQL Server 2000 по протоколу AppleTalk замість TCP / IP Sockets. Вам не обов'язково конфігурувати зони Apple Macintosh, так як використовується поточна зона. Бібліотека не підтримується на операційних системах Windows 95/98

Multiprotocol Працює через виклики віддалених процедур RPC з використанням

більшості механізмів IPC Windows NT: TCP / IP Sockets, Named Pipes, NWLink IPX / SPX і т. д. Не потребує конфігуруванні. Лри роботі під управлінням операційної системи Windows NT дозволяє шифрувати дані при передачі по мережі, а також виконувати аутентифікацію Windows NT поверх будь-якого протоколу. Не підтримується при установці SQL Server 2000 на Windows 98

Named Pipes Дозволяє SQL Server 2000 використовувати іменовані канали. Може
(Іменовані працювати поверх основних протоколів Windows. Слід враховувати, що
канали) Windows 98 не підтримує серверну частину іменованих каналів -
доступна тільки їх клієнтська частина. Використовується в Windows NT і
Windows 2000 за замовчуванням. За замовчуванням для SQL Server встановлюється
канал \ \. \ pipe \ sql \ query. Якщо на одному сервері встановлено декілька
копій SQL Server, то для звернення до конкретної копії потрібне канал
\ \. \ Pipe \ MSSQL $ instancename \ sql \ query

NWLink IPX / SPX Дозволяє підключатися до SQL Server 2000 клієнтам Novell NetWare
Shared Memory За допомогою бібліотеки Shared Memory можна імітувати систему
(Колективна клієнт-сервер на локальному комп'ютері, і тому її рекомендується
пам'ять) використовувати на комп'ютерах, які не мають підтримки мережі. Дана
бібліотека не є в повному сенсі мережевої, хоча і має ті ж
інтерфейси, що й інші бібліотеки

TCP / IP Sockets Працює поверх механізму IPC через сокети протоколу TCP / IP. Сокети (сокети TCP / IP) TCP / IP використовуються за замовчуванням на всіх операційних системах, в тому числі і на Windows 98. При установці цієї бібліотеки необхідно вказати порт, по якому буде здійснюватися обмін даними. Для SQL Server 2000 портом за замовчуванням є порт 1433. Можлива робота через проксі-сервер Banyan VINES За допомогою цієї бібліотеки можлива робота клієнтів, що використовують протокол Banyan VINES IP. Для цих клієнтів за протоколом Banyan VINES Sequenced Packet Protocol, що працює поверх протоколу Banyan VINES IP, _________організуется з'єднання через механізми IPC____________

У процесі установки SQL Server 2000 необхідно вибрати потрібні бібліотеки. Якщо якась потрібна бібліотека не була встановлена, то її можна встановити пізніше, скориставшись утилітою мережевого конфігурування сервера SQL Server Network Utility (рис. 7.15). Ця утиліта автоматично встановлюється разом з SQL Server 2000.

Для запуску цієї утиліти SQL Server Network Utility можна скористатися або головним меню операційної системи, вибравши пункт Start> Programs> Microsoft SQL Server> Server Network Utility (пуск> програми> Microsoft SQL Server> Server Network Utility), або запустивши файл svrnetcn.exe, який знаходиться в папці Tools \ Bin настановної папки SQL Server 2000. Після цього відкриється власне вікно утиліти, наведене на малюнку.

Як видно, вікно утиліти має дві вкладки - General (загальні) і Network Libraries (мережеві бібліотеки). У свою чергу, на вкладці General (загальні) є два списки - Disabled protocols (доступні протоколи) і Enabled protocols (встановлені протоколи). У першому списку перераховані бібліотеки, доступні для установки, але не використовуються в роботі сервера. Другий же список містить перелік бібліотек, які використовуються в поточній роботі SQL Server 2000. Для зміни параметрів будь-який з них необхідно виділити ім'я бібліотеки і клацнути на кнопці Properties (властивості), після чого відкриється діалогове вікно властивостей обраної мережевої бібліотеки. На рис. 7.16 наведено вікно властивостей бібліотеки Multiprotocol.

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

Встановлення та конфігурування клієнтів

Як вже було сказано, щоб клієнт мав можливість підключатися до SQL Server 2000, на ньому повинен бути встановлений принаймні один мережевий протокол і мережева бібліотека, відповідна мережевий бібліотеці сервера, В іншому випадку клієнт не зможе встановити з'єднання з SQL Server 2000. У складі всіх операційних систем сімейства Windows є набір загальних мережевих протоколів. Проте мережеві бібліотеки повинні бути встановлені окремо. Для їх цього можна скористатися майстром встановлення SQL Server 2000, вибравши режим установки Client Connective Only (тільки для з'єднання клієнта). У цьому випадку на комп'ютер буде встановлено тільки компоненти, необхідні для з'єднання клієнтів з SQL Server 2000.

Якщо на клієнті використовується декілька бібліотек, то з'єднання з сервером може бути встановлено за допомогою будь-якої з них. Однак після того, як з'єднання встановлено, робота з сервером ведеться за допомогою лише однієї бібліотеки, вибір якої відбувається наступним чином: клієнт по черзі перебирає бібліотеки, перераховані в списку Enabled Protocols (встановлені протоколи) вкладки General (загальні) утиліти SQL Server Network Utility, починаючи з самої верхньої. Якщо на сервері є аналогічна бібліотека та параметри конфігурації сервера і клієнта збігаються, то перебір на цьому зупиняється і для з'єднання вибирається ця бібліотека. Виходить, що бібліотека, що знаходиться вгорі списку, має більше шансів для встановлення з'єднання. Тому якщо бажано, щоб клієнт використовував конкретну бібліотеку, її слід помістити у верхній частині списку.

До компонентів, необхідним для з'єднання клієнтів з SQL Server 2000, відносяться мережеві бібліотеки і утиліта Client Network Utility (рис. 7.18), за допомогою якої виконується конфігурування мережевих бібліотек з боку клієнта. Запустити утиліту можна з головного меню операційної системи, вибравши пункт Start> Programs> Microsoft SQL Server> Client Network Utility (пуск> програми> Microsoft SQL Server> Client Network Utility) або запустивши файл cliconfg.exe з папки SYSTEM операційної системи Windows 98 або SYSTEM32 для Windows NT і Windows 2000.

Як видно з малюнка, вікно утиліти Client Network Utility має чотири вкладки. Перша з них має ім'я General (загальні) і призначена для управління набором бібліотек, що використовуються для встановлення з'єднання з сервером. Призначення списків Disabled protocols (доступні протоколи) і Enabled protocols (встановлені протоколи) цієї вкладки точно таке ж, як і для вкладки General (загальні) утиліти Server Network Libraries. У нижній частині вкладки є два прапорці.

Про Enable protocol encryption (включити шифрування протоколу) - установка пов го прапорця забезпечує шифрування даних, переданих по мережі. Однак шифрування буде використовуватися тільки в тому випадку, якщо воно дозволене як на клієнті, так і на сервері. Установка прапорця Enable protocol encryption (включити шифрування протоколу) тільки на клієнті без дозволу шифрування з боку сервера не забезпечує шифрування даних.

Про Enable shared memory protocol (включити протокол поділу пам'яті) - установка цього прапорця дозволяє колективне використання пам'яті. Подібний підхід використовується, коли сервер і клієнт знаходяться на одному комп'ютері. Обмін даними через оперативну пам'ять, а не мережеві протоколи, дозволяє підвищити швидкість обміну.

Можлива ситуація, коли клієнт буде взаємодіяти з декількома серверами, що використовують одну і ту ж мережеву бібліотеку, але з різними параметрами. Так як для кожної бібліотеки можна вказати тільки один варіант параметрів, то на клієнті потрібно буде кожен раз змінювати параметри конфігурації у відповідності з налаштуваннями сервера. У цьому випадку зручніше використовувати так звані псевдоніми серверів (server alias). Псевдонім має виразно ім'я і являє собою набір параметрів, що описують спосіб підключення клієнта до сервера. Ім'я псевдоніма сервера і власне ім'я сервера не обов'язково повинні збігатися. Більше того, кожен сервер може мати більше одного псевдоніма, кожен з яких може містити різні варіанти конфігурації мережевих бібліотек. Конфігурування псевдонімів здійснюється за допомогою вкладки Alias ​​(псевдоніми), показаної на рис. 7.19.

Конфігурування нового псевдоніму здійснюється за допомогою вікна Add Network Library Configuration (додавання конфігурації мережевої бібліотеки). Це вікно, показане на рис. 7.20, можна відкрити за допомогою кнопки Add (додати). У цьому вікні в полі Server alias (псевдонім сервера) необхідно вказати ім'я псевдоніма, через яке буде встановлюватися з'єднання з сервером. Клієнт повинен буде вводити не ім'я самого сервера, а відповідний псевдонім. Для кожного псевдоніма допускається використання лише однієї мережевої бібліотеки, вибір якої здійснюється за допомогою групи перемикачів Network libraries (мережеві бібліотеки). В області Connection parameters (параметри з'єднання) настроюються параметри вибраної бібліотеки. Конкретний набір параметрів залежить від того, яка бібліотека обрана. Після завдання всіх необхідних параметрів залишається тільки клацнути на кнопці ОК, після чого псевдонім буде додано до списку вкладки Alias ​​(псевдоніми).

Клієнт може звертатися до сервера, використовуючи технології ODBC, OLE DB, SQL-DMO (SQL Distributed Management Objects) і DB-Library, що працюють поверх мережевих бібліотек. Третя вкладка утиліти Client Network Utility називається DB-Library Options (параметри DB-Library) і містить інформацію про встановлену на клієнті версії DB-Library (рис. 7.21).

У групі DB-Library information (інформація DB-Library) вказуються основні відомості про бібліотеку. Зокрема, виводиться ім'я і шлях до відповідного dll-файлу, а також номер версії, дата створення і розмір файлу. У нижній частині вікна є два прапорці, які використовуються для управління параметрами встановлюваного за допомогою DB-Library з'єднання.

"Про Automatic ANSI to OEM conversion (автоматичне перетворення з OEM в ANSI) - установка цього прапорця забезпечує при передачі даних від клі-

''Ента до сервера автоматичне перетворення текстових даних з форма-та OEM у формат ANSI, і навпаки - перетворення з ANSI в OEM при передачі від сервера до клієнта.

Про Use international settings (використовувати національні установки) - при новке цього прапорця бібліотека DB-Library буде використовувати національні установки (формат дати, часу, валюти і т. д.) локальної системи. Якщо ж цей прапорець знятий, будуть використовуватися значення за замовчуванням, сконфігуровані в самій бібліотеці.

Прапорець Automatic ANSI to OEM conversion (автоматичне перетворення з OEM в ANSI) встановлений за замовчуванням на всіх клієнтах, тоді як прапорець Use international settings (використовувати національні установки) встановлено за умовчанням тільки на клієнтах, що працюють під управлінням 32-розрядних операційних систем.

За умовчанням як клієнти Windows NT 4.0, Windows 2000, так і клієнти Windows 98 використовують для підключення до сервера іменовані канали. Нагадаємо, що Windows 98 не підтримує серверну частину іменованих каналів.

Безпосередньо перед установкою SQL Server необхідно закрити всі програми і зупинити всі служби, що використовують ODBC, такі, наприклад, як Internet Information Service.

Запуск, зупинка і припинення служб

Перш ніж ви зможете зареєструватися в SQL Server і приступити до виконання будь-яких дій, сервер необхідно запустити. Точніше кажучи, запустити службу MSSQLServer. Для цього потрібно знати, яким чином можна це зробити. Тільки після того як буде здійснено запуск SQL Server і перевірені ваші права доступу, ви зможете виконувати будь-які дії відповідно до вашими правами, наприклад адміністрування сервера або виконання запитів.

Нагадаємо, що запуск служби SQLServerAgent необхідний тільки в тому випадку, якщо потрібно автоматизувати адміністрування та управління SQL Server 2000.

У цій главі будуть докладно розглянуті різні варіанти запуску служб SQL Server 2000, а також їх зупинка і припинення.

Ми вже не раз говорили, що основною службою SQL Server 2000 є служба MSSQLServer. Всі основні операції з об'єктами баз даних (виконання запитів, збережених процедур і т. д.) реалізуються саме завдяки цій службі. Інші служби SQL Server 2000 є другорядними, і їх робота будується на фундаменті, яке забезпечується службою MSSQLServer. У принципі, служби MSSearch і MS DTC можуть працювати і незалежно від SQL Server 2000, так як вони використовуються в роботі й інших продуктів. Тим не менш служба SQLServerAgent не може працювати без служби MSSQLServer. Ось чому цю службу необхідно запускати після запуску служби MSSQLServer.

Нагадаємо функції додаткових служб SQL Server 2000: Про служба SQLServerAgent відповідає за автоматичне виконання завдань і

повідомлення операторів про помилки в роботі сервера;

Про служба MSSearch дозволяє реалізувати пошук символьної інформації в полях таблиць баз даних;

Про служба MS DTC дозволяє організувати доступ до розподілених джерел інформації, розташованої як на локальному, так і на віддалених серверах. Додаткові служби запускаються окремо і встановлюють з'єднання

з сервером, подібно до звичайних клієнтам. Кожна така служба самостійно

підключається до MSSQLServer, використовуючи певні облікові записи з відповідними правами доступу. Отже, щоб почати роботу з SQL Server 2000, досить запустити службу MSSQLServer. Після цього користувачі можуть встановлювати з'єднання з сервером і виконувати будь-які дії.

Управління SQL Server в якості служби можливо засобами операційної системи як локально, так і віддалено. У вашій організації може бути встановлено декілька серверів баз даних, і ви можете запускати або зупиняти їх, працюючи на будь-якому комп'ютері, підключеному до мережі (можливо, навіть без встановлених SQL Server і засобів адміністрування).

Майже все вищесказане відноситься до комп'ютерів, що працюють під управлінням операційних систем сімейства Windows NT. Оскільки операційна система Windows 95/98 не має служб, ви можете запускати, зупиняти і припиняти SQL Server тільки локально, тобто тільки на тому комп'ютері, де запущений сервер SQL Server.

Якщо на комп'ютері з SQL Server не встановлена ​​мережна підтримка, ви все ж зможете виконувати запуск, зупинку і призупинення SQL Server. Дії при цьому нічим не відрізняються від операцій з мережею. При установці з'єднання з локальним сервером, який не підтримує мережу, використовуються іменований ні канали. Іменовані канали безпосередньо звертаються до SQL Server, минаючи мережеві компоненти. Як у випадку роботи з мережею, так і без неї, за умовчанням встановлюється з'єднання за допомогою іменованих каналів. Йрі цьому використовується стандартний канал \ \. \ Pipe \ sql \ query, якщо явно не вказано будь-хто інший.

У разі якщо при підключенні не вказується ім'я сервера, проводиться пряме підключення до локального сервера з використанням локальних іменованих каналів. Якщо ж вказується ім'я віддаленого сервера, то використовуються мережеві іменовані канали або інший механізм, наприклад IPX / SPX.

Автоматичний старт

Одним із способів запуску служб SQL Server 2000 є їх запуск операційною системою. Такий спосіб запуску називається автоматичним, так як участі користувача в цьому випадку не потрібно. Запуск служби відбувається в момент завантаження операційної системи. Якщо після цього служба була зупинена, то користувач повинен буде запускати її вручну.

На одному з етапів установки користувач може дозволити автоматичний запуск служб SQL Server 2000. Якщо цього не було зроблено, згодом автоматичний запуск можна дозволити одним з таких методів. Про SQL Server Enterprise Manager. Щоб встановити автоматичний старт служб SQL Server 2000 засобами Enterprise Manager, необхідно вибрати сервер і відкрити вікно його властивостей, вибравши в контекстному меню пункт Properties (властивості). У відповідь відкриється SQL Server Properties вікно (властивості SQL Server), показане на рис. 10.1. У нижній частині вкладки General (загальні) є на-

бор прапорців, за допомогою яких можна дозволити автоматичний запуск для служб MSSQLServer, SQLServerAgent і MSDTC.

Про Засоби утиліти Services. Третій спосіб змусити SQL Server запускатися автоматично зводиться до використання вбудованих в операційну систему засобів управління службами. Таким засобом є утиліта Services (служби) у вікні Control Panel (панель управління) операційної системи. У вікні утиліти відображається список всіх служб, наявних в операційній системі. Для кожної служби відображається її поточний стан та параметри запуску (рис. 10.2). Запуск служби ідентифікується міткою Started (запущена) в поле Status (стан). У полі Startup Type (тип запуску) можливі три варіанти мітки: Automatic (автоматичний), Manual (ручний) і Disabled (відключена), які відповідно означають автоматичний запуск, ручний запуск і відключення служби. Для автоматичного запуску служб SQL Server 2000 двічі клацніть на імені потрібної служби. У відповідь відкриється вікно властивостей служби (мал. 10.3). Вибір методу запуску служби конфігурується за допомогою списку, Startup Type (тип запуску), в якому необхідно вибрати пункт Automatic (автоматичний).

Про Засоби утиліти SQL Server Service Manager. Утиліта SQL Server Service Manager
дозволяє запускати, зупиняти і припиняти служби SQL Server 2000
(Рис. 10.4). Крім того, з її допомогою можна встановити режим автоматичного
запуску для служб MSSQLServer, SQLServerAgent і MSDTC. Для цього необ
обхідно запустити Service Manager, вибрати потрібний сервер, вказати службу і уста-;
новить прапорець Auto-start service when OS starts (автоматично старт при запуску
операційної системи). Повторіть. Цю операцію на всіх серверах мережі для кож
дой служби, яку необхідно запускати в автоматичному режимі.

Якщо у вас виникне необхідність відключити автоматичний запуск SQL Server, скористайтеся будь-яким з перерахованих вище методів для відключення автозапуску.

Ручний запуск SQL Server

Якщо ви з яких-небудь причин не хочете використовувати автозапуск, доведеться кожного разу при завантаженні операційної системи вручну запускати SQL Server.

Аналогічні дії необхідно виконати в разі, коли ви перед цим з якихось причин зупинили SQL Server 2000 і не хочете перезавантажувати після цього операційну систему. Існує кілька способів для виконання ручного запуску служб SQL Server 2000.

Про Запуск SQL Server 2000 з вікна Control Panel (панель управління) зводиться до використання утиліти Services (служби). Аналогічно процедури встановлення автозапуску для цього необхідно вибрати потрібну службу, відкрити вікно властивостей служби (див. рис. 10.3) і клацнути у ньому на кнопці Start (пуск). Якщо в полі Startup Type (тип запуску) зазначений режим Disabled (відключена), то відразу запустити службу не вдасться. Попередньо необхідно змінити режим її запуску на Manual (ручний) або Automatic (автоматичний) і тільки після цього виконувати запуск служби.

Оскільки SQLServerAgent є залежною службою, спочатку необхідно запускати службу MSSQLServer і лише потім SQLServerAgent.

Про Другий спосіб ручного запуску SQL Server передбачає використання SQL Server Enterprise Manager. Для цього клацніть правою кнопкою миші на імені потрібного сервера. У контекстному меню можна вибрати команди, дозволені для сервера в даний момент (рис. 10.5). Таким способом можна запускати (команда Start), зупиняти (команда Stop) і припиняти (команда Pause) як локальні, так і віддалені сервери. Зауважимо, однак, що цей метод дозволяє запускати тільки службу MSSQLServer. Значок служби SQLServerAgent розташований в папці Management сервера. Викликавши його контекстне меню, ви можете керувати роботою цієї служби. Додаткові служби, такі як MSDTC і SQLMail, розташовуються в папці Support Services. Управління їх роботою здійснюється аналогічно.

Про Найбільш простий спосіб ручного запуску полягає у використанні адміністративної утиліти SQL Server Service Manager (див. рис. 10.4), спеціально призначеної для запуску, зупинки та припинення служб SQL Server. У вікні утиліти вам пропонується вибрати сервер і службу, з якими ви будете працювати. Значки відображають дії, доступні в даний момент для обраної служби.

Про Наступний спосіб запуску SQL Server передбачає використання утиліти командного рядка net start. Як параметр необхідно вказати ім'я служби, яку необхідно запустити, наприклад: net start mssqlserver net start sqlserver-agent

Для запуску служб іменованої копії необхідно додати її ім'я і знак долара перед ним. Наприклад, для запуску служби MSSQLServer копії TRELON використовується наступна команда: net start MSSQLSTRELON

Для запуску служби SQLAgent потрібно наступна команда: net start SQLAgentSTRELON

Виконання команди net start без імені служби призведе до висновку списку запущених в операційній системі служб.

Про Для запуску SQL Server можна також використовувати команду sqlservr. У цьому випадку SQL Server 2000 запускається не як служба, а як окреме додатку ження. Це означає, що всі засоби адміністрування (Service Manager, Enterprise Manager, Services в панелі управління) будуть показувати, що сервер зупинений. Використання команди net stop mssql server для зупинки SQL Server в цьому випадку видасть повідомлення про помилку, так як система вважає, що сервер не запущений. Всі системні повідомлення будуть з'являтися у вікні, в якому виконана команда sqlservr. Сервер буде запускатися під обліковим записом користувача, що працює в системі в даний момент, і якщо цей користувач вирішить завершити сеанс роботи в операційній системі, йому доведеться спочатку завершити роботу SQL Server.

Запуск SQL Server в режимі одного

За деяких обставин буває необхідно запустити SQL Server в режимі одного - наприклад, щоб виконати конфігурування важливих характеристик сервера або відновити пошкоджену системну базу даних.

У режимі одного служба MSSQLServer підтримує тільки одне з'єднання. Так як додаткові служби SQL Server 2000, подібно звичайним користувачам, встановлюють клієнтські з'єднання, то необхідно переконатися, що ці служби, наприклад SQLServerAgent або SQLMail, не запущені. В іншому випадку ви самі не зможете отримати доступ до сервера,

оскільки єдине можливе з'єднання буде вже задіяно. Переконайтеся, що клієнтські програми, які звертаються до SQL Server (такі як Internet Information Server), також зупинені.

При режимі одного «брудні» сторінки (dirty pages) негайно записуються на диск. Це означає, що дані, які були змінені після зчитування, відразу опиняться на диску, а не в кеш-пам'яті, як це буває при звичайній роботі.

Іншою особливістю роботи в режимі одного є те, що дозволено прямий доступ до системних таблиць, за замовчуванням заборонений в звичайному режимі. Прямий доступ до системних таблиць дозволяє модифікувати системні дані (структуру таблиць, користувачів, налаштування реплікації і т.д.) безпосередньо командами INSERT, DELETE і UPDATE. У звичайних умовах подібна модифікація виробляється з використанням збережених процедур і адміністративних утиліт.

Прямий доступ до системної інформації вимагає дуже високої кваліфікації та спеціальних знань. Більшості користувачів і системних адміністраторів буде достатньо коштів, наданих інтерфейсом SQL Server.

Для запуску SQL Server 2000 в режимі одного введіть наступну команду.

sqlservr.exe-т

Запуск SQL Server з мінімальними вимогами

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

Для запуску SQL Server 2000 як служби з мінімальними вимогами введіть наступну команду: sqlservr.exe-f

Якщо необхідно негайно запустити SQL Server 2000 з мінімальними вимогами як додаток, виконайте наступну команду: sqlservr.exe-f-с

Перед запуском SQL Server з мінімальними вимогами переконайтеся, що сервер зупинений і ніякі додаткові служби або програми, які можуть блокувати єдине з'єднання, не запущені.

Додаткові режими запуску

Після установки SQL Server програма установки заносить до реєстру набір базових параметрів запуску для SQL Server. Якщо ви не хочете використовувати параметри за замовчуванням, то для запуску SQL Server в нестандартної конфігурації можете скористатися ключами, перерахованими у табл.

Таблиця. Додаткові ключі sqlservr.exe

Ключ реєстру, створюваний програмою установки і містить параметри запуску SQL Server 2000 за умовчанням, знаходиться в реєстрі.

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

Ви можете створити свою власну конфігурацію, зберігши всі необхідні параметри запуску сервера в реєстрі. Створіть копію стандартних ключів (SQLArgO, SQLArgl або SQLArg2), змінивши ім'я, наприклад, на SingleUser. Потім відредагуйте рядок даних для вказівки потрібних параметрів.

Щоб запустити SQL Server з новим ключем реєстру, введіть наступну команду: Sqlservr.exe-sSingleUser

Тут SingleUser - ім'я конфігурації.

Призупинення SQL Server

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

Якщо ви виконуєте зупинку сервера без його попередньої припинення, то всі активні з'єднання негайно закриваються незалежно від того, зберегли користувачі свої дані чи ні. У такому випадку ви дуже скоро дізнаєтеся, що думають ваші колеги з приводу подібних дій і вашої компетентності.

При бажанні ви можете після припинення відновити роботу сервера в нормальному режимі.

Щоб призупинити роботу SQL Server, необхідно скористатися тими ж засобами, що і для запуску, але замість команди Start (пуск) вибирати команду Pause (пауза). Якщо необхідно зупинити сервер з командного рядка, то потрібно ввести наступну команду:

net pause mssqlserver

Для продовження роботи призупиненого SQL Server введіть команду

net continue mssql server

Відповідно для іменованих копій ці команди будуть виглядати наступним чином:

net pause mssqlSinstancename net continue mssql $ instancename

Ви не можете призупинити роботу сервера, якщо він запущений командою sqlservr.exe, так як в цьому випадку сервер працює як самостійний додаток, а не як служба операційної системи.

Зупинка SQL Server

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

Про SQL Server Enterprise Manager зупиняє локальний або віддалений сервер SQL Server або службу SQLServerAgent.

Про SQL Server Service Manager зупиняє локальний або віддалений сервер SQL Server або службу SQLServerAgent з одного вікна (у одному вікні можна керувати роботою всіх служб).

Про Команда SHUTDOWN мови Transact-SQL застосовується для зупинки SQL Server з клієнтського застосування при виконанні запитів, наприклад з утиліти osql або Query Analyzer. Використовуйте команду SHUTDOWN з параметром WITH NOWAIT для негайної зупинки сервера.

Про Команда net stop mssql server (net stop mssql Sinstancename - для іменованих копій) зупиняє локальний або віддалений SQL Server, якщо ви працюєте в Windows NT.

Про Утиліта Services (служби) вікна Control Panel (панель управління) зупиняє локальний сервер SQL Server.

Про Комбінація клавіш CTRL + C зупиняє сервер SQL Server, якщо він запущений з командного рядка командою sqlservr.exe.

При завершенні роботи всі дані з кеша зберігаються на диск, крім випадку, коли зупинка сервера проводиться за допомогою комбінації клавіш CTRL + C. У цьому випадку збереження даних не відбувається, в результаті час наступного запуску сервера збільшується, тому що необхідно виконати фіксацію закінчених і відкат незавершених транзакцій.

SQL Server 2000 очікує завершення всіх активних команд Transact-SQL і збережених процедур, і тільки після їх завершення відбувається зупинка сервера. Однак якщо ви зупиняєте сервер командою SHUTDOWN WITH NOWAIT, зупинка відбувається негайно незалежно від того, чи всі активні операції завершені.

Перед зупинкою SQL Server 2000 завжди здійснюйте припинення відповідних служб та розсилку попереджуючого повідомлення. Це дозволить користувачам коректно завершити свою роботу і в той же час запобіжить нові з'єднання.

Правила Безпеки

На будь-якому функціонуючому підприємстві є певна група людей, які забезпечують прийняття рішень і контроль їх виконання. Кожна людина повинна мати чітко окреслене коло обов'язків відповідно до своєї кваліфікації та займаної посади. Наприклад, виконання щоденного резервного копіювання у великій організації найкраще доручити не системного адміністратора, а спеціально підготовленому персоналу. Чітке розмежування сфер діяльності допомагає більш ефективно контролювати роботу персоналу, відслідковувати зроблені операції та здійснювати перспективне планування.

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

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

У сучасних умовах, коли інформація має величезне значення, вжиття заходів для запобігання несанкціонованого доступу, попередження втрати або пошкодження інформації стають невід'ємною частиною роботи будь-якої компанії. За даними статистики, в США 80% компаній, які втратили інформацію, припиняли свою діяльність протягом року. Серед решти 20% близько половини проіснувало не більше 4 років.

Останнім часом все більше підприємств відмовляються від паперових сховищ інформації і переходять до комп'ютерної обробки документів. Система зберігання інформації повинна бути максимально захищена як від випадкового, так і від не коректного пошкодження або спотворення інформації. При створенні бази даних розробник повинен спланувати її таким чином, щоб будь-який користувач не міг зробити що-небудь, не маючи на це відповідних прав. Не слід сподіватися на компетентність користувача і його порядність. Можливо виправлення або видалення даних не зі злого умислу, а просто через неуважність або помилки. Система, наскільки це можливо, повинна перешкоджати подібним діям.

Система управління базами даних Microsoft SQL Server 2000 має різноманітні засоби забезпечення захисту даних. Ця глава присвячена детальному знайомству з системою безпеки SQL Server 2000.

Загальні правила розмежування доступу

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

Після проектування логічної структури бази даних, зв'язків між таблицями, обмежень цілісності та інших структур необхідно визначити коло користувачів, які будуть мати доступ до бази даних. Щоб дозволити цим користувачам звертатися до сервера, створіть для них облікові записи в SQL Server або надайте їм доступ за допомогою облікових записів в домені, якщо ви використовуєте систему безпеки Windows NT. Дозвіл доступу до сервера не дає автоматично доступу до бази даних та її об'єктів.

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

Ретельно плануйте права, що видаються користувачам у відповідності до займаної посади і необхідністю виконання конкретних дій. Так зовсім необов'язково призначати права на зміну даних у таблиці, що містить відомості про зарплату співробітників, директору компанії. І, звичайно ж, не можна надавати подібні права рядовому співробітникові. Ви можете видати права тільки на введення нових даних, наприклад інформації про нових клієнтів. Неправильний введення такої інформації не завдасть серйозного збитку компанії, але якщо додати до прав введення ще й можливість виправлення або видалення вже існуючих даних, то зловмисник, який заволодів паролем, може завдати істотні фінансові втрати. Крім цього, слід врахувати збиток від роботи користувачів, не сильно замислюються про наслідки своїх дій.

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

Слід уважно ставитися до руху співробітників усередині компанії, їх переходах з одного відділу в іншій. Зміни займаної посади повинні негайно відбиватися на правах доступу. Своєчасно видаляйте користувачів, які більше не працюють в компанії. Якщо ви залишите людині, обіймав керівну посаду і пішов у конкуруючу фірму, доступ до даних, він може скористатися ними і завдати шкоди вашій компанії. Якщо людина йде у відпустку або їде у тривале відрядження, потрібно тимчасово заблокувати його профіль.

При створенні паролів виконуйте стандартні рекомендаціям. Бажано, щоб пароль включав в себе не тільки символи, а й цифри. Слідкуйте, щоб користувачі не застосовували в якості пароля рік народження, номер паспорта, машини або інші часто використовувані дані. Встановіть обмежений термін дії пароля, після закінчення якого система зажадає у користувача змінити пароль. Для досягнення максимального ступеня безпеки використовуйте аутентифікацію користувачів засобами Windows NT, оскільки операційні системи цього сімейства надають безліч дуже корисних засобів захисту.

Архітектура системи безпеки SQL Server 2000

Система безпеки SQL Server 2000 базується на користувачах та облікових записах. Користувачі проходять наступні два етапи перевірки системою безпеки. На першому етапі користувач ідентифікується по імені облікового запису та паролю, тобто проходить аутентифікацію. Якщо дані введені правильно, користувач підключається до SQL Server. Підключення до SQL Server, або реєстрація, не дає автоматичного доступу до баз даних. Для кожної бази даних сервера реєстраційне ім'я (або обліковий запис - login) має відображатися в ім'я користувача бази даних (user). На другому етапі, на основі прав, виданих користувачеві як користувачу бази даних (user), його реєстраційне ім'я (login) отримує доступ до відповідної бази даних. У різних базах даних login одного і того ж користувача може мати однакові або різні імена user з різними правами доступу.

Для доступу програм до баз даних їм також знадобляться права. Найчастіше додаткам видаються ті ж права, що надані користувачам, що запускають ці програми. Однак для роботи деяких додатків необхідно мати фіксований набір прав доступу, що не залежать від прав доступу користувача. SQL Server 2000 дозволяє надати такі із застосуванням спеціальних ролей додатки.

Отже, на рівні сервера система безпеки оперує такими поняттями:

Про аутентифікація (authentication);

Про обліковий запис (login);

Про вбудовані ролі сервера (fixed server roles).

На рівні бази даних використовуються такі поняття: Про користувач бази даних (database user); Про фіксована роль бази даних (fixed database role); Про користувальницька роль бази даних (users database role); Про роль додатка (application role).

Режими аутентифікації

SQL Server 2000 може використовувати два режими аутентифікації користувачів: Про режим аутентифікації засобами Windows NT/2000 (Windows NT Authentication);

Про змішаний режим аутентифікації (Windows NT Authentication and SQL

Server Authentication).

Змішаний режим дозволяє користувачам реєструватися як засобами Windows NT, так і засобами SQL Server. Крім того, цей режим пропонує деякі зручності в порівнянні з першим. Зокрема, при аутентифікації тільки засобами домену Windows NT, якщо користувач не має облікового запису в домені Windows NT, то він не зможе отримати доступу до сервера баз даних. Змішаний режим аутентифікації дозволяє уникнути цієї проблеми.

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

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

Зверніть увагу, що мова йде тільки про право підключення користувача до сервера баз даних. Після реєстрації користувача в SQL Server спосіб перевірки прав доступу до конкретної бази даних однаковий для обох режимів аутентифікації.

Режим аутентифікації SQL Server

Для встановлення з'єднання з сервером SQL Server 2000, що знаходиться в домені, з яким не встановлені довірчі відносини, можна використовувати аутентифікацію SQL Server. Аутентифікація SQL Server також використовується, коли взагалі немає можливості зареєструватися в домені. Наприклад, при підключенні до SQL Server 2000 по Інтернету.

При роботі з аутентифікацією SQL Server доступ також надається на основі облікових записів. Але в цьому випадку використовуються облікові записи SQL Server, а не Windows NT.

Для аутентифікації засобами SQL Server Server член стандартної ролі сервера sysadmin або securityadmin повинен створити і настроїти для користувача обліковий запис, в яку входить ім'я облікового запису, унікальний ідентифікатор SQL Server і пароль. Вся ця інформація буде зберігатися в системній базі master. Створювана обліковий запис не має відношення до облікових записів Windows NT.

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

Аутентифікація SQL Server може застосовуватися в таких випадках: О для користувачів Novell NetWare, Unix і т. д.;

Про при підключенні до SQL Server 2000 через Інтернет, коли реєстрація в домені не виконується;

Про під управлінням операційної системи Windows 98.

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

У більшості випадків обліковий запис в SQL Server створюється з метою надання доступу. Але бувають ситуації, коли необхідно заборонити доступ користувачеві або групі. Наприклад, при наявності складної системь! безпеки Windows NT доступ зазвичай надається групі користувачів. Однак якщо у групі є людина, якій не можна дозволяти доступ до SQL Server, його необхідно прибрати з цієї групи. Але такий підхід незадовільний, якщо група призначена не тільки для об'єднання користувачів, що мають доступ до SQL Server, але має ще й якісь додаткові функції. SQL Server дозволяє створити обліковий запис з метою заборони доступу. Це гарантує, що користувач ніяким чином не зможе встановити з'єднання з сервером. Створивши групу Windows NT і заборонивши їй доступ до SQL Server, ви можете включати до неї користувачів, яким необхідно відмовити в доступі.

Після установки SQL Server створюються дві стандартні облікові записи: BUILTINXAdministrators і sa.

Про BUILT INNAdministrators - це профіль Windows NT, що забезпечує автоматичний доступ усім членам групи Administrators до SQL Server. Обліковий запис BUILTINNAdministrators за замовчуванням є членом вбудованої ролі сервера sysadmin. Таким чином, системні адміністратори отримують повний доступ до всіх баз даних. У ситуації, коли функції системного адміністратора і адміністратора баз даних виконують різні люди, швидше за все, слід виключити цю обліковий запис з ролі sysadmin, а можливо, і взагалі видалити.

Про sa - це спеціальна обліковий запис SQL Server для адміністратора. За умовчанням вона присвоєна вбудованої системної ролі сервера sysadmin і не може бути змінена. Цей обліковий запис збережена в цій версії SQL Server для збереження сумісності з додатками, написаними для попередніх версій. Хоча s а й має адміністративні права, її не рекомендується використовувати в SQL Server 2000. Замість цього слід створити нових користувачів і включити їх в адміністративну групу sysadmin. Обліковий запис s а залиште на крайній випадок, коли облікові записи адміністраторів виявляться недоступними або ви забудете пароль.

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

Компоненти структури безпеки

Фундаментом системи безпеки SQL Server 2000 є облікові записи
(Login), користувачі (user), ролі (role) і групи (group). _T

Користувач, що підключається до SQL Server, повинен ідентифікувати себе, використовуючи обліковий запис. Після того як клієнт успішно пройшов аутентифікацію, він отримує доступ до SQL Server. Для отримання доступу до будь-якої бази да них обліковий запис користувача (login) відображається в користувача даної бази даних (user). Об'єкт «користувач бази даних» застосовується для надання доступу до всіх об'єктів бази даних: таблиць, уявленням, збереженим процедур і т. д. У користувача бази даних може відображатися:

Про обліковий запис Windows NT;

Про група Windows NT;

Про обліковий запис SQL Server.

Подібне відображення облікового запису необхідно для кожної бази даних, доступ до якої хоче отримати користувач. Відображення зберігаються в системній таблиці sysusers, яка є в будь-якій базі даних. Такий підхід забезпечує високу ступінь безпеки, оберігаючи від надання користувачам, що отримала доступ до SQL Server, автоматичного доступу до всіх баз даних та їх об'єктів. Користувачі баз даних, у свою чергу, можуть об'єднуватися в групи і ролі для спрощення управлінням системою безпеки.

У ситуації, коли обліковий запис не відображається у користувача бази даних, клієнт все-таки може отримати доступ до бази даних за допомогою гостьового ім'ям guest, якщо воно, зрозуміло, є в базі даних. Звичайно користувачеві guest надається мінімальний доступ тільки в режимі читання. Але в деяких ситуаціях і цей доступ необхідно запобігти.

Якщо в мережі є невелика кількість користувачів, то досить легко надати доступ кожному користувачеві персонально. Однак у великих мережах з сотнями користувачів подібний підхід займе багато часу. Набагато більш зручним і ефективним є підхід, коли доступ до SQL Server 2000 надається цілим групам користувачів. Саме такий підхід можливий при аутентифікації засобами Windows NT/2000, коли на рівні домену створюється кілька груп, кожна з яких призначена для вирішення специфічних завдань. На рівні SQL Server 2000 такій групі дозволяється доступ до сервера, надаються необхідні права доступу до баз даних та їх об'єктів. Досить включити обліковий запис Windows NT в одну з груп, і користувач отримає всі права доступу, надані цій групі. Більше того, одна і та ж обліковий запис може бути включена у безліч груп Windows NT, що дасть цього облікового запису можливість користуватися правами доступу, наданими всім цим групам. Адміністратор SQL Server 2000 повинен сам вирішити, як зручніше надавати доступ до сервера: персонально кожного облікового запису або групі в цілому.

Користувачі

Після того як користувач пройшов аутентифікацію та отримав ідентифікатор облікового запису (login ID), він вважається зареєстрованим і йому надається доступ до сервера. Для кожної бази даних, до об'єктів якої користувачеві необхідно отримати доступ, обліковий запис користувача (login) асоціюється з користувачем (user) конкретної бази даних. Користувачі виступають у якості спеціальних об'єктів SQL Server, за допомогою яких визначаються всі дозволи доступу і володіння об'єктами в базі даних.

Ім'я користувача може використовуватися для надання доступу як конкретній людині, так і цілій групі людей (залежно від типу облікового запису).

При створенні бази даних визначаються два стандартних користувача: db о і guest.

Якщо обліковий запис (login) не пов'язується явно з користувачем (user), останньому надається неявний доступ з використанням гостьового імені guest. Тобто всі облікові записи, які отримали доступ до SQL Server 2000, автоматично відображаються в користувачів guest у всіх базах даних. Якщо ви вилучили з бази даних користувача guest, то облікові записи, що не мають явного відображення облікового запису в ім'я користувача, не зможуть отримати доступу до бази даних. Тим не менш, guest не має автоматичного доступу до об'єктів. Власник об'єкта повинен сам вирішувати, дозволяти користувачеві guest цей доступ чи ні. Звичайно користувачеві guest надається мінімальний доступ в режимі "тільки читання".

Для забезпечення максимальної безпеки можна видалити користувача guest з будь-якої бази даних, крім системних баз даних master і Tempdb. У першій з них guest використовується для виконання системних збережених процедур звичайними користувачами, тоді як у другій дозволяє створювати будь-яким користувачам тимчасові об'єкти.

Власник бази даних (DataBase Owner, DBO) - спеціальний користувач, що володіє максимальними правами в базі даних. Будь-який член ролі sysadmin автоматично відображається в користувача dbo. Якщо користувач, який є членом ролі sys admin, створює який-небудь об'єкт, то власником цього об'єкта призначається не даний користувач, a dbo. Наприклад, якщо Liliya, член адміністративної групи, створює таблицю ТаИ ЕА, то повне ім'я таблиці буде не Lil iya. ТаИеА, a dbo.ТаИ ЕА. У той же час, якщо Liliya, не будучи учасником ролі сервера sysadmin, полягає в ролі власника бази даних db_owner, то ім'я таблиці буде Li I i уа. ТаИ ЕА.

Користувача dbo не можна видалити.

Для зв'язування облікового запису (login) з певним ім'ям користувача (user) можна скористатися наступною збереженої процедурою:

sp_adduser [@ loginame =] 'login' [, [@ name_in_db =] 'user'] [. [@ grpname =] 'role']

Нижче дається пояснення використаних у ній параметрів:

Про login-ім'я облікового запису, яку необхідно пов'язати з ім'ям користувача бази даних;

Про user - ім'я користувача бази даних, з яким асоціюється Цей обліковий запис (у базі даних заздалегідь не повинно існувати користувача з вказаним ім'ям);

Про role - цей параметр визначає роль, до якої даний користувач буде включений (докладніше про ролях буде розказано пізніше). Процедура, що зберігається sp_grantdbaccess дозволяє відобразити обліковий запис Windows NT в ім'я користувача:

sp_grantdbaccess [@ loginame =] 'login' [, [@ name_in_db =] 'user']

Параметри означають наступне:

Про login-ім'я облікового запису користувача або групи користувачів Windows NT, яким необхідно надати доступ до бази даних. Ім'я повинно забезпечуватися посиланням на домен, в якому обліковий запис визначена. Зазначеною облікового запису не обов'язково повинен бути наданий персональний доступ до SQL Server. Цілком можливо, що з'єднання з сервером встановлюється внаслідок членства в групі Windows NT, яка має доступ до сервера;

Про user - ім'я користувача бази даних, з яким асоціюється Цей обліковий запис.

Користувач, який створює об'єкт у базі даних, наприклад, таблицю, збережену процедуру або подання, стає власником об'єкта. Власник об'єкта (database object owner) має всі права доступу до створеного ним об'єкту. Щоб користувач міг створити об'єкт, власник бази даних (dbo) повинен надати користувачеві відповідні права. Повне ім'я створюваного об'єкта включає в себе ім'я створив його користувача. Якщо користувач хоче звернутися до таблиці, використовуючи тільки її ім'я і не вказуючи власника, SQL Server застосовує наступний алгоритм пошуку.

1. Шукається таблиця, створена користувачем, який виконує запит.

2. Якщо таблиця не знайдена, то шукається таблиця, створена власником бази даних (dbo).

Припустимо, користувач Liss намагається звернутися до таблиці Lil iya. TableA, просто використовуючи ім'я Tab! ЕА. Оскільки таблиця, створена Li I iya, не відповідає ні першому, ні другому критерієм пошуку, то таблиця ТаИеА знайдена не буде і користувач отримає повідомлення про помилку. Для отримання доступу до таблиці необхідно ввести ім'я, що включає власника об'єкта, тобто Liliya.TableA.

Власник об'єкта не має спеціального паролю або особливих прав доступу. Він неявно має повний доступ, але повинен явно надати доступ іншим користувачам.

SQL Server дозволяє передавати права володіння від одного користувача іншому. Щоб видалити власника об'єкта з бази даних, спочатку необхідно видалити всі об'єкти, які він створив, або передати права на їх володіння іншому користувачеві. Для цього можна використовувати збережену процедуру sp_changeobjectowner, що має наступний синтаксис:

sp_changeobjectowner [@ objname =] 'object', [(Pnewowner =] 'owner'

Тут з допомогою першого параметра вказується ім'я об'єкта, а за допомогою другого - ім'я користувача, який стане новим власником зазначеного об'єкта.

Ролі сервера

Роль - це потужний інструмент, доданий до SQL Server 7.0, щоб замінити групи, які використовувалися в попередніх версіях. Роль дозволяє об'єднувати користувачів, що виконують однакові функції, для спрощення адміністрування системи безпеки SQL Server.

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

У попередніх версіях SQL Server для адміністрування сервера можна було використовувати тільки обліковий запис sa або її аналог. Інакше кажучи, ви могли дати або всі права, або ніяких. Тепер в SQL Server ця проблема вирішена шляхом додавання ролей сервера (server role), які дозволяють надати операторам сервера тільки ті права, які адміністратор вважатиме за можливе надати. Ролі сервера не мають відношення до адміністрування баз даних. Можна включити будь-який обліковий запис SQL Server (login) або обліковий запис Windows NT в будь-яку роль сервера.

Стандартні ролі сервера (fixed server role) та їх права наведено в табл.

Таблиця. Фіксовані ролі сервера

Вбудована Призначення

роль сервера ______________________________________________

Sysadmin Може виконувати будь-які дії в SQL Server
Serveradmin Виконує конфігурування й вимкнення сервера

Setupadmin Управляє пов'язаними серверами і процедурами, автоматично
запускаються при старті SQL Server

Securityadmin Управляє обліковими записами і правами на створення бази даних, також може читати журнал помилок

Processadmin Управляє процесами, запущеними в SQL Server

Dbcreator Може створювати і модифікувати бази даних

Diskadmin Управляє файлами SQL Server

Bulkadmin Ця роль не існувала в SQL Server 7.0. Члени ролі Bulkadmin можуть

(Bulk Insert вставляти дані з використанням засобів масивного копіювання,

administrators) не маючи безпосереднього доступу до таблиць ____________________

Ролі баз даних

Ролі бази даних (database role) дозволяють об'єднувати користувачів в одну адміністративну одиницю і працювати з нею як із звичайним користувачем. Можна призначити права доступу до об'єктів бази даних для конкретної ролі, при цьому ви автоматично наділяєте всіх членів цієї ролі однаковими правами. Замість того щоб надавати доступ кожному конкретному користувачу, а згодом постійно стежити за змінами, можна просто включити користувача в потрібну роль. Якщо співробітник переходить в інший відділ, потрібно просто видалити його з однієї ролі і додати в іншу. Створіть необхідну кількість ролей, які охоплювали б усі різноманіття дій з базою даних. Пізніше, при зміні функцій членів однієї з ролей, достатньо змінити права доступа для цієї ролі, а не встановлювати нові права для кожного користувача.

У роль бази даних можна включати: Про користувачів SQL Server; Про роль SQL Server

Про користувачів Windows NT; '

Про групи Windows NT, яким попередньо наданий доступ до потрібної базі даних.

Засоби Enterprise Manager дозволяють додавати в роль бази даних тільки користувачів бази даних (user). Використовуйте збережену процедуру sp_addrolemember, щоб задіяти всі можливості SQL Server 2000:

sp_addrolemember [@ ro1ename =] 'role', [@ membername =] 'security_account'

Тут параметри означають наступне: Про role-назва ролі SQL Server в поточній базі даних;

Про security_account - ім'я того об'єкта системи безпеки, які необхідно включити в роль. В якості такого об'єкта можуть виступати як облікові записи SQL Server, так і користувачі і групи Windows NT, яким надано доступ до сервера баз даних.

При створенні бази даних для неї визначаються стандартні ролі бази даних, які, так само як і стандартні ролі сервера, не можуть бути змінені або видалені. Стандартні ролі баз даних (fixed database role) та їх права наведено в табл.

Таблиця. Фіксовані ролі баз даних

Вбудована роль Призначення

баз даних _______________________________________________

db__owner Має всі права в базі даних
db_accessadmin Може додавати або видаляти користувачів

db_securityadmin Управляє усіма дозволами, об'єктами, ролями і

членами ролей

db_ddladmin Може виконувати будь-які команди DDL, крім GRANT, DENY

і REVOKE

db_backupoperator Може виконувати команди DBCC, CHECKPOINT і BACKUP
db_datareader Може переглядати будь-які дані в будь-якій таблиці БД
db_datawriter Може модифікувати будь-які дані в будь-якій таблиці БД
db_denydatareader Забороняється переглядати дані в будь-якій таблиці
dbjjenydatawriter _________ Забороняється модифікувати дані в будь-якій таблиці _____

Крім зазначених вище ролей існує ще одна - public. Ця роль має спеціальне призначення, оскільки її членами є всі користувачі, що мають доступ до бази даних. Не можна явно встановити членів цієї ролі, тому що всі користувачі й так автоматично є її членами. Використовуйте цю роль для надання мінімального доступу користувачам, для яких права доступу до об'єктів не визначені явно. Якщо в базі даних дозволений користувач guest, то встановлений для publ i з доступ будуть мати всі користувачі, які отримали доступ до SQL Server. Роль public є у всіх базах даних, включаючи системні бази даних master, tempdb, msdb, model, І не може бути вилучена.

Групи Windows NT можуть бути використані аналогічно ролям SQL Server. Можна створити один обліковий запис (login) для групи Windows NT і включати відповідних користувачів замість ролі в групу Windows NT. Вибір методу адміністрування залежить від вас.

Ролі докладання

Система безпеки SQL Server реалізована на найнижчому рівні - рівні бази даних. Це найкращий, найбільш дієвий метод контролю діяльності користувачів незалежно від програм, що використовуються ними для підключення до SQL Server. Тим не менше зустрічаються ситуації, коли необхідний постійний набір прав для доступу до бази даних з програми. Особливо це стосується роботи з великими базами даних, що мають безліч складних взаємозалежних таблиць з тисячами або мільйонами записів. Частіше за все для роботи з такими базами даних створюються спеціальні програми.

Крім того, ви можете захотіти, щоб користувачі отримували доступ до бази даних лише з допомогою певної програми, не даючи можливості безпосередньо звертатися до даних. Наприклад, мобільні користувачі можуть використовувати спеціальну клієнтську програму, за допомогою якої вони оперують даними, встановлюючи зв'язок з сервером через незахищені глобальні комунікації.

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

Перед використанням ролі додатку необхідно спочатку створити його. При створенні ролі вкажіть її ім'я та пароль для доступу. Створення ролі засобами Transact-SQL виконується за допомогою наступної системної збереженої процедури:

sp_addappro1e [@ rolename =] 'role'. [(^ Password =] 'password'

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

Створення ролі докладання засобами Enterprise Manager виконується за допомогою вікна Database Role Properties - New Role (властивості ролей баз даних - нова роль), яке також використовується для створення звичайних користувальницьких ролей. Щоб створювана роль була роллю додатка, досить встановити перемикач Application role (роль додатка) і ввести пароль. Робота із зазначеним вікном буде розглянута в одному з наступних розділів цієї глави.

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

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

sp_setapprole [(ЕгоТепате =] 'role', [^ password =] (Encrypt N 'password'} | 'password' [. [^ encrypt =] 'encrypt_style']

Розглянемо параметри детальніше: Про role-ім'я ролі додатка, що визначено в базі даних;

Про password-пароль, який додаток повинен передати сервера для активізації ролі додатка;

Про encrypt_styl e - застосовувана схема шифрування паролів. Даний параметр може мати два значення: попі (шифрування не застосовується) і odbc (шифрування з застосуванням функції ODBC encrypt).

Коли роль додатка активізується, всі права доступу, встановлені в межах сеансу для користувача, груп чи ролей, губляться до закінчення роботи програми. З'єднання отримує права, встановлені для ролі докладання в базі даних, в якій ця роль існує. Тимчасовий «забування» прав доступу, привласнених встановив з'єднання користувачеві, потрібно для усунення конфліктів доступу. В іншому випадку, якщо користувачеві заборонено читання даних, а додатку необхідно вважати дані, доступ був би відхилений, так як заборона доступу має переваги над наданням доступу.

Оскільки роль додатку має права лише в тій базі даних, в якій вона створена, а всі дозволи для облікових записів, груп і ролей, до яких належить користувач, губляться, то доступ до інших баз даних можлива лише за допомогою гостьового ім'ям guest. Отже, якщо ім'я guest в базі даних не існує, то з'єднання не зможе отримати доступ до даних. Якщо ж ім'я guest не видалено з бази даних, з'єднання зможе отримати доступ до об'єктів бази тільки в тому випадку, якщо дозволу явно видані для користувача guest. Перед встановленням з'єднання з використанням ролі докладання користувачеві спочатку потрібно отримати доступ до SQL Server. Для цього припустимі обидва режими аутентифікації користувачів.

Якщо додаток спроектовано для виконання різних завдань з використанням різних прав доступу, необхідно створити окрему роль для кожної виконуваної задачі. Додаток має сама потурбуватися про переключення ролей.

Захист даних

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

Шифрування даних

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

• будь-які дані, передані між сервером і клієнтом по мережі;

• паролі облікових записів SQL Server або ролей програми;

• код, використаний для створення об'єктів бази даних (збережених процедур,

уявлень, тригерів і т. д.).

Паролі облікових записів і ролей програми завжди зберігаються в системних таблицях SQL Server в зашифрованій формі. Це охороняє їх від перегляду будь-яким користувачем, включаючи адміністратора. Крім того, пароль ролі додатка може бути зашифрований перед відправкою його на сервер.

Якщо код тригера, подання або збереженої процедури містить дані або алгоритм, які необхідно зберегти в таємниці, використовуйте шифрування цих об'єктів.

Шифрування даних при передачі їх по мережі гарантує, що ніяке додаток або пристрій не зможе їх прочитати, навіть якщо і перехопить. Шифроване з'єднання дозволяє також запобігти перехоплення паролів користувачів.

Якщо ви хочете шифрувати дані при передачі їх по мережі, необхідно використовувати мережеву бібліотеку Multiprotocol Net-Library.

Обмеження доступу до файлів SQL Server

У своїй роботі SQL Server створює і використовує безліч файлів - бази даних, журнали помилок, резервні копії, файли для експорту та імпорту даних та багато іншого. Служби SQL Server на рівні операційної системи виконуються у вигляді процесів. Для нормальної роботи SQL Server необхідно, щоб ці процеси мали повний доступ до всіх вказаних вище файлів на рівні файлової системи. Для цього на рівні операційної системи потрібно надати відповідні права облікових записів, які використовуються для запуску SQL Server. Найкраще керувати правами доступу безпосередньо на

рівні файлів і папок. Для цього сервер повинен працювати під управлінням операційної системи Windows NT і мати файлову систему NTFS.

Якщо сервер стартує як служба, необхідно надати повні права доступу облікових записів, що використовуються для запуску служб. Якщо ж старт SQL Server виконується з командного рядка або на комп'ютері під управлінням Windows 98, то сервер буде мати права доступу облікового запису користувача, що виконав запуск. Якщо для запуску сервера використовується обліковий запис локальної системи, то доступ повинен надаватися користувачеві SYSTEM.

З метою обмеження можливостей неавторизованого доступу для файлів SQL Server необхідно встановити заборону на читання, видалення, зміну та виконання всім користувачам, крім безпосередньо SQL Server.

Права доступу

Коли користувачі підключаються до SQL Server, дії, які вони можуть виконувати, визначаються правами (дозволів), виданими їх облікового запису, групі або ролі, в якій вони перебувають.

Права в SQL Server можна розділити на три категорії: Про права на доступ до об'єктів баз даних; Про права на виконання команд Transact-SQL; Про неявні права (дозволу).

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

Права користувачеві видаються адміністратором або власниками баз даних або конкретних об'єктів баз даних. Для надання користувачу певного набору прав можна використовувати ролі. Створивши кілька ролей і надавши їм необхідні права доступу, адміністратор бази даних може просто включати користувачів у відповідні ролі. Користувач автоматично отримує всі права доступу, визначені для ролі. Стандартні ролі бази даних вже мають певний набір прав. Наприклад, члени ролі db_datareader можуть переглядати будь-які дані в будь-якій таблиці.

Важливо бути обережним з наданням дозволів на доступ до даних. Необхідно уважно контролювати права доступу, що видаються користувачеві як безпосередньо, так і через членство в групах Windows NT і ролях SQL Server. Особливо це стосується великих систем безпеки з тисячами користувачів і десятками груп. Ви повинні бути впевнені, що існуюча система безпеки дає можливість користувачу виконувати будь-які необхідні дії, але обмежує доступ до інформації, яка не потрібна йому для виконання своїх обов'язків.

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

Аналогічні рекомендації стосуються дозволів на виконання команд Transact-SQL. Можна спроектувати базу даних таким чином, що виконувати конкретні дії - створення таблиць, уявлень, правил, резервних копій і т. д. - будуть строго певні користувачі.

Права на доступ до об'єктів баз даних

Робота з даними і виконання процедур, що зберігаються вимагають наявності класу доступу, званого правами на доступ до об'єктів баз даних. Під об'єктами маються на увазі таблиці, стовпці таблиць, подання, збережені процедури. Права на доступ до об'єктів баз даних контролюють можливість виконання користувачами, наприклад, команд SELECT, INSERT, UPDATE і DELETE для таблиць і уявлень. Таким чином, якщо користувачеві необхідно додати нові дані в таблицю, йому слід надати право INSERT (вставка записів в таблицю). Надання ж користувачеві права EXECUTE дозволяє йому виконання будь-яких збережених процедур.

Для різних об'єктів застосовуються різні набори прав доступу до них: Про SELECT, INSERT, UPDATE, DELETE, REFERENCES-ці права можуть бути застосовані для таблиці або подання;

Про SELECT та UPDATE - ці права можуть бути застосовані до конкретного стовпцю таблиці або подання;

Про EXECUTE-це право застосовується тільки до збережених процедур і функ ціям. Нижче наводиться більш докладний опис кожного з цих прав.

Про INSERT. Це право дозволяє вставляти в таблицю або подання нові рядки. Як наслідок, право INSERT може бути видано лише на рівні таблиці або подання і не може бути видано на рівні стовпця.

Про UPDATE. Це право видається або на рівні таблиці, що дозволяє змінювати всі дані в таблиці, або на рівні окремого стовпця, що дозволяє змінювати дані тільки в межах конкретного стовпця.

Про DELETE. Це право дозволяє видаляти рядки з таблиці або подання. Як і право INSERT, право DELETE може бути видано лише на рівні таблиці або подання і не може бути видано на рівні стовпця.

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

Про REFERENCES. Можливість посилатися на зазначений об'єкт. Стосовно до таблиць дозволяє користувачеві створювати зовнішні ключі, що посилаються на первинний ключ або унікальний стовпець цієї таблиці. Стосовно до уявлень право REFERENCES дозволяє пов'язувати уявлення зі схемами таблиць, на основі яких будується уявлення. Це дозволяє відстежувати зміни структури вихідних таблиць, які можуть вплинути на роботу подання. Право REFERENCES не існувало в попередніх версіях SQL Server.

Як випливає з вищевикладеного, доступ можна надавати як на рівні всієї таблиці або подання, так і на рівні окремого стовпця. Зазвичай не практикується управління правами доступу на рівні конкретного стовпця. Якщо в таблиці є один або декілька стовпців, доступ користувачів до яких необхідно обмежити, то в базі даних часто створюється уявлення (view), що включає тільки ті стовпці вихідної таблиці, доступ до яких дозволено.

Надати або відхилити доступ користувачеві бази даних до всіх об'єктів бази даних можна за допомогою вбудованих ролей бази даних. Наприклад, для дозволу читання даних з усіх таблиць і уявлень бази даних досить включити користувача в фіксовану роль db_datareader, а не змінювати права доступу користувача до кожної таблиці та поданням окремо.

Використовуйте команду GRANT для управління дозволами користувача на доступ до об'єктів бази даних:

GRANT

(ALL [PRIVILEGES] | permiss1on [.... n]}

{

[(Column [,... n])] ON {table | view}

| ON {table | view} [(column [,... n])]

| ON {stored_procedure | extended_procedure}

}

TO security_account [,... n] [WITH GRANT OPTION] [AS {group | role}]

Призначення параметрів команди GRANT наступне:

Про ALL - користувачеві надаються всі доступні дозволи. Цей параметр можуть використовувати тільки учасники ролі sysadmln;

Про permission - список доступних дозволів, що надаються користувачеві (SELECT, INSERT, UPDATE, DELETE, EXECUTE). Ви можете одночасно надавати декілька дозволів, в цьому випадку їх потрібно розділяти комами;

Про security_account - ім'я того об'єкта системи безпеки, які необхідно включити в роль. В якості таких об'єктів можуть виступати як облікові записи SQL Server, так і користувачі і групи користувачів Windows NT, яким надано доступ до сервера баз даних;

Про table, view, column, stored_procedure, extended_procedure - в якості даних параметрів виступають імена об'єктів у поточній базі даних, для яких необхідно надати доступ;

Про WITH GRANT OPTION-використання даного параметра дозволяє користувачеві, якому ви надаєте права, призначати права на доступ до об'єкта іншим користувачам;

Про AS {group | role) - цей необов'язковий параметр дозволяє вказати участь користувача в ролі, яка має можливість надавати права іншим користувачам.

Як приклад команди розглянемо наступну ситуацію. Вам необхідно надати права на використання команд INSERT і SELECT групі Engineer в таблиці Materials. При цьому потрібно, щоб у подальшому користувачі цієї групи могли самі надавати аналогічні права. Для цього слід виконати наступну команду:

GRANT SELECT. INSERT

ON Materials

TO Engineer

WITH GRANT OPTION

Згодом користувач Valentin, що є членом групи Engineer, може надати аналогічні права іншому користувачеві L iss:

GRANT SELECT, INSERT ON Materials 'TO Liss AS Engineer

У даному випадку необхідно підтвердити, на якій підставі Valentine надає права, тому застосовується параметр AS.

Будьте обережні при використанні параметра WITH GRANT OPTION, оскільки при цьому ви втрачаєте контроль над наданням прав на доступ іншим користувачам. Найкраще обмежити коло людей, що володіють можливістю керувати призначенням прав.

Єдине право доступу, яке може бути надано для збереженої процедури, - це право на її виконання (EXECUTE). Природно, крім цього власник збереженої процедури може переглядати і змінювати її код.

Для функції можна видати право на її виконання, а, крім того, можна видати право REFERENCES, що забезпечить можливість скріплення функції з об'єктами, на які посилається функція. Таке зв'язування дозволяє заборонити внесення змін до структури об'єктів, які могли б призвести до порушення роботи функції.

Щоб надати право на виконання збереженої процедури, можна використовувати Enterprise Manager. Для цього виберіть в лівій панелі Enterprise Manager потрібну базу даних і відкрийте в ній папку Stored Procedures. У правій частині Enterprise Manager буде відображений список збережених процедур, вже створених в базі даних. Управління правами доступу можна здійснювати у вікні Object Properties (властивості об'єктів), показаному на рис. 12.20. Викликати це вікно можна або за допомогою кнопки Permissions (права) у вікні властивостей збереженої процедури, або вибравши в контекстному меню збереженої процедури пункт АН Tasks> Manage Permissions (усі завдання> управління правами).

Щоб дозволити користувачеві виконувати збережену процедуру, потрібно встановити напроти його імені галочку в полі ЕХЕС. Щоб заборонити доступ, потрібно поставити хрестик. Відсутність будь-якого значка на увазі неявне відхилення доступу. Більш докладно про права доступу буде розказано далі в цій главі.

Управління правами доступу до функцій здійснюється аналогічно.

Інший спосіб управління правами доступу полягає в наданні прав конкретному користувачу за допомогою вікна прав доступу користувача. Для цього у вікні Enterprise Manager виберіть необхідну базу даних, а потім папку Users. Клацніть лівою кнопкою миші на обраному користувача. У вікні клацніть на кнопці Permissions (права) та потрібні права.

Заборона доступу

Система безпеки SQL Server має ієрархічну структуру. Це дозволяє ролям бази даних включати в себе облікові записи та групи Windows NT, користувачів і ролі SQL Server. Користувач же, у свою чергу, може брати участь в кількох ролях. Наслідком ієрархічної структури системи безпеки є те, що користувач може одночасно мати різні права доступу для різних ролей. Якщо одна з ролей, в яких складається користувач, має дозвіл на доступ до даних, то користувач автоматично має аналогічні права. Тим не менш може знадобитися заборонити можливість доступу до даних. Коли ви забороняєте користувачеві доступ до даних або командам Transact-SQL (deny access), тим самим анулюються всі дозволи на доступ, отримані користувачем на будь-якому рівні ієрархії. При цьому гарантується, що доступ залишиться забороненим незалежно від дозволів, наданих на більш високому рівні.

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

Використовуйте команду DENY для заборони користувачеві доступу до об'єктів бази даних:

DENY

(ALL [PRIVILEGES] | permission [,... n]}

{

[(ColumnC. ... n])] ON {table | view} | ON {table | vi ew} [- (columnC,... N])] I ON {stored_procedure | extended_procedure}

TO security_account [.... n] [CASCADE]

Для заборони виконання команд Transact-SQL застосовується інша команда:

DENY {ALL | statement ^ ... . N]} ТО security_account [.... n]

Параметри даної команди аналогічні параметрам команди GRANT. Параметр CASCADE дозволяє відкликати права не тільки у даного користувача, але також і у всіх тих користувачів, кому він надав дані права. Пояснимо зміст вищесказаного на прикладі. Нехай ви надали користувачеві Sheridan певні права:

GRANT CREATE TABLE

ТО Sheridan

WITH GRANT OPTION

Припустимо, Sheridan надає аналогічні права деяким користувачам. Якщо згодом вам буде потрібно відкликати дозволу у Sheridan, ви виконаєте команду:

DENY CREATE TABLE ТО Sheridan CASCADE

При цьому будуть відкликані і всі дозволи, які Sheridan надав іншим користувачам.