част 1

Създаване архивиране MS SQL. това е едно от първите неща, което идва на ум, когато се отразява върху последиците от загубата на производствени бази данни. Често, много администратори е да се реши този проблем започва първата среща с SQL Management Studio сървър (SSMs) и Transact SQL език (T-SQL). Тази публикация, ние решихме да започнем поредица от статии, посветени на типичните грешки и неточности. Ние няма да се опише как да изпълните стъпките на копието на конфигурацията, и се съсредоточи върху най-важните точки, които обикновено са пренебрегвани, в резултат на което обезсмисля всички настройки за архивиране MS SQL.

Недоразумение: Имам нужда само създаде резервни копия ...

Така че обикновено мислим за тези, които за пръв път се сблъскват с този въпрос. Все пак, не всичко е толкова лесно, колкото изглежда на пръв поглед. Тук е минимален списък от въпроси, които ще трябва да се разбере:

Каква е вашата резервна стратегия?
Какво е възстановяването на модела на базата данни, както и кой модел да изберете?
Къде по-добре да се сложи резервни копия на файлове и как да ги провери?
За какъв период от време, те се съхраняват архивите?
Как да се създаде редовна проверка на целостта на SQL база данни сървър?
Как да се създаде електронна поща уведомление от грешки?

Почти всеки проблем има собствен списък с грешки и моделни грешки.

Грешка: Изберете грешната стратегия за архивиране и възстановяване

архивиране и възстановяване стратегия се определя от модела на база данни за възстановяване, честотата на резервно копие (пълен, диференциал и регистър на транзакциите) и дълбочината на съхраняване на резервни копия. Стратегията всъщност определя какво ще загубите максимума за периода от време, данните в случай на повреда, както и колко време е възстановяването ще се извърши. С други думи, стратегията за планиране трябва да се ръководи от информация важност и сериозност на последствията, когато се загубили в случай на повреда, както и приемливо срив скорост. Много често, за да не се притеснява, избран най-лесният стратегия, докато загубата на данни, дори и за кратък период от време е изпълнен със сериозни последици за бизнеса.

Трябва да се отбележи, че SQL Server ви позволява да възстановите базата данни, а не само по времето, когато е бил създаден пълния си резервно (бекъп), но също така и по всяко друго момент. За да направите това в дневника сървър сделка SQL е механизмът. Механизмът е прост - всички искания за информация на климата, които са получени от SQL Server, се записват в регистър на транзакциите. В същото време на списанието трябва периодично архивиране. Това се прави бързо и безпроблемно за потребителите. В случай на повреда възстановява цялата верига на свой ред: първо, пълно резервно копие на базата данни, и след това влезте архиви. В резултат на това, базата данни ще бъде възстановено по време на архивирането на миналата регистър на транзакциите.

Модел възстановяване на база данни е един от най-важните качества, които определят дали регистър на операциите, се запазва. Така че в пълния модел на възстановяване, регистър на транзакциите се поддържа, и то не се вижда целият автоматично с един прост модел.

Грешка: Пълен модел възстановяване без резервно копие на регистър на транзакциите

За да се сведе до минимум грешки при създаването на политика обслужване на шаблона QMB автоматично ще зададе правилния модел на базата данни.

Недоразумение: пълен модел на възстановяване е по-малко продуктивни, отколкото прост

Някои съществена разлика между изпълнението на пълно и прост модел за възстановяване не. Трябва да се каже, че данните, записани в регистъра на операциите за всеки модел възстановяване. Въпреки това, ако моделът Simple възстановяване, лог файл е съкратено автоматично.

Грешка: Не може да се създаде уведомяване на администратора

Настройка архивиране MS SQL, че няма да бъде направено, докато нотификации са конфигурирани (обикновено по електронна поща). Мисля, че всеки разбира, че администраторът трябва незабавно да проверите за грешки по време на операции по архивиране, в противен случай цялата работа с резервно няма смисъл. В крайна сметка, това, че на резервната е днес, не означава, че ще работи утре. Причините за това могат да бъдат много: изтече на дисково пространство, да се променят правилата на директория и т.н. В нашата практика, тя е основен тест, когато администратор в момента на катастрофата установено, че архивите са работещи на база данни е на няколко месеца не са били създадени.

Необходимо е да се отбележи, един неприятен момент: известие, че изпраща редовно компонент DataBase Mail не съдържа информация за грешката. Ето защо, след като го получите, за да се разбере сериозността на грешките, администраторът трябва да гледате всеки път, когато трупи SQL Server. За съжаление, с течение на времето, много администратори вече не се пренебрегват грешките и да реагират на тях. По закон, в жанра е в такава база време летят в ада.