Міністерство Освіти Російської Федерації
Назва Вашого інституту (повне)
Назва Вашої кафедри (повне)
Курсова робота
за спеціальністю ""
на тему:
"Відновлення бази даних"
Москва, 2010
Зміст
Введення
1. Причини пошкоджень баз даних
2. Відновлення баз даних на прикладі SQL Server 2005
2.1 Основні можливості відновлення баз даних SQL Server 2005
2.2 Підготовка до відновлення
2.3 Проведення відновлення
2.4 Спеціальні ситуації відновлення
Висновок
Список літератури
Введення
Встановлено, що більшість підприємств, які пережили велику незворотну втрату корпоративних даних, припиняють своє існування протягом трьох років після такого інциденту. Думка про можливу катастрофу неприємна для ІТ-та бізнес-менеджерів, тому вони часто не приймають серйозних запобіжних заходів. На жаль, це груба правда життя. І тут під "попереджувальними заходами" у жодному разі не можна розуміти "купівлю техніки brand-name", так як "бренди" теж ламаються, іноді навіть частіше ніж "самозбірні машини". Тому "попереджувальні заходи" - це не тільки якісне "залізо", а й планування резервного копіювання даних.
Актуальність мого дослідження визначила мету і завдання роботи:
Мета дослідження - розглянути методи відновлення баз даних
Для досягнення мети необхідно вирішити такі завдання:
На основі аналізу зарубіжної та вітчизняної літератури, монографічних джерел вивчити методи відновлення баз даних
Виявити причини за яких базу даних потрібно відновлювати
Провести аналіз основних можливостей відновлення
Розглянути на прикладі SQL Server 2005 відновлення бази даних
На основі проведеного дослідження зробити висновки і дати рекомендації по роботі
Для розкриття поставленої мети і завдань визначена наступна структура дослідження: робота складається зі вступу, двох розділів, висновків та списку використаної літератури. Назви розділів відображають їх зміст.
1. Причини пошкоджень баз даних
Існує кілька причин, за яких база даних може виявитися пошкодженої. Перелічимо найбільш характерні.
Відключення живлення сервера.
Найчастіший випадок пошкодження бази даних це відключення живлення на сервері. Такі ситуації треба намагатися запобігати, використовуючи апаратні засоби (UPS, RAID-контролери з батарейками).
Існує два режими запису сторінок - синхронний і асинхронний. Синхронний запис означає, що змінені сторінки бази даних не будуть кешуватися операційною системою, а будуть записуватися безпосередньо на диск при виштовхуванні сторінок з кеша на запис (на Windows це в буквальному сенсі відсутність прапора lazy write при відкритті файлу БД). Це погіршує продуктивність, тому більшість людей вимикають forced writes. У цьому випадку змінені сторінки знаходяться в кеші операційної системи до тих пір, поки операційна система не вирішить записати їх на диск.
У деяких випадках при безперервній роботі з БД операційна система не скидає змінені сторінки на диск до тих пір, поки всі користувачі не від'єднався від бази даних. При вимиканні живлення в цьому випадку пошкодження бази даних можуть бути максимальними. Причому, пошкодження в даному випадку відбуваються від "недозапісі" інформації. Це куди менш сумний випадок, ніж "перезапис" інформації випадковими даними. Однак, на Windows було виявлено, що якщо у бази даних встановлено Forced Write = Off, то за певних умов змінені сторінки БД могли тижнями не потрапляти в БД, і залишатися в кеші операційної системи. При цьому, у разі збою сервера (або відключення живлення), пропадало величезна кількість змін у БД (а база могла виглядати взагалі неушкодженою). Тобто, БД як би виявлялася "незмінної" протягом тривалого часу.
Дефекти обладнання
Пам'ять. Найчастіший дефект - збої пам'яті (RAM). Очевидно, при використанні серверів "своєї збірки" купується пам'ять подешевше, що призводить до відповідних результатів. Бажано для сервера набувати і материнську плату і пам'ять з підтримкою ECC. Збої пам'яті можуть призвести до досить важких наслідків. Сервер не тільки "пропускає" сторінки бази даних через пам'ять, але і кешує їх у пам'яті. Контрольні суми сторінок, навіть якщо б вони і були, не допоможуть коли сервер буде записувати сторінку на диск через зіпсований ділянку пам'яті. В іншому випадку дані довелося б перечитувати, що дуже серйозно погіршило б продуктивність. Збої пам'яті ще погані тим, що в цьому випадку пошкодженими як правило виявляються і база даних та її копія, якщо копія використовується в якості "швидкої резервної копії" (тому що запис на диск йде з одних і тих же ділянок пам'яті).
Диски. Раніше, років 10-15 тому, bad-блоки з'являлися часто, і існували спеціальні утиліти для їх виправлення. Зараз контроль помилок не тільки може виправити дані на пошкодженій блоці самостійно, а й прозоро збереже блок в робочому місці диска, а поганий блок позначить до виключення з подальшого використання. Грубо кажучи, нинішні диски або працюють, або не працюють цілком.
Контролери. Тут можна відзначити тільки те, що при збої в роботі контролера некоректна інформація може бути записана на всі носії, які підключені до цього контролера. Саме тому при організації створення копії рекомендується розташовувати її на вінчестері, підключеному до іншого контролеру.
Інші програми. Додатки в основному не працюють з операційною системою на "внутрішньому" рівні. Такі програми ніколи не зможуть викликати збій типу відомого "синього екрану" в Windows. Тому якщо подібний збій ОС стався, у цьому швидше винні некоректно працюючі драйвери або саме обладнання (дуже часто в "синьому екрані" винні драйвера відео).
Збої самого сервера
Зрозуміло, серверні програми, як і будь-яке інше програмне забезпечення, не є ідеальною програмою. Ідеальною, звичайно, в сенсі відсутності помилок. Якщо "залізо" працює нормально, сервер може сам "зламатися" і або просто перестати працювати, або зіпсувати базу даних.
Раніше код сервера містив виклик звичайної функції позиціонування по файлу БД (seek), яка не могла адресувати більше 4-гігабайт (в ті далекі часи просто не було файлових систем, які підтримували файли більше 4-х гігабайт). Коли у функцію передавалося таке велике число, воно обрізати по старшим розрядами. Відбувалася така ситуація при операції розширення файлу БД, тобто при записі нових сторінок, а отже файл БД опинявся "затертим" нової інформації з самого початку, тобто з нульовою сторінки (сторінка заголовка БД). Якщо нових сторінок до запису було багато, то знищувалася початкова частина БД, де як правило містяться системні таблиці, сторінки інформації про транзакції і т.п. Причому боротьба з горезвісним розміром файлу в 4 гігабайти найдовше велася на Linux, що пов'язано не тільки з кодом СУБД, але й з підтримкою файлів таких розмірів самою операційною системою і її файловими системами. На Windows, Firebird і Yaffil цієї проблеми вже немає, тобто файл БД може мати розмір і 10, і 20 і більше гігабайт.
У будь-якому випадку, при роботі на Unix або Windows слід уважно вивчити можливості ядра і конкретної (використовуваної) файлової системи - чи здатні вони працювати з файлами більше 4-х гігабайт, а також перевірити версію IB / FB / YA, щоб бути впевненим в коректній роботі з такими файлами, або навпаки, відразу передбачити розбиття БД на многофайловую, наприклад "шматками" по 2-3 гігабайти.
У відношенні файлових систем Windows відома наступна особливість: на FAT32 підтримуються файли розміром не більше 4 гігабайт (найчастіше зазначене пошкодження БД і відбувається при використанні цієї, фактично вже застарілою, файлової системи). Припустимо, розмір вашої БД досяг 3-х гігабайт, і ви хочете перенести її на NTFS, щоб уникнути обмеження в 4 Гб. Проблема в тому, що з FAT32 на NTFS скопіюється тільки 2 гігабайти з 3-х, через особливості Windows. Це ще раз підкреслює необхідність знання обмежень використовуваних файлових систем і їх взаємодії на одному комп'ютері.
Зупинка під час збірки сміття
Якщо під час примусового завершення роботи сервера були активні підключення і сервер займався складанням сміття, то база даних може бути пошкоджена (і найчастіше це так і відбувається). Зменшити ймовірність таких пошкоджень можна тільки відключивши автоматичну збірку сміття, а в разі примусового збирання сміття попередньо робити "швидкий" backup, щоб резервна копія бази даних виявилася самої свіжої у разі збою і пошкодження БД.
Пошкодження індексів
Пошкодження індексів можуть відбуватися як по всіх перерахованих вище причин, так і з-за ряду багів сервера при роботі з індексами. Оскільки індекси не є 100% необхідним видом об'єктів для функціонування бази даних, їх пошкодження виявляються значно пізніше, ніж пошкодження інших об'єктів БД (наприклад, даних таблиць). І клієнтські додатки можуть продовжувати функціонувати в такій ситуації як і раніше.
Однак, при пошкодженні індексів можливо спотворення даних, одержуваних додатками. Якщо в індексі пошкоджено декілька ключів, і сервер не видав повідомлення про помилку при виконанні запиту, що використовує такий індекс, в результат запиту не потраплять запису, на які посилаються ті самі пошкоджені ключі. Тобто, частина записів може "зникнути". Виявити різницю у видаваному кількості записів можна тільки використовуючи запити з повним перебором записів
SELECT * FROM TABLE
і з перебором за індексом
SELECT * FROM TABLE
WHERE FIELD> 0
де FIELD - стовпець, по якому є можливо пошкоджений індекс, а> 0 - умова, що однозначно буде вибирати всі записи.
Можна цього і не робити, а при підозрі на "пропажа записів" відразу подивитися в log-файл, і перебудувати ті індекси, про пошкодження яких там повідомляється.
У log-файл пишуться тільки порядкові номери індексів (а не їх імена) для конкретних таблиць. Процес backup пошкоджені або неушкоджені індекси (за винятком ушкоджень індексів по системних таблиць) не цікавлять, тому що індекси в backup зберігаються лише у вигляді опису в системних таблицях (restore створює індекси за цим описам ж в кінці restore). Backup зчитує записи в натуральному порядку і індекси не використовує, тому всі існуючі (committed) запису обов'язково потраплять до backup. Однак, якщо пошкоджений унікальний індекс, то в певних умовах існує ймовірність повторної вставки запису в таблицю з уже існуючим (унікальним) значенням стовпця. Ця ситуація може призвести до невідновлювального backup, тобто процес restore зупиниться в момент створення унікального індексу, виявивши дублікат унікального значення у відновлених записах. Але така проблема також не є катастрофічною - процес створення індексів виконується самим останнім, тобто після того як абсолютно всі об'єкти БД вже відновлені в базі даних процесом restore. Якщо раптом виявлена проблема неунікальний даних при створенні індексу, можна спробувати знайти такий запис (і потім видалити зайву) запитом
SELECT ID, COUNT (*) FROM TABLE
GROUP BY ID
HAVING (COUNT (*))> 1
де id - стовпець, по якому є не створюваний унікальний індекс. Після цього можна активувати індекси, які не були відновлені.
Пошкодження таблиць
Нормальна база даних - це не набір окремих таблиць. Таблиці між собою можуть бути досить сильно взаємопов'язані, аж до циклічних посилань. Тому навіть один і той же тип і обсяг пошкодження може мати різні наслідки, залежно від того, з якою таблицею це сталося. Типовий приклад: таблиця CLIENTS - довідкова, а ORDERS - оперативна. Якщо пропаде частина записів з ORDERS, то після лагодження БД буде нормально функціонувати. Якщо ж буде пошкоджена CLIENTS, то після лагодження в ORDERS будуть записи, що посилаються на неіснуючих клієнтів. Таким чином БД начебто буде відремонтована, але логічну цілісність даних буде порушена. Боротися з цією ситуацією ніяк неможливо, хіба що частіше роблячи backup (оскільки довідники змінюються рідше, ніж оперативні дані). Подібна ситуація (з ушкодженням master-таблиці) може виникнути навіть у тому випадку, якщо всі записи пакету master-detail вставляються в одній транзакції, а Forced Write виключений (off) - сторінки із записами detail можуть бути записані на диск операційною системою з кешу раніше , ніж відповідні їм записи таблиці master. Це не призводить до "невідновлювального backup", але після restore доведеться або додавати відсутні master-запису, або видаляти "осиротілі" detail-запису (залежно від складності тригерів, що обробляють вставку master або видалення в detail. Можливо, такі тригери на час ремонту даних потрібно буде відключити).
Також, в подібній ситуації, при restore відремонтованої бази даних можуть виявитися неактивними індекси за Foreign Key відповідних зв'язків master-detail. Активувати їх можна після згаданих вставок або вилучень master / detail, шляхом установки rdb $ indices.rdb $ index_inactive в 0.
7. Стихійні і техногенні лиха
Шторм, землетрус, злодії, пожежа, прорив водопроводу - все це призводить до втрати всіх носіїв даних, розташованих на певній території. Дана причина втрати даних буває дуже рідко, але вона має місце.
Єдиний спосіб захисту від стихійних лих - тримати частину резервних копій в іншому приміщенні.
8. Шкідливі програми
У цю категорію входить випадково занесене ПЗ, яке навмисно псує інформацію - (віруси, черв'яки, «троянські коні»). Іноді факт зараження виявляється, коли чимала частина інформації перекручена або знищена.
Рішенням цієї проблеми буде:
встановлення антивірусних програм на робочі станції. Найпростіші антивірусні заходи - відключення автозавантаження, ізоляція локальної мережі від Інтернету, і т. д.;
забезпечення централізованого оновлення: перша копія антивіруса отримує оновлення прямо з Інтернету, а інші копії налаштовані на папку, куди перші завантажує оновлення; також можна налаштувати проксі-сервер таким чином, щоб оновлення кешувати (це всі заходи для зменшення трафіку);
мати копії в такому місці, до якого вірус не добереться - виділений сервер або знімні носії;
Якщо копіювання йде на сервер: забезпечити захист сервера від вірусів (або встановити антивірус, або використовувати ОС, для якої ймовірність зараження мала). Зберігати версії достатньої давності, щоб існувала копія, не контактувала із зараженим комп'ютером.
Якщо копіювання йде на знімні носії: частина носіїв зберігати (без дописування на них) досить довго, щоб існувала копія, не контактувала із зараженим комп'ютером.
9. Людський фактор
Навмисне або ненавмисне знищення важливої інформації - людиною, спеціально написаної шкідливою програмою або збійних ПЗ.
Ретельно розставляються права на всі ресурси, щоб інші користувачі не могли модифіковані чужі файли. Виняток робиться для системного адміністратора, який повинен мати всі права на все, щоб бути здатним виправити помилки користувачів, програм і т.д.
Забезпечити працюючу систему резервного копіювання - тобто, систему, якої люди реально користуються і котра досить стійка до помилок оператора. Якщо користувач не користується системою резервного копіювання, вся відповідальність за збереження лягає на нього.
Зберігати версії достатньої давності, щоб при виявленні зіпсованих даних файл можна було відновити.
Перед перевстановлення ОС слід обов'язково копіювати весь вміст розділу, на якій буде встановлена ОС, на сервер, на інший розділ або на CD / DVD.
Оперативно обновляти ПЗ, яку запідозрено у втраті даних.
2. Відновлення баз даних на прикладі SQL Server 2005
2.1 Основні можливості відновлення баз даних SQL Server 2005
Перш ніж розглядати процедуру відновлення баз даних SQL Server, уточнимо значення декількох термінів використовуваних в SQL Server.
R estore. З точки зору SQL Server, цей термін можна перекласти як "відновлення з носія". Найчастіше відновленням з носія доводиться займатися в ситуаціях, коли база даних пошкоджена фізично або потрібно виправити велику помилку користувача. Нерідко нею користуються для створення тестової бази для перевірки критичних оновлень або навчання. Під час цього процесу здійснюється перенесення даних з резервної копії на сервер бази даних.
R ecovery. Його можна перекласти як "відновлення працездатності". Під час процедури recovery усуваються всі проблеми, які можуть бути з базою даних (наприклад, виникли через незавершених транзакцій), і база даних відкривається для доступу користувачів. Процедура recovery повинна бути проведена після відновлення з носія - restore, однак вона запускається і в інших ситуаціях. Наприклад, якщо робота сервера був завершена некоректно (наприклад, пропало живлення), то ця процедура поверне всі бази даних в працездатний стан.
F ailure (збій) зазвичай означає збій в роботі бази даних, наприклад, з'явилися помилки на диску, на якому була розташована база даних. Операційна система і програмні файли сервера при цьому залишилися в робочому стані, і вам потрібно зробити відновлення тільки бази даних.
D isaster (катастрофа) означає катастрофічний відмову сервера, наприклад, через стрибок напруги, пожежі, затоплення і т. п. При відновленні в разі такого катастрофічного відмови вам доведеться спочатку встановити операційну систему та програмне забезпечення SQL Server, а потім вже проводити відновлення робочих баз даних.
Загальний план відновлення звичайно виглядає наступним чином:
1. Спочатку проводиться процедура restore - необхідна інформація відновлюється з носія. Ви можете відновити тільки повну резервну копію, а вже після цього провести відновлення різницевої резервної копії і резервних копій журналів транзакцій. Офіційна назва цього етапу - фаза копіювання даних (data copy phase).
2. Якщо проводиться також відновлення журналів транзакцій, то наступним дією SQL Server записує в базу даних всю інформацію про завершені транзакціях з журналу транзакцій. Ця операція називається roll forward (завершення). Сам етап називається фазою повтору (redo phase), а обидва перші етапи разом - етап завершення (roll forward step).
3. Тільки в редакції SQL Server 2005 Enterprise Edition користувачам відкривається доступ до бази даних. Відкриття доступу на цьому етапі - це нова можливість SQL Server 2005. Вона має свою назву - fast recovery (швидке відновлення). Якщо ж користувач спробує звернутися до даних, зміненим незавершеними транзакціями, то доступ йому буде закритий за рахунок механізму блокувань.
4. Потім SQL Server виявляє в журналі всі незавершені транзакції і скасовує їх. Ця операція називається rollback - відкат транзакцій, а сам етап називається етапом відкату (rollback phase).
5. Після цього до бази даних відкривається доступ в звичайному режимі у всіх версіях SQL Server.
Відзначимо ще кілька моментів, пов'язаних з процесом відновлення SQL Server 2005:
для відновлення ви можете використовувати не тільки резервні копії, які були створені у версії SQL Server 2005, але й ті, які були створені на версіях 7.0 і 2000. Оновлення до версії 2005 відбудеться автоматично. Звичайно, таку можливість слід розглядати як ще один варіант оновлення баз даних;
творці SQL Server 2005 активно рекламують нову можливість - відновлення на відкритій базі даних. Насправді таке відновлення можна робити тільки тоді, коли в базі даних декілька файлових груп, і відновлювана файлова група знаходиться в автономному режимі (offline). Тому насправді користувачі працювати з відновлюваними даними, звичайно, не зможуть;
в SQL Server 2005 відновлення повнотекстових індексів проводиться разом з базами даних;
інформація про відновлення, як і інформація про резервне копіювання, записується в службові таблиці бази даних msdb. Використовуються таблиці restorehistory, restorefile і restorefilegroup.
2.2 Підготовка до відновлення
Перед відновленням потрібно буде провести деякі підготовчі дії.
Перше, що потрібно зробити, - це заборонити користувачам доступ до бази даних, що підлягає відновленню. Це можна зробити різними способами:
для більшості баз даних досить встановити для параметра Restrict Access (Обмежити доступ) властивостей бази даних значення Restricted. Якщо ж користувачі вашої бази даних можуть підключатися з правами dbo, то для цього параметра можна встановити значення Single;
якщо на сервері є тільки одна робоча база даних, то краще просто на час відновлення відключити мережевий доступ до SQL Server. Для цього можна, наприклад, на час відновлення відключити протокол TCP / IP в контейнері SQL Server 2005 Network Configuration в SQL Server Configuration Manager.
Якщо до бази даних в даний момент підключені користувачі, то їх з'єднання доведеться закрити.
Може статися так, що база даних пошкоджена настільки сильно, що змінити її властивості не вдається. Вона при цьому може знаходитися в стані suspect (підозріле) або в автономному режимі offline (інформацію про стан можна переглянути, наприклад, з контейнера Dat а bases в Management Studio). Якщо база даних знаходиться в автономному режимі, то запустити її відновлення вам не вдасться. У цій ситуації найпростіший вихід - від'єднати (detach) пошкоджену базу даних і провести відновлення з резервної копії так, як ніби ця база даних відсутній на сервері взагалі. Відзначимо, що для того, щоб від'єднати базу даних, позначену як підозріла (suspect), її необхідно спочатку перевести у стан "екстреної необхідності" (emergency) - ALTER DATABASE db 1 SET emergency.
Якщо база даних знаходиться в робочому режимі, а час у вас є, то краще, звичайно, підстрахуватися, створивши ще одну, саму свіжу резервну копію цієї бази даних і журналу транзакцій (або тільки журналу транзакцій в залежності від ситуації).
Після того, як доступ користувачів до бази даних закритий, рекомендується перевірити заголовки ваших резервних копій. Для цього можна використовувати наступні команди:
RESTORE FILELISTONLY - повертає інформацію про список файлів і журналів транзакцій, які поміщені в дану резервну копію. Ця інформація береться з таблиці backupfile бази даних msdb;
RESTORE HEADERONLY - повертає інформацію про ім'я резервної копії, її типі, описі, часу створення і часу старіння і т. п.. Ця інформація береться з таблиці backupset бази даних msdb;
RESTORE LABELONLY - виводить службову інформацію про мітку носія. В основному мітка потрібна для картриджів стриммерів, але може застосовуватися і для файлів. Інформація береться, в тому числі, і з таблиці backupmediaset бази даних msdb.
Приклад виконання команди на перегляд інформації про резервної копії може виглядати так:
RESTORE FILELISTONLY FROM backupdevice 1;
Звичайно, ви можете звернутися до таблиць з історією резервного копіювання в базі даних msdb і безпосередньо.
2.3 Проведення відновлення
Після того, як підготовка завершена, можна приступати до самого відновленню. Запустити відновлення можна за допомогою графічного інтерфейсу Management Studio (контекстне меню Restore Database для контейнера Databases або контекстне меню Tasks | Restore для контейнера бази даних) або за допомогою команди RESTORE. Як завжди, опишемо можливості, які представляє графічний інтерфейс, і наведемо інформацію про тих параметрах команди RESTORE, яким вони відповідають.
Destination to restore ... To database (Призначення відновлення ... в базу даних) - це, звичайно, ім'я відновлюваної бази даних. Зверніть увагу, що замість вибору бази даних зі списку ви можете ввести своє ім'я. У цьому випадку з резервної копії на сервері буде створена нова база даних. У деяких випадках може бути зручно відновити копію існуючої бази даних під іншим ім'ям, а потім при необхідності стару базу даних видалити, а відновлену перейменувати, присвоївши їй стару назву.
Команда на відновлення бази даних у найпростішому варіанті може виглядати так:
RESTORE DATABASE db2 FROM DISK = 'D: \ SQLBackups \ BackupFile1.bak'
При цьому резервна копія цілком могла бути створена для бази даних db 1, а не db 2;
To a point of time (На момент часу) - дозволяє задати відновлення на певний момент часу. Зазвичай використовується тільки в ситуації, коли користувач зробив помилку (наприклад, вилучив важливі дані) і ви знаєте приблизно, коли це сталося. Використовується тільки при відновленні журналів транзакцій. Цей перемикач відповідає параметру STOPAT команди RESTORE, наприклад, WITH STOPAT = "01 / 06/2006 12:14:24 '. Для команди RESTORE можна вказати ще два параметри:
1. відновлення на мітку транзакції. Зазвичай мітка транзакції застосовується перед виконанням ризикованих операцій (застосування виправлень від розробників, очищення або масове завантаження даних і т. п.). Створити мітку транзакції можна дуже просто:
BEGIN TRAN mark 1 WITH MARK;
COMMIT TRAN;
Для відновлення буде потрібно використовувати параметр WITH STOPATMARK = 'mark 1', щоб зупинитися точно на цій мітці або WITH STOPBEFOREMARK = 'mark 1' для зупинки точно перед цією міткою;
2. відновлення на номер послідовності в журналі транзакцій (log sequence number, LSN). Номер LSN є в кожної операції, яка зафіксована в журналі транзакцій. На жаль, стандартними засобами переглянути журнал транзакцій і знайти LSN для транзакції, з якої почалися проблеми, неможливо. Для цієї мети доведеться використовувати утиліти третіх фірм, наприклад, Lumigent Log Explorer. Після того, як номер LSN знайдений, можна використовувати ті ж параметри STOPATMARK і STOPBEFOREMARK, але синтаксис буде трохи іншим, наприклад:
RESTORE LOG db1 FROM DISK = 'D: \ SQLBackups \ BackupFile1.bak' WITH STOPATMARK = 'lsn: 120';
From database (З бази даних) - для виявлення резервних копій буде використовуватися історія резервного копіювання з таблиць бази даних msdb. У списку можна вибрати не тільки поточну базу даних, а й інші бази даних, які є на цьому сервері;
From device (З пристрої) - вам буде потрібно вказати місцезнаходження резервної копії явно. Ця можливість використовується в тих ситуаціях, коли вам потрібно відновити базу даних на інший сервер або місцезнаходження резервної копії змінилося. У будь-якому випадку вам потрібно вибрати логічний пристрій резервного копіювання, картридж стриммерів або файл на диску. Ще одна можливість (доступна тільки в Enterprise Edition і тільки при повному відновленні бази даних) - використовувати в якості джерела знімок бази даних (database snapshot);
Select the backup sets to restore (Вибрати резервну копію для відновлення) - у цьому списку вам буде потрібно встановити прапорці навпроти тих резервних копій, які ви плануєте відновити. Зверніть увагу, що прапорці можна поставити напроти декількох резервних копій. У цьому випадку для кожної обраної резервної копії буде виконана окрема команда RESTORE.
За допомогою цього ж списку можна отримати безліч додаткової інформації про відновлюваних резервних копіях (якщо прокрутити список вправо): про час резервного копіювання, про розмір резервної копії, про користувача, які виробляв це копіювання, і т.п.
Додаткові і дуже важливі параметри відновлення представлені на вкладці Options вікна відновлення бази даних Management Studio:
Overwrite the existing database (Перезаписувати існуючу базу даних) - встановлений прапорець дозволяє перезаписати існуючу базу даних. Фактично він скасовує перевірки, які покликані не допустити втрати даних у разі помилкового відновлення. Таких перевірок передбачено три:
заборонено відновлювати резервну копію чужий бази даних на сервер, якщо під цим ім'ям на сервері є своя база даних;
заборонено перезаписувати файли, які відносяться до баз даних, що знаходяться в автономному режимі (offline), і, крім цього, взагалі будь-які файли, які не відносяться до SQL Server;
заборонено проводити відновлення бази даних, якщо на ній залишилася частина журналу транзакцій, резервне копіювання якої ще не проводилося (tail - log). Це нова перевірка, яка з'явилася тільки в SQL Server 2005.
Щоб ці перевірки скасувати, потрібно встановити зазначений прапорець або використовувати параметр WITH REPLACE в команді RESTORE;
Preserve the replication settings (Зберегти налаштування реплікації) - зберегти налаштування реплікації при відновленні. Відповідає параметру KEEP _ REPLICATION команди RESTORE. Зазвичай використовується тільки тоді, коли база даних одночасно бере участь і в реплікації, і в автоматичній доставці журналів (log shipping).
Prompt before restoring each backup (Виводити запрошення перед кожним відновленням) - виводити запрошення перед відновленням кожної наступної резервної копії з обраного вами списку. Зазвичай цей параметр використовується тільки тоді, коли кожна копія лежить на своєму картриджі стриммерів, і вам потрібно їх змінювати. Цей параметр можна встановити лише на графічному екрані Management Studio, оскільки в коді Transact - SQL для відновлення кожної резервної копії вам доведеться використовувати свою власну команду RESTORE;
Restrict access to the restored database (Обмежити доступ до відновлюваної базі даних) - після відновлення доступ буде відкритий тільки членам ролі бази даних db _ owner та членам серверних ролей dbcreator і sysadmin. Цей параметр звичайно застосовується в тих випадках, коли після відновлення бази даних вам необхідно провести додаткові перевірки або внести виправлення. Йому відповідає параметр команди RESTORE WITH RESTRICTED _ USER;
Restore the database files as (Відновити файли бази даних як) - дуже важливий параметр, який дозволяє визначити новий шлях для відновлюваних файлів баз даних. Без нього не обійтися, наприклад, у тих ситуаціях, коли ви відновлює базу даних на інший сервер, на якому конфігурація дисків виглядає по-іншому. Цьому прапорця в команді RESTORE відповідає параметр MOVE, наприклад:
RESTORE DATABASE db 1 FROM DISK = 'D: \ SQLbackups \ BackupFile 1. Bak' WITH MOVE 'db 1' TO 'D: \ db 1. Mdf', MOVE 'db 1_ log' TO 'D: \ db 1_ log. mdf ';
Тут db 1 і db 1_ log - це логічні назви файлів бази даних і журналу транзакцій відповідно, а 'D: \ db 1. Mdf' і 'D: \ db 1_ log. Mdf' - це нові місця для файлів, які будуть відновлені з резервної копії;
Recovery state (Стан відновлення) - ще один найважливіший параметр, який визначає, чи буде база даних відкрита для користувачів після закінчення відновлення з носія. У вашому розпорядженні три варіанти:
WITH RECOVERY - відновлення в звичайному режимі. Після закінчення відновлення почнеться процедура RECOVERY, всі незавершені транзакції будуть скасовані, і в підсумку база даних буде відкрита для користувачів. Цей параметр використовується за умовчанням;
WITH NORECOVERY - після закінчення процесу відновлення з носія процедура RECOVERY не почнеться. Бази даних залишиться в неробочому стані відновлення. Цей параметр використовується тоді, коли після відновлення резервної копії ви хочете відновити додаткові копії, наприклад, після відновлення повної резервної копії відновити резервну копію журналу транзакцій;
WITH STANDBY - процедура RECOVERY почнеться, але вся інформація про всіх скасованих незавершених транзакціях буде записана в файл скасування (його потрібно буде вказати). У результаті користувачі зможуть звертатися до відновленої базі даних для читання (наприклад, для створення звітів), але в той же час зберігається можливість застосування наступних резервних копій журналів транзакцій. Таке рішення використовується зазвичай лише при застосуванні автоматичної доставки журналів на резервний сервер (log shipping).
Як і у випадку з командою BACKUP, деякі можливості команди RESTORE доступні тільки з коду Transact - SQL. Про деякі з них (наприклад, про можливість відновлення до мітки транзакції або LSN) вже розказано. Далі представлено ще декілька параметрів, які не можна вибрати за допомогою графічного інтерфейсу:
PAGE - цей параметр дозволяє вказати певні сторінки в базі даних, які потрібно відновити. Ця нова можливість SQL Server 2005, у попередніх версіях її не було.
CHECKSUM | NOCHECKSUM - дозволяє включити або відключити перевірку контрольних сум при відновленні. За замовчуванням така перевірка проводиться, а у разі виявлення розбіжностей відновлення припиняється, і видається повідомлення про помилку;
CONTINUE _ AFTER _ ERROR | STOP _ ON _ ERROR - чи буде зупинено відновлення в разі виявлення помилок в контрольній сумі. За замовчуванням встановлено параметр STOP _ ON _ ERROR;
MEDIANAME - дозволяє вказати ім'я носія, з якого проводиться відновлення. Використовується тільки для додаткових перевірок;
MEDIAPASSWORD і PASSWORD - за допомогою цих параметрів вам буде потрібно вказати паролі для носія і резервної копії відповідно, які були використані при резервному копіюванні. Ці параметри також слід віднести до категорії додаткових перевірок. Якщо ви проводите відновлення резервної копії на інший сервер (по відношенню до того, на якому була створена резервна копія), то пароль вказувати не потрібно;
PARTIAL - визначає, що в ході поточної сесії відновлення буде проводитися відновлення тільки одного файлового групи (якщо резервне копіювання вироблялося по файлових групами). Процедура відновлення бази даних по частинах (тобто по файлових групами) називається piecemeal restore;
RESTART - Дозволяє продовжити операцію відновлення з того моменту, коли вона була перервана (наприклад, необхідно вставити наступний картридж у стриммер);
REWIND | NOREWIND - виробляти чи після закінчення відновлення перемотування стрічки у картриджі чи ні. За замовчуванням використовується значення REWIND, тобто виробляти;
STATS - так само, як і для команди BACKUP, цей параметр визначає частоту появи інформаційних повідомлень. За замовчуванням інформація про хід відновлення виводиться після відновлення приблизно кожних 10% резервної копії;
UNLOAD | NOUNLOAD - вивантажувати картридж з стриммерів після закінчення відновлення чи ні. За замовчуванням використовується значення UNLOAD, тобто вивантажувати. UNLOAD включає в себе також і перемотування стрічки на початок, тому разом з параметром REWIND використовуватися не може.
2.4 Спеціальні ситуації відновлення
У всіх попередніх версіях SQL Server можна було виконувати відновлення бази даних, тільки відключивши від неї всіх користувачів. У SQL Server 2005 з'явилась нова можливість - відновлення на працюючій базі даних. Інша назва такого типу відновлення - оперативне відновлення (online restore).
Звичайно, на практиці обійтися зовсім без обмеження доступу користувачів не вдасться. При відновленні на працюючій базі даних вам в будь-якому випадку доведеться перевести в автономний режим (offline) той файл або файлову групу, відновлення якого ви робите в даний момент. Решта файли або файлові групи можуть залишатися в робочому режимі.
Для відновлення на відкритій базі даних передбачені й інші обмеження:
резервне копіювання на працюючій базі даних може використовуватися тільки для баз даних, які працюють в режимі відновлення Full або Bulk - logged;
оперативне відновлення першого файлу бази даних або первинної файлової групи (у яких знаходяться системні таблиці та карта розміщення даних) проводити не можна.
Якщо це можливо, SQL Server автоматично застосовує режим оперативного відновлення при відновленні окремих файлів, файлових груп і сторінковому відновленні (але не при звичайному відновлення всієї бази даних). Якщо ви хочете заборонити застосування оперативного відновлення та проводити відновлення файлів, файлових груп та окремих сторінок в звичайному автономному режимі, то можна перед відновленням виконати команду BACKUP LOG WITH NORECOVERY. Ця команда, яка зазвичай застосовується тільки при використанні автоматичної доставки журналів (log shipping), дозволяє створити резервну копію журналу транзакцій і перевести базу даних у спеціальне стан RESTORING. У цьому стані доступ до бази даних користувачів буде закритий, а відновлення буде проводитися тільки в автономному режимі.
Синтаксис команд для виконання оперативного відновлення нічим не відрізняється від звичайного. Наприклад, щоб в оперативному режимі відновити файл db 1 file 2, вже переведений в автономний режим, можна використовувати наступні команди:
RESTORE DATABASE db1 FILE = 'db1file2' FROM DISK = 'D: \ SQLBackups \ BackupFile1.bak' WITH NORECOVERY;
RESTORE LOG db1 FROM DISK = 'D: \ SQLBackups \ BackupLogFile1.bak';
Ще одна нова можливість SQL Server 2005, пов'язана з відновленням, - відновлення окремих сторінок даних (page restore). Тепер у деяких ситуаціях можна замість відновлення всієї бази даних або якихось файлів, обмежитися відновленням лише окремих сторінок. Це дозволить:
заощадити час;
провести відновлення в оперативному режимі, без відключення користувачів від бази даних. Недоступними для користувачів будуть тільки відновлювані сторінки.
Найчастіше помилки на сторінках баз даних виникають через збої дисків або дискових контролерів. Тому перед таким відновленням краще переконатися, що з дисковою підсистемою сервери у вас все в порядку.
Відновлення окремих сторінок бази даних можна робити тільки при дотриманні наступних умов:
ви використовуєте редакцію Enterprise Edition;
відновлювані сторінки не відносяться до журналу транзакцій, до службових сторінок бази даних та до повнотекстових каталогів;
база даних працює в режимі Full або Bulk - logged;
файлові групи, до яких відносяться відновлювані сторінки, доступні і на читання, і на запис.
Порядок дій відновлення окремих сторінок бази даних зазвичай такий:
1. Спочатку ви виявляєте, що деякі сторінки в базі даних пошкоджені. Таку інформацію можна отримати при перегляді журналів подій SQL Server, за допомогою команд DBCC (наприклад, DBCC CHECKDB) і просто за допомогою аналізу повідомлень, які повертаються клієнтського додатку. Сам SQL Server виявляє пошкоджені сторінки за допомогою аналізу контрольних сум чи контрольних біт.
2. Перед відновленням вам потрібно отримати інформацію про номери пошкоджених сторінок і номери файлів, в яких ці сторінки знаходяться. Ця інформація зберігається в таблиці suspect _ pages бази даних msdb (вона заноситься в цю таблицю автоматично). Номери сторінок знаходяться у стовпці page _ id, а номери файлів - у стовпці file _ id. Треба відзначити, що в таблиці suspect _ pages не може бути більше 1000 записів. Після досягнення цієї межі запис у таблицю просто припиняється. Тому рекомендується у разі фізичного пошкодження баз даних після відновлення очистити цю таблицю.
3. Потім запускаєте команду на відновлення бази даних, наприклад:
RESTORE DATABASE db1 PAGE = '1: 51, 1:52, 1:55 'FROM DISK =' D: \ SQLBackups \ BackupFile1.bak ';
За замовчуванням відновлення запускається в оперативному режимі, без відключення користувачів від бази даних. Більше 1000 пошкоджених сторінок відновлювати не можна.
У деяких ситуаціях може знадобитися зробити відновлення системної бази даних master, в якій зберігається службова інформація всього сервера (наприклад, інформація про логіни, призначених для користувача базах даних, налаштування сервера і т. п.).
Перед тим, як проводити відновлення бази даних master, подумайте про альтернативні можливості. Якщо постраждала не тільки ця база даних, але й користувальницькі бази даних, то можливо легше і надійніше буде просто перевстановити весь сервер, а потім відновити призначені для користувача бази даних з резервних копій. Якщо пошкоджена база даних master, а для користувача бази даних не постраждали, то можна думати про те, щоб перевстановити сервер або перебудувати базу даних master, а для користувача бази даних приєднати. Такий варіант буде найбільш надійним.
Відновлення бази даних master відрізняється від відновлення звичайних баз даних деякими особливостями:
проводити відновлення бази даних master можна тільки після перезапуску сервера в режимі одного користувача. Найпростіше зробити це, запустивши SQL Server з командного рядка. Для цього потрібно перейти в каталог, в якому знаходиться файл sqlservr. Exe (за замовчуванням це C: \ Program Files \ Microsoft SQL Server \ MSSQL .1 \ MSSQL \ Binn), а потім виконати команду: sqlservr. Exe - m
якщо база даних master пошкоджена, то сервер цілком може не запуститися. У цьому випадку, щоб все-таки можна було запустити сервер і зробити процедуру відновлення, потрібно перебудувати базу даних master. При перестроюванні база даних master повертається до свого вихідного стану (коли сервер був щойно встановлений). У попередніх версіях SQL Server для перестроювання бази даних master використовувалася спеціальна утиліта rebuildm. У SQL Server 2005 для цієї мети використовується програма установки SQL Server;
для бази даних master доступний тільки один тип резервного копіювання - повне резервне копіювання всієї бази даних. Тому відновити ви можете тільки всю базу даних master цілком. Резервне копіювання і відновлення журналів транзакцій, а також будь-які інші операції відновлення (файлів, файлових груп, окремих сторінок і т. п.) для цієї бази даних не передбачені;
після відновлення бази даних master сервер автоматично перезавантажиться.
Після того, як відновлення бази даних master завершиться, дуже рекомендується перевірити, чи не виникло якихось проблем на SQL Server. Можуть виявиться проблеми:
з логінами. Для перевірки можна використовувати збережену процедуру sp _ validatelogins;
з користувачами баз даних. Перевірку можна зробити за допомогою команди: sp _ change _ users _ login @ Action = 'Report';
зі списком баз даних на сервері. Якщо якийсь бази даних у списку немає, але файли її залишилися на диску, цю базу даних можна заново приєднати до сервера.
Якщо ви зробили перестроювання бази даних master, то після завершення відновлення цієї бази даних обов'язково потрібно провести відновлення баз даних model і msdb. В іншому, резервне копіювання і відновлення цих баз проводиться так само, як і для користувача.
Провести резервне копіювання бази даних tempdb неможливо. Оскільки ця база даних створюється заново при кожному запуску SQL Server, то відновлювати її не потрібно.
Висновок
Процес відновлення даних - найважливіша операції в SQL Server. Відновити дані не так складно, як уявлялося раніше, особливо за допомогою графічного інтерфейсу утиліти Enterprise Manager. Утруднення викликає тільки відновлення пошкодженої бази даних master.
Роблячи резервні копії і тестуючи кожну створювану резервну копію і відновлену базу даних, ми уникаємо частих втрат даних і збоїв.
Резервне копіювання необхідно для можливості швидкого і недорогого відновлення інформації у випадку поломки робочої копії бази з якої-небудь причини.
Наприкінці своєї роботи хочеться привести перший закон Чизхолма, який доводить актуальність даної роботи:
Все, що може зіпсуватися, псується.
Все, що не може зіпсуватися, псується теж.
Список літератури
Ковязін О.М., Востріков С.М. "Світ Interbase", М.: Кудиц-Образ, 2002р.
Кріс Касперски «Відновлення даних. Практичне керівництво »Спб.: БХВ-Петербург, 2007р.
Леонов Василь. «Відновлення даних». М.: Ексмо, 2009 р.
Міхєєв Ростислав «MS SQL Server 2005 для адміністраторів". Спб.: БХВ-Петербург, 2007р.
Вільям Р. Станек «Microsoft SQL Server 2005. Довідник адміністратора». М.: Російська Редакція, 2008 р.