трудности перехода (на sql server 2005)

[Юрий]

Не я его только выкачал.

Мы не можем отказаться от 2000 ка так как у нас 2000 на 4 проца куплен,
а 2005 только один а тратить деньги на 2005 пока нет резона, так что работаем на 2000 ом.

[Anderyt]

Не я его только выкачал

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

[Александр]

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

[Anderyt]

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

[Александр]

покажи запрос на статистику - запущу у себя
а на счет оптимизации - структура Лоции и так идеальна (эт. комплимент разработчикам) а вот ее использование и наполнение оставляют желать лучшего...

к сожалению понимаешь это уже имея в каком либо атрибуте миллион значений и т.д. и т.п

[Anderyt]

сначала запросом

Код: Выделить всё

select OBJECT_ID(N'party.lsdbo.object_reference')

вытаскиваем код таблицы object_reference. здесь party - название БД..
потом определяем код самой базы.
это можно сделать через запрос

Код: Выделить всё

select *
from
master..sysprocesses

потом <код БД> и <код таблицы> вставляем в такой запрос:

Код: Выделить всё

SELECT * FROM sys.dm_db_index_physical_stats(<код БД>, <код таблицы>, NULL, NULL , 'DETAILED')

подробнее о том, что это такое и как понимать результаты, можно почитать вот тут - http://msdn.microsoft.com/en-us/library/ms188917.aspx
микрософт рекомендует особое внимание уделять колонке avg_fragmentation_in_percent.. типа чем меньше - тем меньше фрагментированность индекса, то есть тем лучше вообще все..

[Александр]

на счет кода самой базы

select *
from
master..sysprocesses

не совсем понятно - получается целая таблица - и что оттуда нужно взять из какой строки / столбца

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

[Anderyt]

не совсем понятно - получается целая таблица - и что оттуда нужно взять из какой строки / столбца

код базы - в колонке dbid.
только надо понять, какие из этих подключений - к базе Лоции..
можно посмотреть по колонке program_name, там должно быть partyplus..

[Александр]

получил результат
куда теперь посмотреть?

[Anderyt]

в колонку avg_fragmentation_in_percent.
там процент фрагментации.. чем меньше - тем лучше..
но там есть куча строк для индексов разных уровней, у некоторых большой процент, даже после ребилда, у некоторых - маленький..
не совсем понимаю, почему так.. возможно, есть какая то связь с колонками page_count и record_count.. может быть, индексы с небольшим числом страниц и записей плохо дефрагментируются сами по себе, и может это непринципиально, то есть фрагментированность объемного индекса намного хуже, чем небольшого..
в общем.. у меня по запросу

Код: Выделить всё

SELECT index_level, avg_fragmentation_in_percent, 
fragment_count, avg_fragment_size_in_pages, page_count   
FROM sys.dm_db_index_physical_stats(<код БД>, <код object_reference>, NULL, NULL , 'DETAILED')

получилась вот такая таблица

081225_1.GIF (10.7 КБ) 65696 просмотров

а у вас как будут эти цифры выглядеть?

[Александр]

вот так как то

[Anderyt]

ух ты! значит статистика индексов все таки может отличаться на разных базах!
у меня на тестовой базе после махинаций с разными параметрами ребилда и реорганайза получилась вот такая статистика (это все та же object_reference):

081225_2.GIF (11.04 КБ) 65675 просмотров

смотрите, какой небольшой процент в индексах с большими page_count
и еще, если в селект добавить колонку record_count, то в строках с большими page_count будут одинаковые числа в колонке record_count, которые при этом еще и совпадают с числом записей в этой таблице!
в итоге что получается... микрософт говорит, что чем меньше фрагментация в процентах - тем лучше. причем можно предположить, что фрагментация больших индексов (тех, у кого большое record_count) более серьезна, чем небольших. и кажется, что именно такие индексы более менее нормально дефрагментируются при всяких там ребилдах и реорганайзах...
микрософт говорит (в том числе вроде и в той статье), что при фрагментации меньше 30% можно ограничиться реорганайзом, а при более 30% - лучше сделать ребилд..

[Anderyt]

Александр, продолжим?
можете сделать копию базы, чтобы на ней поиграть?
и попробуйте в select в том волшебном запросе добавить record_count - какая будет картинка?
мне кажется, что у вас очень фрагментированные индексы
у вас кстати как часто происходит удаление объектов из БД? просто уж очень большой процент фрагментации (если сравнивать с нашей базой..)

[Александр]

продолжим почему нет
вот что у меня получилось

24.gif (8.05 КБ) 65661 просмотр

На счет фрагментации. Дело в том что изначально мы импортировали очень много объектов задавая индекс - вручную - т.е. все id были созданы в Excell и ушли в Лоцию.

Само удаление объектов происходит раз в месяц ~ 25 объектов

ну и естественно сам вопрос
- как сделать дефрагментацию
- как дефрагментация повлияет на атрибуты хранящие id объектов - не перезапишутся ли id существующих объектов

[Anderyt]

а, ну вот..
обратите внимание на фрагментацию в % в строках 1,4,7 и 10.
многовато, вроде..
дефрагментировать (если так можно выразиться - мне почему то кажется, микрософт в этом контексте говорит как то по другому) можно через реорганизацию или через ребилд. их можно провести в виде планов обслуживания - там есть такие пункты.
причем в вашем случае лучше именно ребилд, как считает микрософт, - процент намного больше 30.
удалиться ничего не должно. насколько я понял, индексы хранятся рядом с таблицей и они после этой процедуры просто перестроятся, станут более последовательными..
но в любом случае, чтобы потом не было мучительно больно, очень рекомендую сделать это сначала на тестовой базе. планы обслуживания вроде как не могут нанести деструктивных действий, но все таки...
судя по небольшому опыту, при настройке ребилда лучше задавать кол-во свободного места в явном виде, я ставил 10%, после этого процент фрагментации стал меньше 1 (а был больше 10)
вот как бы потом еще оценить изменение производительности...
можно по скорости получения какого то отчета, но если это будет на тестовой базе, то она скорее всего будет хуже, чем на реальной, даже без ребилда. надо дать серверу поработать с новой базой.
а можно поступить кардинально - сначала сделать бэкап реальной базы, потом провести на ней же ребилд индексов. так будет возможность откатиться назад, хотя это вряд ли понадобиться...