Добрый день.
Возникла следующая ситуация.
Совсем недавно перешел с .dbf базы на SQL. Размер базы 15ГБ.
Был куплен сервер для этого дела(SQL+сервер терминалов).
Xeon5530 x2,16ГБ оперативы.
Вначале всё было замечательно, народ работал(6 пользователей), отчеты стали быстрее формироваться, по словам бухгалтеров проводки тоже стали быстрее. Но через 1,5 недели резко упала производительность базы. Скорость проводок упала в несколько раз.С сервером ничего я не делал, никакой софт не ставил. С чем это может быть связано?
Если нужна какая то еще информация,  напишу, просто не часто задаю вопросы на форумах.

(0) ищите узкое место. подними архив той базы которую заводил и сравни

1сv7.7, SQL 2000 sp3, Windows server 2003 x64.

(0) Шринк базы делали?

1. не рекомендуется иметь на одном сервере терминальник и сиквел.
2. читай про настройку сиквел-сервера, и про его обслуживание

Нет не делал, это может помочь?

(5) Да.

А почему терминальник и SQL не стоит держать на одном сервере. Железо вроде позволяет..

Щас почитаю про шринкование.Спасибо за наводку)

(0) вам надо обновить статистику. И, желательно, накатить sp4 на sql server.

про стасистику можно поподробней?Что вы имеете ввиду?

UPDATE STATISTICS

http://msdn.microsoft.com/ru-ru/library/ms187348.aspx

(0) >> С сервером ничего я не делал

Вот в этом то и проблема ;-)
Шринкование базы, обновление статистики, перестроение индексов делать надо. Регулярно.

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

(14) шринк и обновление статистики, теоретически, можно делать во время работы пользователей. Но обе операции будут ждать очень много ресурсов - как процессора, так и дисков. Реиндексация делать во время работы пользователей ни в коем случае нельзя - когда будет перестраиваться кластерный индекс - таблица будет становиться недоступной.
Лучше все эти операции делать когда с базой никто не работает.

Понял, тогда стоит сделать по расписанию на ночь.
Я сейчас почитал, Шринковние это сжатие базы получается?

Буду пробывать всё, что вы мне посоветовали.
И я хотел бы еще узнать, как правильно делать бекапы базы SQL?
Я сделал фул Бекап, и периодически делаю бекапы лога..
Может это неправильно? Или есть более удобный или еще какой способ способ?

(17) Раз в сутки фулл, каждый час - логи. Вместе с фуллом - каталог базы.

вообще файл данных можно и не шринковать
мы шринкуем только ЛОГИ
бывает лог за неделю разрастается на размер втрое превышающий размер файла данных.

+19 потом настроили каждые 2-3 часа шринк и бэкап и забыли про это дело
только иногда net send присылает отчет об ошибках шринкования

ок, понял, у меня вот фай логов уже вырос до 13ГБ.Это уже почти размер базы.
А Шринк можно делать паралельно с работой пользвателей получается,раз вы делаете его раз в 2-3 часа, верно?

(21) мы его в заданиях настроили
да можно делать вместе с работой
правда если шринк ДАННЫХ будешь делать то база может наглухо подвиснуть

а ЛОГ файл мигом шринкуется.
а сам файл данных смысла шринковать не вижу.
ну урежешь ты его а он потом снова начнет расти
а если не урежешь то файл расти не будет пока не заполнится пустое место

ну изредка конечно стоит делать. (там еще какие то опции есть. если сказать проще то что то типа дефрагментации файла)

(17)
1. Шринкование не поможет.
2. Обновление статистики почаще (можно несколько раз в день) и реиндексация ночью - помогут.
3. Ночью - полный бекап (фулл). Бекапы лога - часто (от 5 минут до часа) - зависит от того, сколько минут работы всех пользователей Вы согласны потерять при сбое базы.

(23) ой ли (п.1) шринкование ЛОГА еще как поможет

(24) При регулярных беапах логов шринкование не только не полезно, но и вредно, так как серверу придется снова выделять простанство для роста лога, что безусловно приводит к тормозам. Лучше заранее выделить достаточное место для лога и не делать шринкование лога никогда.

(24) а чем оно поможет? странная-таки логика.. файл данных не шринковать, потому что он все равно вырастет. А файл лога шринковать, потому что он вырастает. Может лучше увеличить частоту бэкапов лога?

тут зубры бились на тему шринкования
SQL 2008: План поддержки завершается с ошибкой

При бекапе transaction Log файл получился размером меньше 1 мб, а сам _LOG файл занимает 13ГБ. Я что не понимаю, или делаю не правильно?

(28) Вы все делаете правильно. Размер лога и размер бекапа лога никак между собой не связаны.

Автор, лог базы full стоит в свойствах?

Посмотрел задание, там копировался не тот лог, но все равно размер мал 6,5мб.
val, я понял спасибо.
mishaPH, щас посмотрю.

Вот еще вопрос при бекапе логов, сам файл не должен меняться в размерах? Уменьшаться? или уменьшение Лога только шринкованием?  
И вот такой вопрос6 при записи ставить выбор на "Перезаписывать файл бекапа" или "Присоединять к файлу"?(вроде так переводится)

MishaPH, я чего то не могу понять где смотреть)

1. Сам файл не меняется при бекапе. Освобождается только место внутри файла.
2. Перезаписывать.

(33) В свойствах базы закладка Options, поле Recovery Model

да, стоит full

я вот щас почитал статьи, там написано что есть разница в какой послеовтельности запускать шринк, реиндекс,статистику, бекап.
Я понял что вначале надо делать реиндекс и статистику,потом шринк, потом бекап.
Или сначал бекап, реиндекс и статистику, шринк? Или это вообще не имеет знчения?)

(37) сначала реиндекс, потом статистика, потом шринк, потом бекап.
Потому что реиндекс переставляет страницы индекса и может освободить место.
Статистика не переставляет, но добавляет данные.
Потом шринк, чтобы для бекапа было меньше работы

Ок, понятно. Спасибо.

(38) Шринк - имеется в виду базы? Тогда не согласен. Совсем.

Если нет ежечасного бэкапа лога, то проще поставить модель simple

любовь к шринку не ясна.. просто, господа шринкующие, посмотрите эти ссылки:
http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(930)-data-file-shrink-does-not-affect-performance.aspx

http://www.sqlskills.com/BLOGS/PAUL/post/Conference-Questions-Pot-Pourri-10-Shrinking-the-database-before-taking-a-backup.aspx

(40) Это если хочется шринкать, разумеется

(38) на размер бэкапа шринк вообще не влияет. В бэкап попадают заполненные страницы данных, пустые страницы из файла данных "игнорируются"

(44) я сказал не размер, а работы :-)
Если база ужата уже, то бекап пройдёт быстрей. ИМХО.

Вообщем можно не шринковать, а делать реиндек,статистику,потом бекап. Я понял.

(45) Извините, я не правильно прочитал. Но бэкап быстрее в любом случае не пройдет :)

(38) (39)
Никогда не делайте шринк после реиндексации.
Этим Вы нивелируете весь эффект от реиндексации.
http://www.sql.ru/articles/mssql/2007/051403ExtentUsageAndBehavioursWhenUsingDBREINDEXAndSHRINKFILE.shtml

(46)
1. Реиндексация уже включает в себя обновление статистики. Поэтому повторно делать ее после реиндексации не имеет смысла.
2. Реиндексация может идти долго. При нехватке места на диске, особенно под логи, она может закончиться аварийно. Я бы на всякий случай делал бекап перед реиндексацией, чтобы иметь возможность быстро восстановить базу.

(49) Ты удивишься, но статистики бывают не только по индексам :-) И такие не обновляются при индексации.

(50) Не удивлюсь. Но влияние для 1С статистики представлений и пр., что не связано с индексами, близко к 0.
И чуть выше я рекомендовал делать обновление статистики несколько раз в день.

Места на диске хватает, с этим проблем пока нету(и не предвидится в ближайшее время).Сегодня всё попробую.

(52) Вы читали ссылку в (48)? Не делайте шринк:

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

Я понял, шринк пропускаю))

/уселся и жду итогового времени, по-ламерски, слегка охренев от обилия разных мнений/
1. Таки full или simple?
2. Таки раз в сутки шринк данных? и бэкап базы? с бєкапом файла данных (а как его узнать?)
3. Таки в каком порядке и с какой частотой шринк лога, реиндекс, бэкап лога?
4. Таки при улёте базы - как поднять-отресторить и какую копию?
прим.: и когда кого выгонять? или не выгонять можно? и - самое важное - как какое действо выглядит в терминах "запустить <???>, в нем меню: <???> -- <???>: закладка <???>: флал <???> и на кнопку <???>"

ЗЫ: и - в базу знаний!!!

(55) единого мнения быть не может. Мое такое:
1. Full - если хотите иметь возможность восстановления на любой момент времени, simple - если вам достаточно восстановления только из полного+дифференциального бэкапов
2,3. Шринк - разово, при необходимости. Шринк лога при внезапном очень большом разрастании лога (но не до минимального размера, а до обычного). Шринк файла данных при удалении оч. большого количества данных из БД (и то не обязательно). shrinkdatabase\autoshrink - никогда.
Реиндекс, дефрагментацию - в зависимости от уровня фрагментации данных. В общем случае - реиндекс раз в сутки ночью, дефрагментацию, при необходимости днем, в период минимальной загрузки.
UPDATE STATISTICS WITH FULLSCAN раз в сутки ночью. sp_updatestats несколько раз в день, при необходимости
Полный бэкап - раз в сутки перед реиндексацией. Бэкап лога - раз в час или чаще (см (23))
4. Отресторить - полный бэкап (norecovery), последний дифференциальный бэкап (если есть, тоже с norecovery), все последующие бэкапы журнала транзакций (все, кроме последнего norecovery, последний - with recovery)
Выгонять никого никогда не нужно. Но во время шринка, дефрагментации и обновления статистики велика вероятность тормозов. Во время реиндексации люди работать не смогут, поскольку при реиндексации кластерного индекса на таблице - эта таблица становится недоступной (хотя может повезти и на "заблокированную" таблицу никто не наткнется, но тормозить все может серьезно).

+(56) В целом согласен.
Замечания:
1. Если делать реиндекс каждую ночь, лог всегда будет большой. Нет смысла шринковать его. Лучше один раз посмотреть его размер после реиндекса, обрезать его и сразу сделать большим с запасом на разрастание базы (с коэффициентом 2-3). И больше не резать никогда.
2. Дефрагментация днем - конкретные тормоза у пользователей. Лучше реиндексация ночью и sp_updatestats днем (можно раз в 1-4 часа - в зависимости от нагрузки).
Как вариант, можно делать обновление статистики не для всех, а для некоторых нагруженных таблиц.
3. Шринк базы не делать никогда (см.(53)).
4. Во время реиндексации и восстановления базы пользователей выгонять.

Есть еще пара вопросов про статистику..
sp_updatestats с какими параметрами задавать?

(56)
>>>единого мнения быть не может. Мое такое:
>>>1. Full - если хотите иметь возможность восстановления
>>>на любой момент времени,
>>>simple - если вам достаточно восстановления только из
>>>полного+дифференциального бэкапов
Full не позволяет восстановить ранее  смены конфигурации с измееннием или без
изменения структуры данных. При смене конфигурации Делается принудительный шринк лога.
При делании бекапов тем или иным способом (может и прописная истина)
обязательно делайте копию md b dds.

Шринк данных - никогда. это событие можно приравныть к какой-то аварийной ситуации

>>>UPDATE STATISTICS WITH FULLSCAN раз в сутки ночью.
У меня ночью полная переиндексация индексов.
После переиндексации делать UPDATE STATISTICS WITH FULLSCAN бесмысленно и вредно
потому что занимаем на это время и статистика может даже ухкдшиться после переиндексации.

(57)
>>>4. Во время реиндексации  базы пользователей выгонять
необязательно. Если в сесиии нет открытых курсоров на изменяемый индекс
то реиндексация эту сесию не задевает если есть открытый курсой то этот процесс сам вылетит.

(57)
>>>1. Если делать реиндекс каждую ночь, лог всегда будет большой.
>>>Нет смысла шринковать его.
>>>Лучше один раз посмотреть его размер после реиндекса, обрезать его
>>> и сразу сделать большим с запасом на разрастание базы (с коэффициентом 2-3).
>>> И больше не резать никогда1.
Это верно если у Вас модель full.

Для модели simple чем меньше размер log фала тем лучше. Более малый размер
влечет меньшее число виртуальных журналов а следовтельно меньшее время для
поиска и добавления новой информации в журнал трнзакций.

Ну и еще приращения лог и данных ставьте всегда числом (независимо от модели ) а не процентом.
процент плохо тем что "плывет" от размера и на вычисление
конкретного приращения это тратиться больше времени.

(59) Про бэкапы - да, точно, семерка жеж.. А про шринк я как бы и писал, что это разовое и совершенно необязательное действо.
(60) Есть еще статистика создаваемая SQL Server'ом автоматически. Она не обновляется во время реиндексации. И статистика (если она выполняется с WITH FULLSCAN) НЕ МОЖЕТ ухудшиться после реиндекскации.
Хотя согласен в том, что если делается полная реиндексация - необходимость в обновлении статистики гораздо меньше. Я про нее написал скорее потому, что у меня нет ночью реиндексации для всех таблиц, а только дефрагментация\перестройка индексов по индексам с высоким уровнем фрагментации - в этом случае обновление статистики очень желательно.

(63)
>>>Она не обновляется во время реиндексации.
>>>И статистика (если она выполняется с WITH FULLSCAN) НЕ МОЖЕТ ухудшиться после реиндекскации.
Я считаю что Ваше утверждение не правильное сполрить здесь не буду.
к этому мнению я пришел из чтения форума sql.ru.
Если для Вас принципиальный ответ на этот вопрос лучше создать по этому вопросу
ветку на sql.ru там ответят более грамотно чем я.

И еще обратите внмание что некоторые индексы настолько "корявы"
( неправильная архитектура данных ) что они становяться сразу
сильно дефрагментированными даже сразу после пиереиндексации.
У самого в базе всего один такой индекс  но не могу от него избавиться в силу специфики задачи. Проверьте это на своих бд

(64) хорошо, давайте не будем спорить здесь. Только уточним терминологию - что с Вашей точки зрния "ухудшится"? Я предполагаю, что это будет первый же вопрос на sql.ru :)
(65) Да у меня тоже такие есть - быстро становятся фрагментированными.. Но переделать их тоже не могу. Хотя и сканов по ним нет, так что фрагментация не сильно мешает.

(63)>>>Я про нее написал скорее потому, что у меня нет ночью реиндексации для
>>>всех таблиц, а только дефрагментация\
>>>перестройка индексов по индексам с высоким уровнем фрагментации
>>> - в этом случае обновление статистики очень желательно

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

(66)
>>>хорошо, давайте не будем спорить здесь.
>>>Только уточним терминологию - что с Вашей точки зрния "ухудшится"?
Я считаю что при пеериндексации статистика пересоздается.
При выполнении update statictic sql  не так строго просматривает индексы
(из за ограничености своих ресурсов по времени ) как при переиндексации
а так как он просмматривает индексы не так тщательно то его обновление статистики может быть хуже чем сделаное при переиндексировании.

(67) В моем случае речеь идет не про полную, а про выборочную дефрагментацию. Если "уровень" фрагментации в индексе 5-30 процентов - дефрагментирую, больше 30 - перестраиваю.
(68) Вы заблуждаетесь :). Я-таки не буду создавать тему на скуле, лучше процитирую бол:
"FULLSCAN
Вычисляет статистику путем просмотра всех строк в таблице или индексированном представлении. FULLSCAN и SAMPLE 100 PERCENT имеют одинаковые результаты. FULLSCAN не может быть использован с параметром SAMPLE
"(русская версия к 2008-му серверу)
"FULLSCAN
Specifies that all rows in table or view should be read to gather the statistics. FULLSCAN provides the same behavior as SAMPLE 100 PERCENT. FULLSCAN cannot be used with the SAMPLE option." (англ. к 2000-му)
Статистика обновляется одинаково, другое дело, что вся статистика, кроме созданной автоматически, уже будет обновлена, так что можно сказать, что в случае полной реиндексации сервер будет выполнять много лишней работы. Но ухудшить статистику он не в состоянии.
Сорри, это, наверное, похоже на то что я все-таки начал спорить, но это не так, я просто подтвердил свое мнение. Пусть каждый останется при своем :).

(69)
>>>FULLSCAN
>>>Specifies that all rows in table

Из этого не вытекает что просматриваются полностью все таблицы индексов.
а по индексам также строится статистика.
А при перестроении всех индексов sql все индексы и просматриваются и перестраиваются.

(70) Я опять не согласен:). Тут уже другой вопрос, в таком случае ставится - "Что такое статистика".
"When you create an index, the query optimizer automatically stores statistical information about the indexed columns." (это из статьи Index Statistics к 2005-му серверу
"CREATE INDEX generates the declared index in the first place, and then as a byproduct creates one set of statistics for the column combination constituting the index" (это к 2000-му).
Т.е. "статистика по индексу" - это статистика по тем столбцам таблицы, по которым строится индекс. И для обновления этой статистики SQL Server будет (как я это понимаю) сканировать нужный индекс (а даже если и будет сканировать всю таблицу - это ничего не меняет).

букмарк

ван мо букмарк

всем добрый день)
Вообщем тему я начал с того, что у меня тормозит провдение накладных. Обратил внимаие, что чем дольше идет проведение, тем медленнее. Вот например, началась проводка док-тов в 19:00, нужно обработать 2 месяца. Первые 5-10 дней обрабатываются примерно по 30 мин, постепенно увеличивая время, в итоге к утру проводился 23 день. И вот он проводился 2,5 часа, и потом обработку просто остановили. С чем это связано? Так и должно быть или с этим можно как то бороться?

Кстати, я попробовал делать реиндесацию.Дефрагментацию и шринк базы и логов не делал. Обновил еще и статистику с помощью команды sp_updatestat.
стало получше, но было быстрее...

(74) SQL2000? плюс конфа наверное ТиС или Комплекс. так?

(74) известный баг

кстати в скуле 2005 он пофиксен?

(74) Это патентованный косяк 2000 скуля. Почитай про метод ReconnectNative() из 1с++.dll

почитал, интересно. Вполне возможно что это поможет...
Попробую, отпишусь.

(79) Всегда помогало. Но помни про открытые курсоры. В т.ч. и в глобальнике.
Лучше сделать для перепроведения отдельного пользователя. И в ПриНачалеРаботыСистемы в самом начале для этого пользователя сразу запускать перепроведение. Тогда точно будешь знать, какие курсоры закрыть перед ReconnectNative.

а в SQL 2005 этот баг остался? И есть ли преимущества 2005 Скула перед 2000?

(81)

(81) в ms sql 2005  этого  бага  нет.
преимущества ms sq2005  перед sql2000 есть.
Но не все их можно использовать в базах 1с77 sql.

(83): новые баги (в части работы с 1с в том числе и в особенности) - тоже есть?..

(84) Самый извесный баг под связкой 1с sql2005 что
вместо
ВыбратьПодчиненныеДокументы - надо использовать прямой запрос.
Если открываете стандартный журнал подчиненных документов то обязательно устанавливайте интервал дат.

(85): 1) слишком много где менять; 2) ВК не катит.
и чо делать в таком случае?

Ясно.
Значит пора переходить на SSD и переписывать сложные запросы. В частности, надо добиваться именно Index Seek (а не Table scan), избегать page split и делать выравнивание extent'ов (копать структуры GAM, SGAM, IAM), налаживать Log shipping....