» Microsoft SQL SERVER

naPmu3aH


Цитата:

Никакого MIRROR TO нет ни в Enterprise, ни в любой другой редакции SQL Server.

Вот вам ссылка на msdn: BACKUP (Transact-SQL).

Цитата:

MIRROR TO <устройство_резервного_копирования> [ ,...n ]

Указывает набор от одного до трех устройств резервного копирования, которые будут зеркалами для устройств резервного копирования, описанных в предложении TO. В предложении MIRROR TO должен быть указан тот же тип и то же количество устройств резервного копирования, что и в предложении TO. Максимальное число предложений MIRROR TO — три.

Этот параметр доступен только в SQL Server 2005 Enterprise Edition и более поздних версиях.

Цитата:

Если надо делать бекапы на локальный и на удаленный - можно делать на локальный и удаленный по UNC пути последовательно

Нельзя делать последовательно. С диф бэкапами (и бэкапами лога) могут возникнуть проблемы при восстановлении, если будет поврежден один из этих бэкапов. Бэкапы должны быть одинаковыми абсолютно.
Копировать по сети - можно. Но это уже не относится к sql server.


Цитата:

Если же говорить о зеркалировании AKA Database Mirroring

Зачем вы здесь приплели database mirroring я не понял.

Возможно вопрос тупой и уже раз 100 обсуждался, но я так и не могу понять один момент.
Для чего и как используется параметр "Срок действия набора данных истекает" ?
При создании бэкапов на устройство резервного копирование в "Maintance Plan" есть 2 варианта выбора: присоединить, перезаписать.
При выборе "присоединить" бэкапы с прошедшим сроком действия не удаляются.
При выборе "перезаписать" каждый раз стирается весь носитель со всеми предыдущими бэкапами, не зависимо от сроков действия последних.
Как настроить бэкап на устройство, с автоматическим удалением бакапов, у которых истёк срок действия ?
Или нужно бэкапить каждый раз в отдельный файл и затем удалять старые при помощи задачи "Очистка после обслуживания" ?
Надеюсь на полноценный ответ, а не очередной ссылки на базу знаний М$.
Спасибо!

Egenius
EXPIREDATE работает в связке с INIT/NOINIT, SKIP/NOSKIP. Первый из этих параметров вы знаете - он означает перезапись набора данных/"присоединение". Второй отвечает за то будет проводиться проверка параметра EXPIREDATE или нет.
Вот только что я создал бэкап базы с EXPIREDATE +5 минут от текущего времени, пробую его перезаписать (INIT, NOSKIP), получаю ошибку:

Цитата:

The medium on device 'D:\tmp\backup1.bak' expires on Nov 11 2011 11:51:51:000AM and cannot be overwritten.

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

Цитата:

BACKUP DATABASE successfully

Не очень, наверное, очевидный момент, но перезаписать - это действительно ПЕРЕЗАПИСАТЬ все на устройстве. Т.е. бэкап с INIT, NOSKIP пройдет только тогда, когда у ВСЕХ бэкапов на устройстве истечет "срок хранения". В противном случае оно будет кричать, что есть наборы с неистекшим сроком хранения.

Перезаписать один конкретный бэкап в устройстве не получится.

bigsloth
Тогда совсем уж не понятна эта фича с со сроками хранения. Зачем она вообще нужна? Если нельзя в одном устройстве удалять один конкретный бэкап, то зачем это вообще придумано ? Или это рудиментарные остатки от работы с ленточными накопителями ?
Проще и удобнее тогда уж создавать отдельные файлы для каждого бэкапа и потом скриптом удалять старые.

Egenius
Ничего не могу сказать. Мне эта фича так же не очень понятна. Наверное, ее можно использовать, если создать, например, 7 дамп девайсов и в понедельник писать все в один, во вторник в другой и тд, тем самым храня в 7 файлах все бэкапы за неделю. Ну это так, пример высосан из пальца .

Egenius
у меня сделано так: в каждый девайс (файл на диске) сохраняется полная ежемесячная копия одной базы с ПЕРЕЗАПИСЬЮ. Далее ежедневно делается разностная копия той же базы с добавлением к существующему. Ну и в течении дня каждые 2 часа с 8:00 до 19:00 туда же скидывается лог транзакций, после которого происходит сжатие баз. И такая схема для каждой базы. Все в одном плане.
P.S. ежедневно, в ночное время делается полная копия каждой базы, средствами командной строки (osql), и потом уже копии всех баз сжимаются WinRAR и складываются в папочку с бекапами.

bigsloth
Какбэ особой разницы между тем что Вы предложили и созданием отдельных файлов с последующим удалением лишних не вижу
Serg0FFan
На мой взгляд, было бы более логично если бы механизм работал так:
При записи в девайс происходит проверка сроков всех бэкапов в хранилище и те, у которых истёк срок, удаляются, а новый бэкап записывается в конец девайса. И так каждый раз. В идеале можно было бы иметь вообще один файл , в котором собрать как полные бэкапы раз в неделю, так и инкрементальные по дням+журналы транзакций. И всё это удовольствие не разрастается бесконечно, а чистится в зависимости от выставленных сроков.
Не знаю чем руководствовались создатели этой замечательной DB при создании подобной фичи, но точно не её удобством для пользователей. В результате всем приходится использовать либо сторонний софт, либо самописные скрипты. Как всегда, БРАВО M$ !!!

Egenius
В итоге размер всех девайсов (три рабочих базы + системные) не превышает 10 гигов.
Можно сделать 2 аналогичных плана, которые будут работать в разные числа. Например первый план работает с 1го числа по 15ое, сохраняя базу в device1 а второй план с 16 по 30(31) сохраняя в device2, в итоге, начиная с 16го числа и по 30ое у нас в device1 будут доступные копии, которые до конца месяца будут не перезаписаны! А уже с 1го числа сл. месяца они конечно перезапишутся, но! останутся копии с 16 по 30(31) число Надеюсь мысль ясна. Пока не придумал как реализовать - загвоздка с датой конца месяца.

Egenius
Ну почему же. Разница есть. В этом примере у меня будет всего 7 файлов за неделю на каждую базу (или вообще всего 7, как я захочу), а в примере с отдельными файлами: 7*(1 файл с фулл-бэкапом + 4 диффа + 4*24 бэкапов лога) - на каждую базу (в моих условиях). И потом, при необходимости восстановления мне придется прописывать для каждого файла RESTORE DATABASE ... А в варианте с устройствами всего один раз.
Тут есть и минус - размер такого файла будет ого-го.

Serg0FFan
Ммм. Не совсем понятна проблема. Как это сделать планом затрудняюсь сказать, а вот в job на TSQL довольно легко:
@expdate = DATEADD(day, -1*DATEPART(day, GETDATE()), DATEADD(month, 1, GETDATE())) - дата конца текущего месяца. В зависимости от даты бэкапить либо в дампдевайс1, либо в дампдевайс2.

где эта функция находиться MIRRO TO?

bigsloth
Так вот проблема в том чтобы сделать планом это Ибо в TSQL как то не особо силён да и уж если менять всю схему на предложенную, то надо текущие планы "ломать", а уж если делать так чтобы работало нормально.

Добавлено:
Уважаемые, подскажите. Имеется SQL 2008R2 Ent.x64 RUS+ последний CU
Захожу через Management Studio, пытаюсь поменять настройки Агент SQL Server, жму ок и ничего не происходит. Если открыть их по новой то выставленные настройки не сохранились. Что делаю не так?

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

Добавлено:
Так же буду признателен если расскажете/ткнёте ссылкой как настроить электронную почту в этой консоли, чтобы при ошибках отсылались сообщения мне в ящик

Цитата:

Хотел включить опцию: Удалять журнал агента старше чем...

Это баг. ms connect. Видимо, еще не починили.


Цитата:

Так же буду признателен если расскажете/ткнёте ссылкой как настроить электронную почту в этой консоли, чтобы при ошибках отсылались сообщения мне в ящик

по-русски
по-аглицки 1
по-аглицки 2
Там вообще мастер очень удобный и достаточно простой. Единственное, что надо не пропустить - создать публичный профиль. Это, в принципе, не обязательно, но так будет проще.

Не могу понять в чём проблема.
Раз в неделю делается полный бэкап всех баз, которые складываются отдельными файлами в отдельной папке для каждой базы.
Раз в сутки делаются разностные бэкапы тех же баз.
Когда запускаю задания вручную всё проходит нормально.
А вот по расписанию каждую ночь бэкап отрабатывает с ошибкой, мол, инкрементальный бэкап не может быть сделан т.к. нет полной резервной копии. НА самом деле всё есть и лежит оно в той же папке что и инкрементальные бэкапы.
Бьюсь с эти уже неделю, но решить проблему так и не могу.
Помогите разобраться, плииз!!!

Egenius
В SQL Server нет понятия "инкрементальный бэкап". Есть полные, дифференциальные и бэкапы журнала транзакций. И диф, и бэкап ЖТ, с определенной "натяжкой" можно назвать инкрементальными. Про какие конкретно бэкапы идет речь?
Покажите записи из журнала ошибок SQL Server.

bigsloth
про дифференциальные

Egenius
и еще:

Цитата:

Покажите записи из журнала ошибок SQL Server.

Со злости удалил предыдущий план обслуживания, а вместе с ним похоже и все логи.
Вот что осталось.

Код:
Операция BACKUP не выполнила команду BACKUP DATABASE msdb WITH DIFFERENTIAL. Проверьте дополнительные сообщения в журнале приложения резервного копирования.
-----------------
SQL Server Scheduled Job 'Задачи резервного копирования.Инкрементальный бэкап каждый день' (0x02EC587C4A2E5E45B4AC98F1B75B7963) - Status: Ошибка - Invoked on: 2011-11-14 02:00:00 - Message: Не удалось завершить задание. Запуск задания был произведен Расписание 12 (Задачи резервного копирования.Инкрементальный бэкап каждый день). Последним выполнявшимся шагом был шаг 1 (Инкрементальный бэкап каждый день).

Цитата:

BACKUP DATABASE msdb WITH DIFFERENTIAL

Есть подозрение, что полные бэкапы в плане делаете для всех пользовательских баз, а дифференциальные бэкапы для всех баз (включая системные). Проверьте этот момент.
Возможно, SQL Server начинает делать бэкапы в порядке возрастания database_id, видит что для системной базы msdb нет полного бэкапа и вываливается с ошибкой, даже не пытаясь приступить к бэкапу пользовательских баз.

bigsloth
Полные бэкапы есть для всех баз, как пользовательских так и системных.
Дифференциальные делаются для всех баз, которые это позволяют делать. К примеру база master не позволяет делать диф. бэкап и её в плане обслуживание для ежедневных бэкапов нет. Для всех остальных вываливается ошибка, при чём для каждой базы одна и та же ошибка.

Egenius
хм, посмотрите этот fix - может быть ваша проблема. Если не поможет, возможно имеет смысл попробовать обновиться до последнего SP+CU.

bigsloth
Проблема похожая, но тут патч для 2005 сервера, а у меня 2008.

А Windows бэкапы не делает?
Еще здесь похожая проблема.

Винда делает теневые копии томов и состояния системы раз в сутки. Но время бэкапов разное и не совпадает с заданиями MSSQL.

Egenius
Посмотрите вот это. naPmu3aH приводил решение.

bigsloth
Отключил службу SQLWriter. Буду мониторить.
Спасибо!

Такая вот интересная проблема возникла.
Стоял sharepoint server 2007 в паре с SQL server 2008 - для вывода отчетов опубликованных на ReportServer. Все работало отлично.
Обновили одновремено на sharepoint server 2011 и sql server 2008 r2. Практически все заработало нормально - у пользователей на сайте sharepoint стало просить авторизацию когда открываешь отчет ReportServer (при навигации по сайту самому нигде ничего не спрашивает). Настроена везде Windows авторизация. Что самое интересное, что если нажать кнопку отмена в окне ввода логина и пароля - отчет прекрасно открывается. Может кто сталкивался с такой проблемой - подскажите где что подкрутить убрать надоедливое окно.
Еще интересное наблюдение в папке пользователей Windows стали появляется "временные" каталоги пользователей (формат temp.MoyDomen.001), в паке лежит файл ntuser.dat. Если убрать эти папки - встает раком ReportServer. Это так и должно быть такие пользователи "временные" или все же гдето ошибка в настройках

Здравствуйте. Возникла необходимость вынести одну таблицу в SQL 2005 и в SQL 2008 в другую файловую группу. На просторах интернета нашел статью: http://decipherinfosys.wordpress.com/2007/08/14/moving-tables-to-a-different-filegroup-in-sql-2005, но не получается у меня сделать так, как там написано - в таблице нет кластерного индекса, который в примере при переносе таблицы дропается. (ALTER TABLE TAB1 DROP CONSTRAINT PK_TAB1 WITH (MOVE TO TEST_DATA_2)). А если использовать команду без дропа - синтаксические ошибка. Подскажите, как все-таки переместить таблицу в другую файловую группу?

SerBUser
Раз у вас нет кластерного индекса, создайте его и укажите в нем ON [Нужная файловая группа]. Когда создастся - убивайте этот индекс, таблица перенесена. Учтите, что остальные индексы никуда не переедут и будут относиться к той файловой группе, в которой создавались

Вечер добры не могу в новую базу востановить вчерашний архив скуль 2008, описываю по шагах
1.создал базу test
выбираю востановить, указываю архив с которого нужно брать, указываю файлы в которые нужно сохранить, ставлю галочку Перезаписать существующую базу данных и выполнить и вылетает ошибка Резервный набор данных содержит копию базы данных, отличной от существующей базы данных (Ошибка 3154).