Описати більш-менш докладно всі можливості нової
версії Microsoft SQL Server завдання не тривіальна, тому в даній статті
запропонований лише невеликий огляд деяких нововведень. А саме подання
метаданих, схем, трохи про безпеку, нові можливості при роботі з
індексами та нові вбудовані типи даних. Я не ставив перед собою цілі
розкопати все в подробицях, оскільки на даний момент доступна лише перший
попередня версія сервера і багато чого може змінитися, але основна
функціональність, очевидно, залишиться, тому її і має сенс розглянути.
Метадані та безпека
Одне з досить серйозних змін в сервер
стосується метаданих. Раніше ця інформація зберігалася в декількох системних
табличках, і була досить невигадливо структурована, а тепер усе стало
дещо складніше, але в той же час суворіше і логічніше. Взагалі зараз про цю
частини сервера складно говорити щось напевно, тому що, судячи з усього, частина
заявленої функціональності ще не реалізована, а частина очікують досить
серйозні зміни. Голови у Books On-Line, що відносяться до безпеки, на
даний момент просто відсутні, але вже можна розгледіти напрям
подальшого розвитку і навіть дещо помацати руками.
У попередніх версіях сервера для обслуговування і тонкої
настройки, як правило, використовувалися спеціальні системні збережені
процедури. Тепер же вся ця функціональність вносяться до T-SQL, за допомогою
створення нових DDL операторів або невеликої зміни старих. Від системних ж
процедур в майбутніх версіях, судячи з усього, відмовляться. Опції діагностики,
збору статистики та перегляду іншої адміністративної інформації, також
переходять від системних процедур і DBCC команд до спеціальних системних функцій.
Безпека
Як вже говорилося, на даний момент щось конкретне
в цій частині сервера розкопати важкувато, оскільки документація практично
відсутня. Але, тим не менше, вже зрозуміло, що очікуються серйозні зміни.
Row level security
Свого часу Microsoft була заявлена підтримка
безпеки на рівні окремих рядків у таблиці, але як це буде виглядати,
поки що незрозуміло. У BOL з цього приводу - лише натяки, і немає жодного рядка прикладу
або хоча б приблизного опису, а всі спроби зробити щось навмання до
успіху не привели.
Робота з логінами і користувачами
Збережені процедури для створення користувача і логіна
оголошені застарілими й призначені виключно для забезпечення сумісності, на
зміну їм прийшли нові DDL оператори - CREATE USER, CREATE LOGIN, ALTER USER і
ALTER LOGIN, які надають більше можливостей.
У Yukon можна застосувати політику логінів операційної
системи до логінів SQL-сервера. При цьому для контролю узгодженості політик
безпеки ОС і SQL-сервера використовується спеціальне API, що з'явилося в
Windows 2003 Server. При створенні або зміні логіна може бути виставлено
два прапори, CHECK_EXPIRATION і CHECK_POLICY, які й визначають втручання
ОС в політику логінів сервера.
Значення прапора CHECK_EXPIRATION (за замовчуванням ON)
визначає, чи буде відбуватися перевірка старіння пароля. Встановлення цього
прапора в "OFF" означає, що перевірка не проводиться, і пароль не старіє.
Значення прапора CHECK_POLICY (за замовчуванням ON)
визначає, чи буде проводитися перевірка стійкості пароля з використанням
локальної політики ОС. Установка цього прапора в "OFF" означає, що локальна
політика ОС не використовується, і діє внутрішня політика СУБД.
Є також параметр HASHED, що означає, що пароль,
вказаний при створенні або зміні логіна, вже зашифрований, і параметр
MUST_CHANGE, що означає, що при першому зверненні користувача з цим логіном
буде затребуваний новий пароль.
Якщо прапор CHECK_POLICY встановлений в «OFF», то й
CHECK_EXPIRATION так само повинен бути встановлений в «OFF». Якщо вказано параметр
MUST_CHANGE, то прапор CHECK_EXPIRATION повинен бути встановлений в «ON», а,
отже, і CHECK_POLICY також повинен бути «ON».
Природно, всі ці настройки можна застосовувати лише до
локальним користувачам SQL-сервера.
Наприклад, якщо спробувати створити логін Vasya з
простим і нехитрим паролем:
CREATE
LOGIN Vasya WITH PASSWORD = 'password'
то нічого не вийде, оскільки за замовчуванням прапор
CHECK_POLICY встановлений в «ON», ОС перевіряє пароль на стійкість і можна
спостерігати помилку 15118, приблизно такого змісту:
Password
validation failed. The password does not meet policy requirements because it
is not complex enough.
Однак якщо перевірку політики безпеки ОС
відключити, то створення логіна Vasya з простим і нехитрим паролем пройде
цілком успішно:
CREATE
LOGIN Vasya WITH PASSWORD = 'password', CHECK_POLICY = OFF
Схеми
За стандартом ANSI SQL під поняттям схема (schema) розуміється
набір об'єктів БД, що належить одному власнику (principal) і утворює одне
простір імен (namespace). Іншими словами схема - це набір об'єктів БД,
які не можуть мати однакові імена.
У попередніх версіях SQL-сервера схема була безпосередньо
пов'язана з власником об'єкта. Фактично між цими двома поняттями для
користувача не було різниці. Кожен користувач був власником схеми, і ім'я
цієї схеми збігалося з користувачем. Спеціальна команда створення схеми
- CREATE SCHEMA, строго кажучи, схему не створювала, а дозволяла створити об'єкт
і роздати на нього права одним оператором, полегшуючи тим самим життя
адміністраторам.
Подібне спрощення приводить до деяких проблем.
Повне ім'я об'єкта в MS SQL Server формально складається з чотирьох частин: <ім'я
сервера>. <ім'я бази>. <ім'я схеми>. <ім'я об'єкта>, але
оскільки в попередніх версіях відмінностей між ім'ям користувача і ім'ям
схеми не робилося, то фактично ім'я користувача використовувалося замість імені
схеми. Припустимо, є якийсь набір об'єктів, що належить користувачеві Vasya,
повне ім'я кожного об'єкта буде приблизно таким:
avalon.employee.vasya.account
Таким чином, якщо в якийсь трагічний момент
користувача Vasya звільнять, то для його видалення з бази треба або видалити всі
об'єкти, що належать йому, або передати їх у володіння іншому користувачеві.
Якщо передати ці об'єкти у володіння комусь іншому, наприклад користувачу
Masha, то зміниться і повне ім'я об'єкта:
avalon.employee.masha.account
Це вимагає внесення змін до клієнтське
програми та подальшого тестування - приємного в цьому мало.
У новій версії Microsoft SQL Server ці два поняття
(схема та її власник) відокремлені один від одного, і поміняти власника схеми можна
без зміни повного імені об'єкта. Очевидно, що приклад з Васею і Машею
кілька надуманий, але, тим не менше, подібний розподіл дозволить більш
вільно і логічно групувати об'єкти в БД по просторах імен, серйозно
підвищуючи зручність розробки.
Більше того, з цією ж метою введено нове поняття синоніма.
Синонім створюється за допомогою нового оператора CREATE SYNONYM і є
альтернативним ім'я об'єкта БД. Об'єкт, на який посилається синонім,
називається «базовим об'єктом» (base object), і з цим базовим об'єктом синонім
пов'язаний тільки по імені. Таким чином, клієнтський додаток, що використовує
синоніми, захищене від зміни імен об'єктів. Крім того, синонім, що складається
з одного слова, зручніше використовувати, ніж повне ім'я об'єкта, що складається з
двох, трьох або чотирьох частин. Наприклад, створення синонім для Employee в базі
AdventureWorks для використання з Northwind виглядає приблизно так:
USE
Northwind
GO
CREATE
SYNONYM MyEmployee FOR AdventureWorks.dbo.Employee
Сам синонім належить схемою, таким чином, не можна
створити два однакових синоніма в одній схемі.
Синоніми можуть бути створені для наступних об'єктів:
збережених процедур, скалярних і табличних функцій, CLR-процедур і функцій (також
скалярних і табличних), розширених збережених процедур, процедур реплікації,
таблиць, включаючи тимчасові, локальні і глобальні, а так само уявлень.
Введено також поняття «схеми за умовчанням» (default
schema). Ця схема вказується при створенні користувача або логіна, і якщо
користувач шукає об'єкт без зазначення певної схеми, то в першу чергу
об'єкт шукається у схемі за замовчуванням. Якщо ж при створенні користувача схема по
умовчанням не була вказана, то використовується схема DBO. При створенні користувача
можна також вказати неіснуючу схему і створити її пізніше.
Метадані
Спосіб доступу до метаданих змінився кардинально.
Тепер до них можна добратися через спеціальні подання каталозі (Catalog
Views), які, по суті, є реляційних інтерфейсом метаданих. Ці
уявлення дозволяють переглядати метадані, які містяться в кожній
базі сервера, і практично цілком замінили собою системні таблиці та
системні уявлення, які використовувалися для роботи з метаданими в
попередніх версіях.
Кожна БД має спеціальну схему sys, де і
розташовані нові системні уявлення. Самі метадані безпосередньо недоступні
нікому. Усі системні таблиці, що використовувалися раніше, тепер є
уявленнями і залишені тільки для зворотної сумісності. Використовувати їх
не рекомендується, як з міркувань продуктивності, так і в силу того,
що підтримка цих уявлень в майбутньому не гарантується. Природно, і
інформацію про нову функціональності ці уявлення не відображають.
Наприклад, всі об'єкти раніше були доступні через
системну таблицю sysobjects, а тепер ця інформація переїхала до подання
sys.objects. Sysobject тепер - теж уявлення, яке робить вибірку з
sys.objects. Але оскільки частина інформації у форматі sysobjects відобразити
неможливо, то навіть вибірка всіх даних з sys.object і sysobjects поверне різне
кількість записів.
Системні процедури також переписані з використанням
нових системних уявлень.
Взагалі з доступністю метаданих все стало набагато
суворіше. Тепер навіть переглянути можна тільки ті метадані, на які є
відповідні права.
Наприклад, якщо створити простеньку процедуру в
тестовій базі:
CREATE
PROCEDURE tst_sel AS
SELECT
* FROM employee
GO
а потім підключитися до цієї бази під раніше створеним
логіном Vasya і спробувати знайти цю процедуру в метаданих, то спроба успіхом
не увінчається. Ось такий запит:
SELECT
* FROM sys.procedures WHERE name = 'tst_sel'
який в принципі повинен був повернути запис з
інформацією про щойно створеної процедури, яка не поверне жодного запису. Якщо
ж знову повернутися до попереднього підключення і дати користувачеві Vasya права на
виконання процедури tst_sel:
GRANT
EXECUTE ON tst_sel TO vasya
а потім повторити запит під все тим же логіном Vasya,
то інформація про процедуру буде доступна. Однак якщо тепер користувач Vasya
захоче переглянути текст процедури tst_sel, у нього нічого не вийде. Ось
такий запит, який, в принципі, дозволяє побачити тексти процедур і функцій,
виконаний з підключення Vasya:
SELECT
definition FROM sys.sql_modules WHERE name = 'tst_sel'
не поверне жодного запису. У той же час, якщо його
виконати з підключення, в якому процедура створювалася, то її код цілком
можна переглянути.
Подібні нововведення у безпеку метаданих,
безумовно, дуже корисні, але цілком можуть призвести до проблем при переносі
застарілих прикладних програм, в яких передбачається, що для перегляду доступні
практично всі метадані, незалежно від прав.
Щоб уникнути цих проблем, а також для більшої
гнучкості при налаштуванні прав перегляду метаданих, в Yukon додано нове право
- VIEW DEFINITION. Це право перекриває правила, що описані вище. Якщо
надати користувачеві Vasya право VIEW DEFINITION на об'єкт, то йому будуть
доступні для перегляду всі метадані цього об'єкту, не зважаючи на інші
права, якщо ж це право явно заборонити, то ніякі метадані подивитися вже
буде не можна, знов-таки не дивлячись на інші права.
Права VIEW DEFINITION можуть бути застосовані до об'єктів,
розташованим на різних рівнях ієрархії сервера.
