И снова... о производительности...

[xonix]

2 Falcon
Понимаю вас.
Попробуйте на старый сервер поставить 5-6 дисков без раида (желательно, с нормальным продвинутым контроллером) и разнести индексы, логи, темпы, данные, подкачку ОС. Залейте на него вашу базу и потестите.
Точнее даже, замерьте что и как грузится до разнесения по дискам, затем разнесите и посмотрите, увеличивается ли производительность? Если разница ощутима - то смело на поклон к руководству.

По статистике - сделайте рейтинг запросов за день (по времени выполнения). Уже будет интересно. Это пригодится и для определения чего куда разносить по разным дискам. Посмотрите планы топовых запросов. Возможно помогут хинты и доп. индексы. Но если все запросы равномерно размазаны - то конечно лечить - только тюнинговать диски. Но, думаю, вы найдёте 10-20 топовых запросов, лечение которых спасёт ситуацию раза в 2-3.

По Ораклу я бы смог сказать гораздо больше что и как делать Тюнил базы и по 80 гигов....

П.С. Надо было с майкрософта и ИБМа в письменном виде с печатями и подписями советы брать

[AKIS-Falcon]

Цитата:

Смотрим в форму заказов. По каким полям установлены фильтры при открытии заказа. Есть ли соответствующий индекс?

Никаких фильтров нет, выводится все что есть.

Цитата:

2 Falcon
Кстати, а ОС где лежит? Где её "подкачка"?
Где лежат временные файлы сиквела (где он сортировку там делает и прочую хрень)?

ОС лежит на отдельном (третьем) дисковом массиве, там же подкачка. Тока не говорите, что своп-файл надо на отдельный диск класть - это ж застрелиться, не сервер получается а фиг знает что... пять, а то и шесть дисковых массивов... При этом диски-то далеко не слабенькие, 10К (у предыдущего сервака было 7200 - все работало).

Временные файлы сиквела лежат на том же диске, что и база данных

[AKIS-Falcon]

Еще раз спасибо всем за советы!!!

Цитата:

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

Логи подрезаю регулярно. Кстати, тоже вопрос: а не лучше ли, когда у 14 ГБ базы лог хотя бы 1 Гб, а не урезанный "в ноль"? Есть ли какие-то рекоммендации по соотношению "размер базы-размер лога"? Было время, работал я с базой данных Progress - так вот там лог в ноль советовали урезать только в экстренных случаях, например при переносе базы, чтоб не тратить время на копирование "пустых" гигабайтов. По-моему, такой же подход и у оракла. А как у сиквела - не знаю...

На сервере не крутится больше ничего.

[AKIS-Falcon]

Цитата:

Понимаю вас.
Попробуйте на старый сервер поставить 5-6 дисков без раида (желательно, с нормальным продвинутым контроллером) и разнести индексы,

К сожалению, старого сервера больше нет, отправлен на пенсию обратно в ИБМ... Так что рад бы "потестить", да не на чем

[savel]

Цитата:

--------------------------------------------------------------------------------
Смотрим в форму заказов. По каким полям установлены фильтры при открытии заказа. Есть ли соответствующий индекс?
--------------------------------------------------------------------------------



Никаких фильтров нет, выводится все что есть

Теперь смотрим на заджойненые таблицы, есть ли у них соответствующие индексы.
И ещё, какие дисплей-методы работают. Если есть там запросы, есть ли там "нужные" индексы.

[xonix]

2 Falcon
Попробуйте вынести временные файлы сиквел на отдельный диск.
Однозначно попробуйте вынести индексы на отдельный диск. После посмотрите в перформанс мониторе, как юзаются диски (в смысле, у кого 100%).

[AKIS-Falcon]

Попробую, не на рабочей а на тестовой (=копия рабочей) базе.

Напишу, чего получилось.

[xonix]

Для корректности толкования:
"У кого 100%" читать как "у какого физического диска загрузка 100%"
Ждём результатов.... Конечно, слабо верится, что подобными мерами можно поднять производительнось более чем в 2 раза, но....
Скорее всего дело в "плохих" запросах - т.е. надо их искать и думать, какие индексы добавлять. В идеале, в запросах не должно быть у подчинённых таблиц FULL SCAN, а индексы должны обладать высокой селективностью. Тогда всё должно ЛЕТАТЬ

[AKIS-Falcon]

Спасибо, еще один маленький вопрос:

Решил узнать, почему все-таки такая большая база. Сделал выборку. Вот результат:

Table Name____________Rows_______Reserved, KB_Data, KB_____idx, KB______Unused, KB
NUMBERSEQUENCELIST 12,132,699.00 15,799,544.00 1,191,000.00_5,434,240.00 9,174,304.00
INVENTSETTLEMENT____13,076,341.00_8,993,192.00 1,753,208.00_6,263,688.00 976,296.00
DOCUREF_____________2,738,234.00__3,593,424.00__530,592.00_1,036,688.00 2,026,144.00
NUMBERSEQUENCETTS________-_____3,171,640.00_____-________30,688.00 3,140,952.00
TAXTRANS______________130,454.00___1,001,504.00__60,856.00___75,568.00 865,080.00

Вопрос: почему Unused space в разы больше чем data? Почему такой гиганский размер у индексов, при сравнительно небольшом числе записей (у NumberSequenceTTS их вообще 0, а индекс тем не менее 30 Мб - как так?). Может ли это влиять на перфоманс? Если да - можно ли это как-то поправить?

База, повторюсь, была "нормализована" только два дня назад, с переиндексацией, обновлением статистики и усечением размера. И вот такая, с позволения сказать, ерунда...

[Vadik]

Цитата:

Изначально опубликовано AKIS-Falcon
Спасибо, еще один маленький вопрос:

"спасибо - да" или "спасибо - нет"?

что делалось и главное - помогло или нет?

Цитата:

Вопрос: почему Unused space в разы больше чем data? Почему такой гиганский размер у индексов, при сравнительно небольшом числе записей (у NumberSequenceTTS их вообще 0, а индекс тем не менее 30 Мб - как так?).

dbcc updateusage(0) - после этого сильно результаты изменятся?

Вдогонку к предыдущим постингам: transaction log регулярно резать НЕ НАДО. В идеале событий Log file auto growth происходить не должно вообще, в реале надо стремиться к тому, чтобы их частота стремилась в рабочее время к нулю. На время расширения журнала транзакций система находится в очень неприятной позиции: все изменения (INSERT/UPDATE/DELETE) фиксировать в логе надо, но делать это невозможно, так как он (лог) на это время заблокирован. Транзакции, в которых происходят эти изменения данных, висят, блокируя при этом чтение (SELECT). Ступор

Сколько в итоге резервировать места под лог - зависит от размера БД, ее recovery model, свободного места, интенсивности модификаций и того, как часто делается его (лога) резервное копирование. Для 10-20 гигабайт БД я бы под лог отдал не менее 2.

[xonix]

2 Falcon

Так. Unused space не влияет на производительность ваще. Это просто зарезервированное место на диске. Т.о. сравнивать размер неиспользуемого пространства с используемым с точки зрения производительности смысла нет. Если места не жалко - лучше иметь этого пространства побольше и заранее.
"Нормалиизация" - это из другой оперы
Очень трудно читать вашу таблицу. Я не понимаю какие там данные.
Индекс 30 МБ при количестве записей 0 - это странно. Хотя... в МС SQL есть настройки на начальный размер данных при создании объектов БД? Сегодня-завтра дома если найду книжечку - буду давать более конкретные ответы.
На перформанс в вашем случае это влиять не может. Только на место на диске.
Пришлите нормальную табличку!

[KiselevSA]

Попробуйте изменить тип кэширования для таблиц UnitConvert и PriceDiscTable с EntireTable на Found. Посмотрите производительность после изменения

[bio_unit]

Цитата:

Изначально опубликовано KiselevSA
Попробуйте изменить тип кэширования для таблиц UnitConvert и PriceDiscTable с EntireTable на Found. Посмотрите производительность после изменения

Данный метод может помочь только 2tier и fat 3tier клиентам, а при thin 3tier с включенным entireTable таблицы кэшируются только на AOS, а на клиенте на эти же таблицы еще автоматически и foundAndEmpty кэш на уровне записей создается.

[AKIS-Falcon]

Привет еще раз xonix.

Пишу в эту ветку. То, что советовали здесь - не все, разумеется, но кое-что - пробовал. И буду пробовать еще. Пока не помогает. Диски не переставлял - пока неоткуда взять лишних... Если будут еще какие умные советы - с удовольствием послушаю.

[Serge Kotov]

Выше в ветке видел сообщение, что память используется на 50 %. Странно. А каков у вас абсолютный размер занимаемый под процесс sqlserv? И сколько всего установлено.

Для базы 14 гигов SQL Server c удовольствием съел бы оперативки и 3 GB.

[AKIS-Falcon]

Вот щас только посмотрел: всего оперативки занято 2.1 Гб, из них 1.8 кушает сиквелсервер... Времени 8 вечера, стало быть в система сейчас никого.
Всего памяти 4 Гига.
Сиквелу разрешено кушать столько, сколько он пожелает (т.к. ничего больше на этом сервере просто нету).
Да, база уже не 14 а 10 Гигов стала! Почистил я ее.

[xonix]

2 Falcon
На счёт памяти - ставьте Windows 2000 Advanced Server, ему можно по 6 гигов памяти омалачивать (сейчас максимум 2).
Это регулируется каким-то параметром в конфиге - спросите вашего админа.
Теоретически, после добивания памяти до 6 гигов (не так дорого), установки Advanced Server и выдаче сиквелу его законных 5 с копейками гигов может всё зашевелиться быстрее.. Кстати, у сиквела ести настройки, регулирующие распределение памяти под буфер данных?
Напиши, что сделал... :
-разнёс индексы на отдельный диск
-собрал статистику по самым ресурсоёмким запросам (время*кол-во запросов)
-временные файлы на отдельный диск

Есть ли возможность пересесть под Оракл?

[Serge Kotov]

При использовании AWE (Microsoft Windows Address Windowing Extensions) Windows 2000 Advanced Server поддерживает до 8 Гбайт памяти, Windows 2000 Datacenter Server поддерживает до 64 Гбайт памяти.

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

[xonix]

2 Serge Kotov
Спасибо за комментарий. Только наверно надо сказать, что из этих 8 гигов любому процессу доступно максимум 6
В любом случае, это должно работать гораздо быстрее, чем работа с диском.

[Serge Kotov]

Да ускорение ожидать можно. Мы в свое время не решились на этот вариант вследствие определенных сложностей в работе с AWE и решили проблему кардинально - перешли на IA64 c 56 GB ОЗУ. Из них 55 досталось SQL Server.