Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Новичнам будет полезно, спасибо за статью.
Вообще было бы круто добавить в статью, как сделать все то же самое 5 строчками на TSQL, а еще лучше просто засунуть их в джобу агента, сделать SCRIPT — CREATE TO… и выложить сюда код создания джобы.
Вообще было бы круто добавить в статью, как сделать все то же самое 5 строчками на TSQL, а еще лучше просто засунуть их в джобу агента, сделать SCRIPT — CREATE TO… и выложить сюда код создания джобы.
Я понимаю, зачем нужна была частая перестройка индексов в БД типа dBase и 1С в бессерверную эпоху. Но зачем столь частое — еженедельное! — перестроение индексов у базы MS SQL Server — этого я не понимаю. Объясните.
Данные получены эмпирическим путем, на протяжении почти 5 лет работаю с 1С. Наблюдая за скоростью работы 1С и частотой перестроения индексов вывел оптимальную на мой взгляд цифру. Ее же рекомендуют на курсах для администраторов в самой 1С.
Каждый день? Я вот тоже слежу за индексами, и поверьте, даже при круглосуточной работе 100-150 пользователей, ежедневная дефрагментация излишня.
Что ж, хочу еще раз подчеркнуть, что это лишь мое виденье ситуации через призму курсов пройденных в самой 1С. Ежедневная реорганизация, а не полное перестроение индекса. С перестроением было бы действительно перебор.
т.е. на уровень фрагментации не смотрим, в любом случае реорганизация? А если индекс сильно фрагментирован?
Согласен, возможно мой вариант не идеален. С удовольствием выслушаю Ваш вариант и все предложения.
habrahabr.ru/post/155933/
Правда к этому еще добавилось пару плюшек, например за индексами я веду отдельную слежку, собирая инфо по ним дважды в сутки, и сами индексы дефрагментируются в зависимости от того, насколько интенсивно они используются и фрагментируются
Правда к этому еще добавилось пару плюшек, например за индексами я веду отдельную слежку, собирая инфо по ним дважды в сутки, и сами индексы дефрагментируются в зависимости от того, насколько интенсивно они используются и фрагментируются
Отдельно хочу сказать про резервное копирование, зачем делать full backup каждый день? Конечно, если база весит 5-7 гигов, и бэкапы сжимать, то ладно, но что если база весит 100-300 Гб? Каждый день по 30 гигов бэкап, за месяц терабайт места только для резервных копий.
И еще момент, сколько данных вы готовы потерять? в вашем случае, в худшем варианте вы теряете данные за целый рабочий день. Я рекомендую делать так, раз в неделю full, каждый день differential, и каждый час (у меня каждые 30 минут, тут зависит от того сколько данных вы готовы потерять) бэкап логов, бэкап логов делается быстро, пользователи даже жаловаться не успевают :)
И еще момент, сколько данных вы готовы потерять? в вашем случае, в худшем варианте вы теряете данные за целый рабочий день. Я рекомендую делать так, раз в неделю full, каждый день differential, и каждый час (у меня каждые 30 минут, тут зависит от того сколько данных вы готовы потерять) бэкап логов, бэкап логов делается быстро, пользователи даже жаловаться не успевают :)
Подчеркиваю, это применимо только к небольшим базам, МАКСИМУМ 100 Гб (и то пожалуй уже выходит за рамки). Так же хочу обратить Ваше внимание, что я и рекомендовал делать бэкап полный — в недельном мэйнтенсе, и ежедневно разностный. Бэкап логов не применим. Во первых сама 1С об этом говорит, во вторых в моем варианте база работает с простым типом восстановления.
Значит я не блеснул внимательностью, но по поводу применимости бэкапа логов готов спорить, опытным путем установлено что это необходимая мера, и к тому-же в 1С как правило важна сохраность данных, так что модель simple ИМХО не самый лучший вариант, неужели все так печально с быстродействием?
Я всего лишь стараюсь донести до таких же новичков как я знания, которые удалось получить на личном примере. Я не DBA и даже в этом направлении не учусь. Я опирался на данные из best practice 1С и эмпирически полученных в ходе работы. Бэкап лога очень не рекомендовали. Использование «полного» типа снижало производительность.
разумеется снижало, но насколько это было критично, и чем они мотивировали свою рекомендацию не делать бэкап логов?
Вот бы что-то такое же, но по PostgreSQL.
Насчет 1С, в общем они ориентируются на MS SQL, Oracle — продукт коммерческий, и еще воевать и на что-то давить в 1с пытается. PostgreSQL защищать некому. В общем глюков я с PostgreSQL натерпелся в свое время у нескольких клиентов. Но на Linux это самый оптимальный вариант. Рад буду посодействовать чем смогу авторам статьи по Postgre
А мне как полному нубу-новичку подскажите: чем поможет проведение сбора статистики ПОСЛЕ перестроения индекса? Без шуток и иронии, раз уж статья для новичков, разъясните..? Да и перед зачем в таком случае делать, если Вы каждый день реиндексируете базу… Или сбор статистики нужен для переиндексации вообще и в целом? На основании данных статистики оно строит индексы? А сам MSSQL сервер не собирает статистику в автоматическом режиме?
И ещё: правильно я понимаю, что сбор статистики нужен только для перестроения индекса? И для реорганизации уже существующего индекса статистика безполезна?
Вы под сбором статистики имеете в виду обновление статистики? Если нет, то ниже можете не читать :)
Обновление статистики после перестроения индексов имеет смысл, поскольку при этом обновится автоматически созданная статистика.
Статистика, вообще, нужна оптимизатору для построения плана выполнения запроса. При дефрагментации/перестроении она не играет роли. Выбор index scan/index seek в плане выполнения, если упрощённо, зависит от количества записей в таблице и от предполагаемого результата запроса. Т.е. если вы из таблицы, содержащей 15 миллионов строк хотите получить всего 1 строку — логично использовать index seek. Если же вам нужно будет получить 10 миллионов строк, будет оправдано использование index/table scan'a. Вот для того чтобы понять сколько строк вернётся запросом и используется статистика.
Обновление статистики после перестроения индексов имеет смысл, поскольку при этом обновится автоматически созданная статистика.
Статистика, вообще, нужна оптимизатору для построения плана выполнения запроса. При дефрагментации/перестроении она не играет роли. Выбор index scan/index seek в плане выполнения, если упрощённо, зависит от количества записей в таблице и от предполагаемого результата запроса. Т.е. если вы из таблицы, содержащей 15 миллионов строк хотите получить всего 1 строку — логично использовать index seek. Если же вам нужно будет получить 10 миллионов строк, будет оправдано использование index/table scan'a. Вот для того чтобы понять сколько строк вернётся запросом и используется статистика.
dbcc proccache
вот на картинке правильно, а в описании нет.
Более того, dbcc freeproccache очищает кэш во всех базах данных, а если мы выполняем данный план для определенных баз, то и кэш чистить лучше для отдельных баз
DBCC FLUSHPROCINDB(<database_id>)
Чтобы узнать database_id используем
select name, database_id from sys.databases
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Составление планов обслуживания SQL для нужд 1С: Предприятия 8.х