В цій статті
Моментальний знімок бази даних є статичним, доступним тільки для читання поданням бази даних SQL Server SQL Server (бази даних-джерела). A database snapshot is a read-only, static view of a SQL Server SQL Server database (the source database). Моментальний знімок бази даних узгоджується на рівні транзакцій з базою даних-джерелом в момент створення знімка. The database snapshot is transactionally consistent with the source database as of the moment of the snapshot's creation. Моментальний знімок бази даних завжди знаходиться на тому ж примірнику сервера, що і база даних-джерело. A database snapshot always resides on the same server instance as its source database. При оновленні бази даних-джерела оновлюється і моментальний знімок бази даних. As the source database is updated, the database snapshot is updated. Це означає, що чим довше існує моментальний знімок бази даних, тим більша ймовірність того, що він витратить все доступне місце на диску. Therefore, the longer a database snapshot exists, the more likely it is to use up its available disk space.
Може існувати кілька моментальних знімків однієї і тієї ж бази даних-джерела. Multiple snapshots can exist on a given source database. Кожен моментальний знімок бази даних існує до тих пір, поки він не буде явно видалений власником бази даних. Each database snapshot persists until it is explicitly dropped by the database owner.
Примітка
Загальні відомості про функції Feature Overview
Знімки бази даних працюють на рівні сторінок даних. Database snapshots operate at the data-page level. Перед першою зміною бази даних-джерела вихідна сторінка копіюється з неї в моментальний знімок. Before a page of the source database is modified for the first time, the original page is copied from the source database to the snapshot. Моментальний знімок зберігає вихідну сторінку, залишаючи записи даних в тому вигляді, в якому вони існували на момент створення знімка. The snapshot stores the original page, preserving the data records as they existed when the snapshot was created. Процес повторюється для кожної сторінки, змінною вперше. The same process is repeated for every page that is being modified for the first time. Для користувача моментальний знімок ніколи не змінюється, оскільки операції зчитування в моментальному знімку бази даних завжди звертаються до вихідних сторінок даних, незалежно від того, збереглися вони чи ні. To the user, a database snapshot appears never to change, because read operations on a database snapshot always access the original data pages, regardless of where they reside.
Для зберігання вихідних сторінок моментальний знімок використовує один або більше розріджених файлів. To store the copied original pages, the snapshot uses one or more sparse files. Спочатку розріджений файл являє собою порожній файл, який не містить ніяких призначених для користувача даних, і йому ще не виділено місце на диску для призначених для користувача даних. Initially, a sparse file is an essentially empty file that contains no user data and has not yet been allocated disk space for user data. У міру відновлення сторінок в базі даних-джерелі розмір файлу збільшується. As more and more pages are updated in the source database, the size of the file grows. На цьому малюнку показано дію двох різних конфігурацій оновлення на розмір моментального знімка. The following figure illustrates the effects of two contrasting update patterns on the size of a snapshot. Конфігурація поновлення А відображає умови, при яких протягом життя моментального знімка оновлюється тільки 30% всіх вихідних сторінок. Update pattern A reflects an environment in which only 30 percent of the original pages are updated during the life of the snapshot. Конфігурація поновлення Б відображає умови, при яких протягом життя моментального знімка оновлюється тільки 80% всіх вихідних сторінок. Update pattern B reflects an environment in which 80 percent of the original pages are updated during the life of the snapshot.
Переваги моментальних знімків баз даних Benefits of Database Snapshots
Знімки можна використовувати для складання звітів. Snapshots can be used for reporting purposes.
Клієнт може запитувати моментальний знімок бази даних, що може знадобитися для створення звітів на основі даних, що відносяться до моменту створення знімка. Clients can query a database snapshot, which makes it useful for writing reports based on the data at the time of snapshot creation.
Підтримка хронологічних даних для створення звітів. Maintaining historical data for report generation.
Моментальний знімок дозволяє користувачеві отримати доступ до даних за станом на певний момент часу. A snapshot can extend user access to data from a particular point in time. Наприклад, моментальний знімок бази даних можна створити в кінці певного періоду часу (наприклад, фінансового кварталу) для подальшого створення звітів. For example, you can create a database snapshot at the end of a given time period (such as a financial quarter) for later reporting. Звіти про кожний такий періоді будуть створюватися на основі даних з моментального знімка. You can then run end-of-period reports on the snapshot. Якщо на диску достатньо вільного місця, можна створювати такі моментальні знімки для кожного звітного періоду і дозволити запити результатів по звітних періодах, що може знадобитися, наприклад для дослідження ефективності діяльності організації. If disk space permits, you can also maintain end-of-period snapshots indefinitely, allowing queries against the results from these periods; for example, to investigate organizational performance.
Економія ресурсів за рахунок доступності даних, необхідних для створення звітів, в дзеркальних базах даних. Using a mirror database that you are maintaining for availability purposes to offload reporting.
Застосування моментальних знімків з дзеркальним відображенням баз даних дозволяє зробити дані на дзеркальному сервері доступними для звітів. Using database snapshots with database mirroring permits you to make the data on the mirror server accessible for reporting. Крім того, виконання запитів в дзеркальній базі даних може звільнити ресурси основної бази даних. Additionally, running queries on the mirror database can free up resources on the principal. Додаткові відомості див. У статті Дзеркальне відображення і моментальні знімки баз даних (SQL Server). For more information, see Database Mirroring and Database Snapshots # 40; SQL Server # 41 ;.
Захист даних від адміністративних помилок. Safeguarding data against administrative error.
При виникненні користувача помилки в базі даних-джерелі цю базу даних можна повернути до стану, в якому вона перебувала на момент створення певного моментального знімка бази даних. In the event of a user error on a source database, you can revert the source database to the state it was in when a given database snapshot was created. Втрата даних торкнеться тільки зміни в базі даних, вироблені після створення знімка. Data loss is confined to updates to the database since the snapshot's creation.
Перед серйозними оновленнями, такими як масове оновлення або зміна схеми, слід створити моментальний знімок бази даних для захисту даних. For example, before doing major updates, such as a bulk update or a schema change, create a database snapshot on the database protects data. У разі помилки можна буде відновити базу даних шляхом повернення її в попередній стан за допомогою моментального знімка. If you make a mistake, you can use the snapshot to recover by reverting the database to the snapshot. Потенційно процедура повернення займає набагато менше часу, ніж відновлення з резервної копії, але при цьому вона не підтримує накат. Reverting is potentially much faster for this purpose than restoring from a backup; however, you can not roll forward afterward.
Відновлення не застосовується до пошкодженої базі даних і до бази даних, яка перебуває в режимі поза мережею. Reverting does not work in an offline or corrupted database. Таким чином, створення регулярних резервних копій і тестування плану відновлення необхідні для захисту бази даних. Therefore, taking regular backups and testing your restore plan are necessary to protect a database.
Примітка
Знімки бази даних залежать від бази даних-джерела. Database snapshots are dependent on the source database. Отже, стратегію резервного копіювання та відновлення не слід замінювати відновленням даних за допомогою моментальних знімків бази даних. Therefore, using database snapshots for reverting a database is not a substitute for your backup and restore strategy. Планове створення резервних копій залишається основною дією. Performing all your scheduled backups remains essential. Якщо необхідно відновити базу даних-джерело на момент часу, в який був створений моментальний знімок бази даних, реалізуйте політику резервного копіювання, що дозволяє це робити. If you must restore the source database to the point in time at which you created a database snapshot, implement a backup policy that enables you to do that.
Захист даних від користувача помилок. Safeguarding data against user error.
Регулярне створення моментальних знімків бази даних може зменшити шкоду від серйозних помилок користувачів, наприклад від видалення тієї чи іншої таблиці. By creating database snapshots on a regular basis, you can mitigate the impact of a major user error, such as a dropped table. Щоб забезпечити високий рівень захисту можна створити кілька моментальних знімків баз даних, що охоплюють період часу, достатній, щоб розпізнати більшість призначених для користувача помилок і усунути їх наслідки. For a high level of protection, you can create a series of database snapshots spanning enough time to recognize and respond to most user errors. Наприклад, якщо достатньо вільного місця на диску, то можна підтримувати від 6 до 12 моментальних знімків, що охоплюють 24-годинний інтервал. For instance, you might maintain 6 to 12 rolling snapshots spanning a 24-hour interval, depending on your disk resources. При створенні наступного моментального знімка найраніший буде віддалятися. Then, each time a new snapshot is created, the earliest snapshot can be deleted.
Для усунення помилки користувача можна за допомогою моментального знімка повернути базу даних в стан безпосередньо перед цією помилкою. To recover from a user error, you can revert the database to the snapshot immediately before the error. Потенційно процедура повернення займає набагато менше часу, ніж відновлення з резервної копії, але при цьому вона не підтримує накат. Reverting is potentially much faster for this purpose than restoring from a backup; however, you can not roll forward afterward.
Примітка
Від причини використання моментальних знімків залежить число паралельних знімків для однієї бази даних, частота створення нових знімків і термін їх зберігання. Your reasons for using database snapshots determine how many concurrent snapshots you need on a database, how frequently to create a new snapshot, and how long to keep it.
Управління тестової базою даних. Managing a test database
При періодичному виконанні тестового протоколу в базі даних тестового середовища корисно, щоб база даних містила однакові дані на початку кожного циклу тестування. In a testing environment, it can be useful when repeatedly running a test protocol for the database to contain identical data at the start of each round of testing. Перед виконанням першого циклу розробник програми або тестувальник може створити моментальний знімок тестової бази даних. Before running the first round, an application developer or tester can create a database snapshot on the test database. Після кожного запуску тестування базу даних можна швидко повернути в попередній стан шляхом повернення моментального знімка бази даних. After each test run, the database can be quickly returned to its prior state by reverting the database snapshot.
Терміни та визначення Terms and Definitions
database snapshot database snapshot
Узгоджена на рівні транзакцій, доступне тільки для читання зріз бази даних (бази даних-джерела). A transactionally consistent, read-only, static view of a database (the source database).
бази даних-джерела source database
Для моментального знімка бази даних - база даних, в якій створено моментальний знімок. For a database snapshot, the database on which the snapshot was created. Знімки бази даних залежать від бази даних-джерела. Database snapshots are dependent on the source database. Вони повинні знаходитися на одному екземплярі сервера разом з базою даних. The snapshots of a database must be on the same server instance as the database. Більш того, якщо з якої-небудь причини база даних стає недоступною, все її моментальні знімки також стають недоступними. Furthermore, if that database becomes unavailable for any reason, all of its database snapshots also become unavailable.
розріджений файл sparse file
Файл, наданий файлової системою NTFS, в результаті чого він займає значно менше місця на диску, ніж звичайні файли. A file provided by the NTFS file system that requires much less disk space than would otherwise be needed. Розріджений файл використовується для зберігання сторінок, поміщених в моментальний знімок бази даних. A sparse file is used to store pages copied to a database snapshot. Після створення розріджений файл займає небагато місця на диску. When first created, a sparse file takes up little disk space. У міру занесення даних в моментальний знімок бази даних файлову систему NTFS поступово виділяє місце на диску для відповідного розрідженого файлу. As data is written to a database snapshot, NTFS allocates disk space gradually to the corresponding sparse file.