Модель базы SQL, Full или Simple? #512364

Надоело периодически обрезать огромные логи в 20Гб. И почемуто думаю что будет небольшой прирост производительности при использование Simple. Подумал а почему бы не использовать модель Simple. База бэкапиться ежедненвно автоматически после окночания рабочего времени. С базами 1с на SQL работаю уже 4 года ни разу за это время база не рушилась. Может тогда стоит использовать модель без ведения логов? Выскажите мнение кто работал, плюсы и минусы. Ну и хотелось бы услышать есть ли прирост производительности модели Simple?

[4 года ни разу за это время база не рушилась] - не повод расслаблятца Обрезай логи автоматически после автоматического бекапа + добавь бекап транзакций в течении дня - это позволит восстановить базу на любое время

Я использую модель Simple. Если Backup-ы делаются достаточно часто, то и падение SQL можно пережить. Все зависит от того насколько критично потерять что-то и конечно же от ресурсов сервера :)

это только теория. Если размер базы, к примеру, гигов 100 (как у нас), то восстановление базы (при интенсивной работе), которая упала вечером, до состояния "на 12 часов", может занять несколько суток. Именно по этому мы используем simple т.к. в таком случае выгоднее просто завести все заново, чем ждать.

угу.. или добавить бэкапы лога чаще чем один раз в день и смотреть на чудо - как при модели восстановления FULL логи не растут.. что ж у вас за железо такое? у нас примерно такая же база - восстановление займет не более полутора часов..

Тоже использую Simple, бывает логи забивают весь диск - очень проблематично все восстановить быстро, проще делать бэкапы

да железо нормально. база бэкапируется при работающих пользователях минут 15. Несколько раз специально проводили эксперименты с логом транзакций. Через двое суток "висения" просто обрубали и признавали эксперимент провалившимся. Легче делать бэкапы по чаще.

это странно, я бы на вашем месте разобрался.. Может просто не переводили базу в состояние recovery ;)? Хотя, конечно, вам решать).

а чего страшного? :) у нас есть админы - это их зона ответственности, мне параллельно ) Но эксперементы проводили. Да и бэкапы делаются достаточно часто.

фулл режим только для студентов и начинающих, с опытом проходит

я лично ни разу не слышал чтобы кому-нибудь помогла фулл модель. На прошлой работе было дело, база накрылась - но она вместе с логом транзакций. Все равно пришлось из бэкапа доставать.

Да вот тоже думаю бэкапить базу, вместо одного раза в день 2 раза и использовать Simple. Еще подскажите на производительность тип модели влияет?

Вот и я про тоже. Начинающие наслушаются SQLщиков и разявив варежки носятся как угорелые. Во всех конторах приходится доказывать бессмысленность фула. Тьфу, блин...

надо запомнить. А всякие там зеркалированиялог-шиппинги научите в симпл модели восстановления настраивать?

ну во первых, задача такая стоит? во вторых, а ты пробовал зеркалирование настроить? Получилось? Все работает?

С кривыми руками ни какое зеркало не спасет (лично видел 2 конторы, где сертифицированные админы проипали смерть зеркала)! Смерть ХДД предсказывается за несколько месяцев и это описано уже миллион раз

мне помогла. Когда у нас один справочник случайно очистили. В который активная запись велась. Восстановил копию "за минуту до удаления" и данные оттуда в рабочую перенес. Да, пробовал. Получилось. Даже сейчас работает. И лог-шиппинг есть, как раз на случай описанный выше.

мне кажется, он имел ввиду, зеркалирование данных на другой сервер. Я такое пробовал.

Я вот тоже прихожу к токому мнению. Я хоть и работаю с SQL 4 года, но знаю его не профессионально. Поэтому если база рухнет, хрен знает как ее только из логов востановить.

Я вам про Фому, вы мне про Ерему.

ну тогда поделись опытом, размер базы? Количество пользователей? Какие базы? (семерка, восьмерка?)

какой sql

mdf 98 гиг, ldf 29 (это осознанно выбранный размер). Пользователей около 70, в пике до 100. Восьмерка, бухгалтерия переписанная + три ЗУПа (они маленькие, ухода не требуют, их отдельная фирма ведет).

+ SQL Server 2005 sp3, 1с 8.1.15.14

а sql какой?

скажу честно, пробовал настроить зерклирование - но у меня ничего не вышло. Рогом в стену не упирался, но для эксперемента хотел. Но даже на самой маленькой базе не вышло,и где-то читал что сама 1С выставляет параметры базы такими, что делает зеркалирование не возможным..

Windows какой стоит? А то У меня Winwows Server 2003 + SQL 2000 SP3. Подумываю что-нибудь поновее поставить и желательно 64х, а то 3Гб памяти маловато уже

И где из прошлых постов я должен был понять смысл слова зеркалирования? А вот от этого варианта мы здесь отказались из-за увеличения нагрузки на систему. Сделал админ, мы прифигели и отключили. В общем это басни из разряда - А вот на Си я бы правильные запросы написал, не то что 1С - А я на асме еще круче напишу

*оперативной памяти

это семерка, если я не ошибаюсь, делает время от времени BACKUP LOG WITH TRUNCATE_ONLY (или аналогичную по смыслу операцию) - это действительно обламывает и зеркалирование, и лог-шиппинг. На восьмерке больше года работает - все нормально. Вообще, если настраивать через GUI проблем быть не должно, если службы SQL Server'a запущены под доменными учетками и есть правила на фаерволе. 1С сервер стоит на Win Server 2008 R2 Ent. 14 гб памяти. SQL Server на Win Server 2008 Standard (в ближайшее время переедем на R2 Ent. - лицензии пришли), 20 Гб памяти. Все x64. По-моему отсюда: "А всякие там зеркалированиялог-шиппинги научите в симпл модели восстановления настраивать?". В ответ на ваш пост о моделях восстановления. По-моему, очевидно, что речь идет о технологиях SQL Server. У меня оно работает в синхронном режиме - снижение производительности не более 3-х процентов, но зеркальный сервер по производительности очень близок к рабочему и сеть гигабитная. На случай сильного снижения производительности (или слабого зеркального сервера) есть режим "high performance". Доступен этот режим, к сожалению, только в Enterprise. Вашу иронию про басни вообще не понял..

Спасиб, за инфу по железу. К нам х64 не хватает ))

3 гига памяти - что-то совсем маловато на 70 пользователей... У меня 8 гиг на 40 пользователей, Win2008 и 1c - 64х, SQL  в Simple, архивы 4 раза в день, база маленькая Бух 8.1 - 9 гиг, SQL и 1C серверы на одной машине. И скажу, что не всегда комфортно работают - иногда док Закрытие месяца с амортизацией зависает минут на 10-15. Но чаще всего - полет нормальный. (тук тук по деревяшке :))

1C нигде официально не заявляло о возможности применения log shipping и database mirroring средствами SQL для 1С 8 Гилев также не рекомедует... Q: Уважаемы господа никто не пробовал зеркалировать базы средствами MSSql 2008 вообще это возможно ? A: Нет, рекомендую использовать штатные средства 1С:Предприятие. (Штатные - это видимо УРБД...) Т.е. только на свой страх и риск. Какие подводные камни при этом могут всплыть - пока не понятно...

ну какие подводные камни? Для 1Ски механизмы сиквела - прозначны...

Full есно. Без базара. Пр логи - растут они только у бестолковых. Все вменяемые бекапят базу.

не согласен.. базар есть.. Модель восстановления это не догма, а результат компромиса между скоростью и полнотой восстановления информации и платой за ресурсы и производительность. Знаю кучу бизнесов, где нормально, когда целостность информации нужна в пределах дня (если что, что день с первички легко всстанавливают) и тут Симпл рудит безмерно :-)

надо было голосовалку прикрутить лично я за симпл, естественно при условии, что делаются бэкапы

на этой неделе 2 базы восстановил из бэкапа по логу. Я за фулл.

деньги делаешь? Ну так... из воздуха.

- Да-да, и механизм репликации тоже прозрачен... Только вот: Можно ли организовать распределенную БД, используя возможности репликаций, имеющиеся в сервере MS-SQL Нет. Пользуйтесь механизмами создания распределенных БД, созданным специально для программы 1C Это связано с нетривиальностью хранимых в БД данных программы 1С: Предприятие и с тем, что она (программа 1С: Предприятие) контролирует целостность структуры создаваемых ею таблиц, а при установлении Merge-репликации SQL-сервера в таблицы, хранящие данные программы 1С: Предприятие, добавляется дополнительное поле - внутренний идентификатор реплицированной строки. После опубликования таблицы на репликацию программа 1С: Предприятие будет считать что база данных разрушена и откажется работать.

вот говорит что у него все работает и уже давно.

Не старайся, я с SQLщиками год работаю. Они все равно будут говорить, что средства только MS SQLя нормальные, все остальное второсортное.

говорит, что у него зеркалирование работает, а не merge-репликация. Опять-таки, думаю, что snapshot и transactional репликации вполне себе будут работать, так как не вносят изменений в структуру. Вопрос в том нужны ли они). как вы построите систему высокой доступности средставми только 1С? Никто не говорит, что ТОЛЬКО средства SQLя нормальные, но если есть возможность - почему их не использовать?

"Когда у нас один справочник случайно очистили" Если зеркалирование нужно для такого, то это нонсенс

А меня фул сильно выручал. Настроен бэкап журнала транзакций каждые полчаса. Логам разметил места, они не вырастают. А спас вот так: сворачивали чеки ККМ за день, чеки удалились, отчет о розничных продажах не записался (УПП практически без изменений). Ну так вот где чеки взять за текущий день? За 30 минут развернули копию базы и восстановили до последнего бекапа лога, закрыли там смену и через XML перекинули док в основную базу. При модели восстановления симпл такое было бы невозможно.

Короче вы не понимаете что такое зеркалирование и на кой оно нужно, но утверждаете, что оно бесполезно. В все написано - мне помогли бэкапы журнала транзакций. А чтобы не терять время в случае повторения ситуации - настроен log shipping. Зеркало мне нужно на случай проведения каких-то работ на сервере, установки сервиспаков, просто выхода из строя какой-то части рабочего сервера.

снапшотом пытался шеф настроить, блокировки немного перли, это уже минус огромный ... Нет, я не против различных решений, сам их использую вдоль и поперек, но дублирование средствами MS SQL это, как мне кажется, не правильно. Скорость падает, привязка к платформе и оси, привязка к разработчику (хотя, может он все подробно описал), неизвестно сколько глюков при различных нагрузках и т.д. и т.п. Давно уже убедился, что толпа разработчиков в 1С-е, хоть чуть-чуть, да и умнее, пусть даже мегагуру, но одного.

Мои знакомые предусмотрели варианты потери чеков в пивнушке, вместо восстановления из копии

нет, понадобилось. Админы недоглядели, и место на диске, где базы закончилось (и при этом, как всегда, в неудачный момент). Место то организовали быстро но упавшие службы SQl привели к появлению сообщения "ошибка потока" в каких-то кусках двух баз. Можно, было бы, пытаться лечить конфигуратором... на кто ж знает, в каком месте потом еще выпадение данных вылезет.   После неудачных попыток лечения типа очистки кэша  1С - оповестил народ о прискорбном событии, и пошел восстанавливать базы на момент перед сбоем.

Кластер+СКД. Я не просто так говорю. Нам ставилась мегазадача, что бы все работало 24 часа в сутках с возможностью расширения до офигенного числа пользователей. Прежде чем отказаться от зеркалирования средствами SQL мы провели далеко не одно измерение

Инитересно почему Отчет о розничных продажах не записался, все в одной транзакции происходит, походу транзакцию убрали сами ))

В общем одна половина ИТишников исправляет проблемы, другая их исключает.

Я не утверждаю, что зеркалирование работать не будет. Просто хучу предупредить, что если 1С до сих про официально не объявило о поддержке, возможно на это есть свои причины, о которых они умалчивают... ...Если есть возможность - почему их не использовать?... По этой же логике есть возможность подключаться к одной базе SQL с двух независимых серверов 1С - почему бы ее не использовать?

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

А еще добавили цепочку создания зависимых справочников, отсылки почты и вывод на печать... Такое я видел в телефонном магазине Российского масштаба

Я тоже не переубеждаю, просто высказываюсь, согласно собственному опыту. Излишество нельзя допускать при разработке больших систем. Если вещь не нужная, то её не надо пихать. Понятно, что если автомобиль ёпнется с моста, то ему надо реактивный двигатель и парашют. Хотя, может лучше сказать водителю, что бы не падал и автомобиль оставить автомобилем? Немного от сабжа, но про переделки с SQLем:

СКД - это имеется в виду СХД, правильно? Кластер хорошее решение, но весьма дорогое - windows enterprise значительно дороже standard'a. Когда делали зеркало таких лицензий не было, а сейчас после перехода на виртуальные сервера, зеркало оставили для "защиты" от выхода из строя сервера с esxi (с ними, вроде как бывают разные глюки, когда машина может тупо не запуститься). Вот такую фразу где-то прочитал и себе скопипастил: "... preventing a failure is not high availability, preventing a failure is a hope and a prayer..." Это к исключению проблем. А не надо доводить идею до абсурда. Если у меня есть возможность залить бензин АИ-76 в феррари, не значит, что я буду это делать.

в красноярске есть конторка, где все пишут напрямую в SQL. Они даже на работу одинэсников берут только с сертификатами SQL. Много лет там толпа прогов совокупляется с этими "скоростными" конфами, а конкуренты ржут, хотя объёмы у конкурентов больше

Блин... именно СХД (во всем виновата 1С). понятно, что дорогое. Когда решали что делать, нам была задача про 24 часа в сутки. Поэтому вместо сомнительного огорода, сразу поставили условие и расписали плюсы и минусы.

про автомобиль и мост. Я вижу этот процесс по-другому. Пусть мост скользкий. Так вот ежедневный бэкап - это перила моста, и бекап транзакций - это раз в 30 минут посыпать мост песочком. Естественно что если захотеть, то свалиться с моста можно в любом случае, просто в случае с Full вероятность меньше.

бэкап транзакций, это быстро-быстро вытащить машину из канавы. Скорее всего песочек, это снижение температуры железа и стабилизация питания