Как бэкапить данные MS SQL 2008 + HP MSA2000 G3 SAS

[Bormoto]

Режим всех баз - simple. Причина - 1С 8.2

А можно узнать, какая связь?

Присоединяюсь к заданному вопросу. Очень интересно узнать - какая же связь? Неужели потому, что известный "апостол" 1С Вячеслав Гилев использовал модель simple в своей статье про резервное копирование и восстановление?

[reallord]

Режим всех баз - simple. Причина - 1С 8.2

А можно узнать, какая связь?

Присоединяюсь к заданному вопросу. Очень интересно узнать - какая же связь? Неужели потому, что известный "апостол" 1С Вячеслав Гилев использовал модель simple в своей статье про резервное копирование и восстановление?

Я не гуру в SQL, но свои соображения скажу.
Смысл в том, что исходя из бизнес-логики приложения, нельзя вручную откатить транзакции.
То есть с точки зрения 1С, в момент проведения документа идет НЕСКОЛЬКО транзакций, а не одна.
И если откатить часть транзакций, то можно получить ситуацию, что проведенный документ не делает движений по регистрам и не попадает в отчет, что некорректно с точки зрения бизнес-логики. Если бы проведение всего документа проходило в одной транзакции, то тогда были бы проблемы с производительностью и масштабируемостью.

Если сможете объяснить чем будет лучше режим full, то обещаю как минимум задуматься...

[kim_aa]

1) У SAP тоже самое.
Более того связность БД на уровне бизнес-логики нельзя проконтролировать просто поддерживая связность БД на уровне сервера СУБД.
У меня есть подозрение, что такая ситуация стандартна для трехуровневых приложений
(с собственными модулями/языком для реализации бизнес-логики).

2) Что же касаемо описываемой вами ситуации с транзакционностью, то все верно если писать "транзакции сервера СУБД". Действительно на одну транзакцию сервера приложений приходится неопределенное количество транзакций сервера СУБД.

3) Кстати сам сервер приложений 1С поддерживает транзакционную модель?

[reallord]

1) У SAP тоже самое.
Более того связность БД на уровне бизнес-логики нельзя проконтролировать просто поддерживая связность БД на уровне сервера СУБД.
У меня есть подозрение, что такая ситуация стандартна для трехуровневых приложений
(с собственными модулями/языком для реализации бизнес-логики).

2) Что же касаемо описываемой вами ситуации с транзакционностью, то все верно если писать "транзакции сервера СУБД". Действительно на одну транзакцию сервера приложений приходится неопределенное количество транзакций сервера СУБД.

3) Кстати сам сервер приложений 1С поддерживает транзакционную модель?

1) у меня такие же подозрения, переходящие в твердую уверенность, так как ничего лучше сами после многократного обсуждения подобных ситуаций придумать не смогли
2) да, именно "транзакции сервера СУБД"
3) Да, поддерживает, и даже поддерживает на уровне СУБД, но это практически крайне редко используется, так как приводит к блокировкам записи.
То есть используя язык 1С можно открыть транзакцию и закрыть ее, она будет объявлена на уровне MS SQL и внутри нее будут транзакции уровня проводок документа. Так обычно и делается системно на уровне платформы, если при проведении документа происходит ЛОГИЧЕСКАЯ бизнес ошибка (типа нет остатка на складе).

Если мне кто-то связно сможет объяснить зачем иметь transaction log уровня full в случае если ты не имеешь возможности сделать откат транзакции, я буду этому человеку крайне благодарен. Даже на дисках ИТС в методологических материалах по настройке MS SQL для 1С написано что режим ставим simple.

[diz]

Мне кажется, что одна транзакция СП=одна транзакция СУБД. Иначе бы не работали такие механизмы обеспечения высокой доступности как log shipping. Более того, вообще систему из бэкапа БД, в т.ч. full восстановить было бы нельзя, т.к. нельзя было бы прогарантировать, что СП в момент бэкапа не имеет незавершенную транзакцию. Все примочки к софту резервного копирования для поддержки приложений (напр. тот же агент SAP в симантек) лишь добавляют удобства, позволяя во время восстановления оперировать не только моментом времени, как в случае восстановления из бэкапа БД, а объектами бизнес-приложения. Мы неоднократно восстанавливали SAP из бэкапа с исп. транзакционных логов, непонятнок в системе не возникало (у нас как-раз агент SAP не был куплен).

Собственно, краем уха слышал, что это делается как-то так.

[ITER]

Я не гуру в SQL, но свои соображения скажу.
Смысл в том, что исходя из бизнес-логики приложения, нельзя вручную откатить транзакции.
То есть с точки зрения 1С, в момент проведения документа идет НЕСКОЛЬКО транзакций, а не одна.
И если откатить часть транзакций, то можно получить ситуацию, что проведенный документ не делает движений по регистрам и не попадает в отчет, что некорректно с точки зрения бизнес-логики. Если бы проведение всего документа проходило в одной транзакции, то тогда были бы проблемы с производительностью и масштабируемостью.

Если сможете объяснить чем будет лучше режим full, то обещаю как минимум задуматься...

Что то я не понимаю логики. При чем тут ручной откат транзакции (и что это такое вообще?) и режим лога? Вообще то full режим на MS SQL нужен в первую очередь для возможности восстановления базы на любой момент (или до последней закоммиченной транзакции). А как вы будете восстанавливать упавшую базу? На момент последнего бэкапа? А вся работа пользователей после бэкапа коту под хвост?

[ITER]

Мне кажется, что одна транзакция СП=одна транзакция СУБД. Иначе бы не работали такие механизмы обеспечения высокой доступности как log shipping. Более того, вообще систему из бэкапа БД, в т.ч. full восстановить было бы нельзя, т.к. нельзя было бы прогарантировать, что СП в момент бэкапа не имеет незавершенную транзакцию.

Эпическое предложение. С чего бы это в момент бэкапа не должно быть не завершенных транзакций? База во время бэкапа что не может работать по вашему? После восстановления все незавершенные транзакции откатываются вообще то, тоже самое и при запуске субд после аварийного падения сервера.

[diz]

Эпическое предложение. С чего бы это в момент бэкапа не должно быть не завершенных транзакций? База во время бэкапа что не может работать по вашему? После восстановления все незавершенные транзакции откатываются вообще то, тоже самое и при запуске субд после аварийного падения сервера.

Ну прочитайте же внимательно. Я говорил про транзакцию с точки зрения СП. Т.е. если допустить что транзакция БД не равна транзакции СП (бизнес-логики), то не важно, каким образом бы осуществлялся бэкап БД, он бы всегда был неконсистентен с т.з. СП, т.к., действительно, в момент бэкапа работа не останавливается и в бэкап бы попала часть завершенных транзакций с точки зрения БД, но при этом задачи с т.з. бизнес-логики были бы не завершены.

[kim_aa]

Ну прочитайте же внимательно. Я говорил про транзакцию с точки зрения СП. Т.е. если допустить что транзакция БД не равна транзакции СП (бизнес-логики), то не важно, каким образом бы осуществлялся бэкап БД, он бы всегда был неконсистентен с т.з. СП, т.к., действительно, в момент бэкапа работа не останавливается и в бэкап бы попала часть завершенных транзакций с точки зрения БД, но при этом задачи с т.з. бизнес-логики были бы не завершены.

1) Нужно учитывать, что при операции выгрузки дампа сервер СУБД:
- ждет закрытия всех транзакций на уровне сервера СУБД;
- переходит в специфическое состояние, когда файлы данных переходят в состояние RO, а все операции пишутся только в лог.

2) Я не зря писал, что сервер приложений отслеживает связность и целостность таблиц своего уровня (назовем их "логическими таблицами") сам.
Отношение логических таблиц к таблицам уровня сервера СУБД не один к одному.
Можете открыть базу инструментом типа ErWin и полюбоваться.
Если Вы работали с SAP, то должны знать, что инструментарий сервера СУБД подержки связности БД не используется никак. Т.е. с точки зрения сервера СУБД это груда (десятки тысяч) таблиц где не настроены даже отношения типа PrimaryKey <-> Forign Key.

3) Если сервер приложений понимает пункт 1 и умеет пункт 2, то почему бы не использовать резервное копирование при помощи средств сервера СУБД?
Более того, я наблюдал ситуацию когда люди делели резервные копии SAP при помощи файловых операций (Solaris 10, Oracle 10, Sap NW7). Т.к. ландшафт был не загружен, а система резервного копирования очень быстрая (SAN + VTL), то проблем у них не было.

[ITER]

Я говорил про транзакцию с точки зрения СП. Т.е. если допустить что транзакция БД не равна транзакции СП (бизнес-логики), то не важно, каким образом бы осуществлялся бэкап БД, он бы всегда был неконсистентен с т.з. СП, т.к., действительно, в момент бэкапа работа не останавливается и в бэкап бы попала часть завершенных транзакций с точки зрения БД, но при этом задачи с т.з. бизнес-логики были бы не завершены.

Равна транзакция БД транзакции СП или не равна какое это имеет значение в вопросах бэкапа-восстановления СУБД. Никакого!

[reallord]

А тема то была про offhost backup

[diz]

Равна транзакция БД транзакции СП или не равна какое это имеет значение в вопросах бэкапа-восстановления СУБД. Никакого!

Ну давайте на примере.

Надо перевести 100 баксов с счета Пети на счет Васи. В рамках СП и бизнес-логики это одна транзакция. Если бы в рамках СУБД это делалось n транзакциями (-100 из клетки Пети, отдельно +100 в клетку Васи, еще куча каких-то вспомогательных изменений), то случись бэкап БД между этими транзакциями, то при восстановлении из него он бы хоть и был целостным с т.з. БД, но с т.з. бизнес-логики там был бы полный атас: у Пети денег сняли, а Вася их не получил.

А тема то была про offhost backup

Как успехи?

[reallord]

А тема то была про offhost backup

Как успехи?

Успехи есть, доки докурил, жду дополнительную HBA карту, чтобы потестировать.

[ITER]

Ну давайте на примере.

Надо перевести 100 баксов с счета Пети на счет Васи. В рамках СП и бизнес-логики это одна транзакция. Если бы в рамках СУБД это делалось n транзакциями (-100 из клетки Пети, отдельно +100 в клетку Васи, еще куча каких-то вспомогательных изменений), то случись бэкап БД между этими транзакциями, то при восстановлении из него он бы хоть и был целостным с т.з. БД, но с т.з. бизнес-логики там был бы полный атас: у Пети денег сняли, а Вася их не получил.

Что значит "Если бы в рамках СУБД это делалось n транзакциями"? Что за если бы? Это СУБД сама будет разбивать транзакцию на части? Что за бред? Если СП делает некую свою транзакцию с помощью нескольких транзакций СУБД, то что нужно делать в случае падения, когда не все транзакции СУБД прошли это дело исключительно СП. Он сам должен повторять нужные транзакции, откатывать выполненные или что там ещё. С точки зрения бэкапа нам на этого глубо наплевать. Иначе бы СП разваливался при банальном падении СУБД.

[reallord]

Ну давайте на примере.

Надо перевести 100 баксов с счета Пети на счет Васи. В рамках СП и бизнес-логики это одна транзакция. Если бы в рамках СУБД это делалось n транзакциями (-100 из клетки Пети, отдельно +100 в клетку Васи, еще куча каких-то вспомогательных изменений), то случись бэкап БД между этими транзакциями, то при восстановлении из него он бы хоть и был целостным с т.з. БД, но с т.з. бизнес-логики там был бы полный атас: у Пети денег сняли, а Вася их не получил.

Что значит "Если бы в рамках СУБД это делалось n транзакциями"? Что за если бы? Это СУБД сама будет разбивать транзакцию на части? Что за бред? Если СП делает некую свою транзакцию с помощью нескольких транзакций СУБД, то что нужно делать в случае падения, когда не все транзакции СУБД прошли это дело исключительно СП. Он сам должен повторять нужные транзакции, откатывать выполненные или что там ещё. С точки зрения бэкапа нам на этого глубо наплевать. Иначе бы СП разваливался при банальном падении СУБД.

Это не совсем так... База не развалиться, но могут быть ситуации, когда в базе есть документы которые по бизнес-логике должны делать движения, но не делают их.
Или наоборот, могут быть документы которые делают движения, но не являются проведенными.
С другой стороны если база восстановлена из бэкапа, а он точно не содержит ВСЕХ данных, так как сделан все равно с какой-то периодичностью, то пару кривых проводок или ошибок это самое малое за что придется отвечать. Есть еще время остановки сервиса, время на восстановление работоспособности и т.п.
Как раз вот время на восстановление, это самое больное. При размере баз 2-3Tb, время на восстановление с бэкапа по 1Гб сети просто неприлично много.