Здравствуйте, AC1D, Вы писали:
ACD>Добрый день.
ACD>У нас есть программа некая программа в которой храняться данные по работе всей компании. Структура бд, организовано не грамотно. грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов.
что-то ерунда какая-то. при чем тут "одна таблица". А сколько их должно быть? 7.5млн — это мало даже для десктопа.
ACD>И все отчеты завязаны на ней. Т.е при вызове одного(любого!) отчета тормозится вся работа с программой.
Оракл — версионник. По этому вставка (тем более 300 строк) не должна сильно влиять на конкурентное чтение.
Если конечно кто-то не додумался воткнуть блокировки (но этому индексы никак не помогут)
ACD>Разработчики советуют типа делать пересчет индексов каждую неделю причем для всей бд!!! ACD> ACD> Данных за день не так много. 300 записей в среднем в эту таблицу.
Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных?
ACD> Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
Смысл есть: для ребалансировки дерева, для того, чтобы вернуть свободное место.
Более подробно Том рассказывал: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112
ACD> Данных за день не так много. 300 записей в среднем в эту таблицу. Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
это актуально для средних и больших баз, которые не влезают в оперативку и работа постоянно идет с диском.
для маленьких баз, как у тебя, особого смысла не имеет
On 18.04.2011 8:16, AC1D wrote: > > Разработчики советуют типа делать пересчет индексов каждую неделю причем для > всей бд!!!
Это очень тупой совет. Нужно разбираться с БД вашей, может быть перестройка
индексов вовсе и не нужна.
Вообще перестройка индексов делает эффективно две вещи:
-- немного оптимизирует физическую структуру индекса, он после этого занимает
немного меньше места и физически читается немного быстрее. Эффект от этого очень
сильно зависит от БД и операций в ней, например, если изменений и удалений в БД
нет, и fillfactor-ы настроены хорошо, то эффект от операции будет нулевой.
-- делает неявно update statistics, собирает новую статистику. Статистику
можно update-ить и отдельно от перестройки индексов, это и быстрее, и не
требует на долгое время блокировать таблицу от всех операций.
On 18.04.2011 15:34, AC1D wrote:
> ACD>> Данных за день не так много. 300 записей в среднем в эту таблицу. > O>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных? > ммм. непонял? каков что?
Объём, процен от уже существующих данных (по-видимому).
> кстати там сказано, что в некоторых случаях перестройка индекса не полезна.. в > каких я не понял. можете пояснить?
В тех случаях, когда она не помогает ничему. Далеко не всегда перестройка
индекса что-то в индексе улучшает (сжимает индекс). А процесс ДОЛГИЙ и
МОНОПОЛЬНЫЙ (блокирует таблицу на время построения индекса).
К тому же он ещё жрёт ресурсы сервера во время построения индекса,
немалые в общем-то.
Здравствуйте, AC1D, Вы писали:
ACD>Здравствуйте, octo47, Вы писали:
O>>Если конечно кто-то не додумался воткнуть блокировки (но этому индексы никак не помогут) ACD>Да. в некоторых отчетах, есть блокировки.
Ну так ССЗБ. При наличии транзакций необходимость блокировки для _read only_ операция
типа отчетов ну очень сомнительна.
ACD>>> Данных за день не так много. 300 записей в среднем в эту таблицу. O>>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных? ACD>ммм. непонял? каков что?
Размер.
O>>Смысл есть: для ребалансировки дерева, для того, чтобы вернуть свободное место. O>>Более подробно Том рассказывал: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112 ACD>кстати там сказано, что в некоторых случаях перестройка индекса не полезна.. в каких я не понял. можете пояснить?
1. нужно место 2х от размера индекса
2. блокировка таблицы
3. изменится статистика -> планы могут "внезапно" изменится
On 18.04.2011 08:16, AC1D wrote:
> У нас есть программа некая программа в которой храняться данные по работе всей компании. Структура бд, организовано не грамотно. грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов. > И все отчеты завязаны на ней. Т.е при вызове одного(любого!) отчета тормозится вся работа с программой. > > Разработчики советуют типа делать пересчет индексов каждую неделю причем для всей бд!!!
Поставить вторую БД, настроить репликацию с первой на вторую. Отчеты
делать только со второй.
У нас есть программа некая программа в которой храняться данные по работе всей компании. Структура бд, организовано не грамотно. грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов.
И все отчеты завязаны на ней. Т.е при вызове одного(любого!) отчета тормозится вся работа с программой.
Разработчики советуют типа делать пересчет индексов каждую неделю причем для всей бд!!!
Данных за день не так много. 300 записей в среднем в эту таблицу. Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
Oracle 9
... << RSDN@Home 1.2.0 alpha 4 rev. 1481>>
Re: ПЕРЕСТРОЙКА (индексов)
От:
Аноним
Дата:
18.04.11 05:26
Оценка:
Здравствуйте, AC1D, Вы писали:
ACD>Структура бд, организовано не грамотно.грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов. ACD> Данных за день не так много. 300 записей в среднем в эту таблицу. Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
Вряд ли вы можете судить о грамотности организации БД, если не в курсе про перестройку индексов. Как бы рано вам наверно так самоуверенно оценивать квалификацию других людей.
Смысл тут и везде много раз обсуждался (причин несколько, основная — в фрагментации при вставке данных в середину индекса), а для всей БД вместо одной таблицы, потому что, если грубо говоря есть одна таблица, то грубо говоря, это одно и то же, а хуже в любом случае не будет .
Здравствуйте, MasterZiv, Вы писали:
MZ>On 18.04.2011 8:16, AC1D wrote: >> >> Разработчики советуют типа делать пересчет индексов каждую неделю причем для >> всей бд!!!
MZ>Это очень тупой совет. Нужно разбираться с БД вашей, может быть перестройка MZ>индексов вовсе и не нужна.
Разработчики не хотят разбираться. По этому только дают советы)
Здравствуйте, octo47, Вы писали:
O>что-то ерунда какая-то. при чем тут "одна таблица". А сколько их должно быть? 7.5млн — это мало даже для десктопа.
таблиц много. просто большинство отчетов завязаны на ней.
O>Если конечно кто-то не додумался воткнуть блокировки (но этому индексы никак не помогут)
Да. в некоторых отчетах, есть блокировки.
ACD>> Данных за день не так много. 300 записей в среднем в эту таблицу. O>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных?
ммм. непонял? каков что?
O>Смысл есть: для ребалансировки дерева, для того, чтобы вернуть свободное место. O>Более подробно Том рассказывал: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:2913600659112
кстати там сказано, что в некоторых случаях перестройка индекса не полезна.. в каких я не понял. можете пояснить?
Здравствуйте, <Аноним>, Вы писали:
А>Вряд ли вы можете судить о грамотности организации БД, если не в курсе про перестройку индексов. Как бы рано вам наверно так самоуверенно оценивать квалификацию других людей.
Ну может вы ответите тогда: как повлияет перестройка индекса на таблицы которые не используются и на таблицы из которых происходит полная выборка?
А>Смысл тут и везде много раз обсуждался (причин несколько, основная — в фрагментации при вставке данных в середину индекса), а для всей БД вместо одной таблицы, потому что, если грубо говоря есть одна таблица, то грубо говоря, это одно и то же, а хуже в любом случае не будет .
Посмотрите ссылку которую привел octo47 , там написано что перестройка может и навредить..
On 18.04.2011 15:34, AC1D wrote:
> MZ>Это очень тупой совет. Нужно разбираться с БД вашей, может быть перестройка > MZ>индексов вовсе и не нужна. > > Разработчики не хотят разбираться. По этому только дают советы)
Здравствуйте, octo47, Вы писали:
ACD>>Да. в некоторых отчетах, есть блокировки. O>Ну так ССЗБ. При наличии транзакций необходимость блокировки для _read only_ операция O>типа отчетов ну очень сомнительна.
Есть отчет считающий остатки. Он делает полную выборку по этой здоровой таблице, складывает, считает. Вообщем когда его запускают можно идти пить чай. Если кто-то другой вносил в таблицу какие-то изменения, то отчет выдавал неверные данные.. поэтому они сделали блокировки в отчете.. слава богу это нужно делать раз в месяц)
ACD>>>> Данных за день не так много. 300 записей в среднем в эту таблицу. O>>>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных? ACD>>ммм. непонял? каков что? O>Размер.
1 запись 1-5 кб. Просто ручками в базу вбивается там новые сделки и т.д.
Здравствуйте, AC1D, Вы писали:
ACD>Разработчики не хотят разбираться. По этому только дают советы)
Печально, хоть и часто встречается.
У них перед вами есть какие-то обязательства? Если нет, то начальство ваше само себя в яму загнало. Меняйте их поскорее (сами решите кого :).
А если есть, то ставьте им задачу не "разобраться с индексами", а "чтобы вот этот отчет получался за 5 минут" (или сколько там вас устроит).
Здравствуйте, AC1D, Вы писали:
ACD>Если кто-то другой вносил в таблицу какие-то изменения, то отчет выдавал неверные данные.. поэтому они сделали блокировки в отчете..
Прелестно! :)
С большой вероятностью проблема производительности отчетов кроется не в индексах, а в этих самых блокировках.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, AC1D, Вы писали:
ACD>>Разработчики не хотят разбираться. По этому только дают советы)
W>Печально, хоть и часто встречается. W>У них перед вами есть какие-то обязательства? Если нет, то начальство ваше само себя в яму загнало. Меняйте их поскорее (сами решите кого .
да уже в яме. есть только обязательство тех. поддержки. юристы в свое время пролетели, не каких обязательств у компании нет..
и уже думаю)) W>А если есть, то ставьте им задачу не "разобраться с индексами", а "чтобы вот этот отчет получался за 5 минут" (или сколько там вас устроит).
Я уже перебуилдил индексы во всей базе. Нехрена не изменилось)
Задача как раз так и ставиться. Отчет работает медлено, надо ускорить)
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, AC1D, Вы писали:
ACD>>Если кто-то другой вносил в таблицу какие-то изменения, то отчет выдавал неверные данные.. поэтому они сделали блокировки в отчете..
W>Прелестно! W>С большой вероятностью проблема производительности отчетов кроется не в индексах, а в этих самых блокировках. он запускается раз в месяц. в остальных отчетах вроде блокировок нету.
Там более 50 отчетов разных.
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, AC1D, Вы писали:
ACD>>Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
W>Смысл простой. Вам будет чем заняться, и вы отстанете от разработчиков.
не всё так просто)) те пользователи которые работают с программой, отсылают отчеты начальству.
Я вот жду когда же очередной раз они не успеют и начнется скандал, потому как мое начальство и начальсво разработчиков инертно.. Оракл они не хотят обновлять на новый, сервер не хотят обновлять, кардинально структуру менять не хотят, разбивать базу не хотят, разбираться не хотят .. вообщем ждем..
On 19.04.2011 14:12, AC1D wrote:
> Оракл они не хотят обновлять > на новый, сервер не хотят обновлять, кардинально структуру менять не хотят, > разбивать базу не хотят, разбираться не хотят .. вообщем ждем..
Я вас хочу немного разочаровать -- часто это всё для более быстрой работы
отчётов не помогает.
Здравствуйте, MasterZiv, Вы писали:
MZ>On 19.04.2011 14:12, AC1D wrote:
>> Оракл они не хотят обновлять >> на новый, сервер не хотят обновлять, кардинально структуру менять не хотят, >> разбивать базу не хотят, разбираться не хотят .. вообщем ждем..
MZ>Я вас хочу немного разочаровать -- часто это всё для более быстрой работы MZ>отчётов не помогает.
Я согласен, если не разбираться, где узкие места, это в основном стрельба из пушки по воробьям. Разбираться не кто не хочет. Пинок начальства даст новый импульс в борьбе добра со злом.. И надеюсь он будет довольно сильный.
Вообще моя позиция такова, я хочу отказаться от этой программы..
Здравствуйте, AC1D, Вы писали:
ACD>Здравствуйте, octo47, Вы писали:
ACD>>>Да. в некоторых отчетах, есть блокировки. O>>Ну так ССЗБ. При наличии транзакций необходимость блокировки для _read only_ операция O>>типа отчетов ну очень сомнительна.
ACD>Есть отчет считающий остатки. Он делает полную выборку по этой здоровой таблице, складывает, считает. Вообщем когда его запускают можно идти пить чай. Если кто-то другой вносил в таблицу какие-то изменения, то отчет выдавал неверные данные.. поэтому они сделали блокировки в отчете.. слава богу это нужно делать раз в месяц)
Ну так делайте его ночью. По расписанию.
ACD>>>>> Данных за день не так много. 300 записей в среднем в эту таблицу. O>>>>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных? ACD>>>ммм. непонял? каков что? O>>Размер. ACD>1 запись 1-5 кб. Просто ручками в базу вбивается там новые сделки и т.д.
Ну ради 10Мб данных индексы точно не стоит перестраивать .
O>Ну так делайте его ночью. По расписанию.
его ставят на ночь. но это не вариант. дальше данных станет больше, и придеться все отчеты ставить на ночь..
O>Ну ради 10Мб данных индексы точно не стоит перестраивать .
да это явно был перебор.
Здравствуйте, FantomGood, Вы писали:
FG>Здравствуйте, AC1D, Вы писали: FG>есть возможность почистить данные? удалить старые данные, если есть такая возможность(сделав перед этим бекап)
Нет. Вообще мы хотели разбить таблицу по годам. т.е оставить данные за 2008-2010 год в старой базе.
Для этого нужно было посчитать остатки, остатки посчитали, но дальше этого дело не пошло.
Сегодня разговаривал с начальником на эту тему, он типа сказал что это моя головная боль..
И типа я (начальник) этим буду теперь заниматься.. Ага как же..
... << RSDN@Home 1.2.0 alpha 4 rev. 1481>>
Re[3]: ПЕРЕСТРОЙКА (индексов)
От:
Аноним
Дата:
21.04.11 21:04
Оценка:
Здравствуйте, AC1D, Вы писали:
ACD>Здравствуйте, FantomGood, Вы писали:
FG>>Здравствуйте, AC1D, Вы писали: FG>>есть возможность почистить данные? удалить старые данные, если есть такая возможность(сделав перед этим бекап) ACD>Нет. Вообще мы хотели разбить таблицу по годам. т.е оставить данные за 2008-2010 год в старой базе. ACD>Для этого нужно было посчитать остатки, остатки посчитали, но дальше этого дело не пошло. ACD>Сегодня разговаривал с начальником на эту тему, он типа сказал что это моя головная боль.. ACD>И типа я (начальник) этим буду теперь заниматься.. Ага как же..
— да подход "наш" ты ответственнен, сам разбирайся
— перестройка неизвестных индексов на неизвестной большой таблице, с неизвесными запросами — очень продуктивное занятие .
Ближе к делу
1)при формировании отчетов, индексы вообще могут не использоваться, а идет сканирование таблицы.
2) нужно смотреть отчеты, статистику и попробывать или передалить индексы или добавить необходимые
3) если различные варианты индексов не помогут можно побаловаться с секционированием таблицы, а для отчетов прикрутить материализированые вьюшки(если нет интенсивного ввода данных), вроде бы 9 оракл позволяет их создавать
Здравствуйте, AC1D, Вы писали:
ACD>Добрый день.
ACD>У нас есть программа некая программа в которой храняться данные по работе всей компании. Структура бд, организовано не грамотно. грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов. ACD>И все отчеты завязаны на ней. Т.е при вызове одного(любого!) отчета тормозится вся работа с программой.
ACD>Разработчики советуют типа делать пересчет индексов каждую неделю причем для всей бд!!!
ACD> ACD> Данных за день не так много. 300 записей в среднем в эту таблицу. Может мне кто-нибудь объяснить смысл перестройки индексов тем более для всей бд?
ACD>Oracle 9
Возможно они предпологали, что у вас автогенерируемые первичные ключи в базе,т.е. Id поле базы автоматически генерирутся через сиквенс/автоинкремент. В обоих этих случаях транзакции могут отменяться, поля могут удаляться, и в базе имеются пропуски между первичными ключами имеющими значение например 1 и 21. И в несжатом виде максимальный элемент 20000000. Если ужать то будет например всего 100000.Сервер Oracle (и других бд) динамически выделяет данные под типы, т.е. под число 1 выделит меньше памяти чем под 20000000. И соответственно медленнее перебирает данные.А индексация сделает так чтобы между значениями первичного ключа(или других суррогатных полей) не было пропусков, и все работало быстрее.
Здравствуйте, AC1D, Вы писали:
ACD>Я уже перебуилдил индексы во всей базе. Нехрена не изменилось) ACD>Задача как раз так и ставиться. Отчет работает медлено, надо ускорить)
Ну тогда приступай к оптимизации. Попробуй план запроса посмотреть, что тормозит выделить.
Если план не состраивается, разделяй скрипт на запросы и смотри их план и скорость.
Поищи идусский код, мне это в 70% помогало оптимизировать запрос.
Короче, крутись, делай что-то. Поможем, чем сможем.
Наука изощряет ум; ученье вострит память.
(c) Козьма Прутков
Здравствуйте, wolfstain3d, Вы писали:
W>А индексация сделает так чтобы между значениями первичного ключа(или других суррогатных полей) не было пропусков, и все работало быстрее.
Здравствуйте, ZAMUNDA, Вы писали:
ZAM>Здравствуйте, AC1D, Вы писали:
ACD>>Я уже перебуилдил индексы во всей базе. Нехрена не изменилось) ACD>>Задача как раз так и ставиться. Отчет работает медлено, надо ускорить) ZAM>Ну тогда приступай к оптимизации. Попробуй план запроса посмотреть, что тормозит выделить. ZAM>Если план не состраивается, разделяй скрипт на запросы и смотри их план и скорость. ZAM>Поищи идусский код, мне это в 70% помогало оптимизировать запрос.
ZAM>Короче, крутись, делай что-то. Поможем, чем сможем.
Я же писал что меня отстранили) Сказали типа оптимизацией занимаюсь теперь я (начальник) , ну и естественно всё висит как и висело)
Сегодня начальник разговаривал о скорости какого-то отчета, типа они оптимизировали и он стал АЖ(!) 40 минут формироваться , его спрашивают, а нельзяли 15 минут сделать. Он грит нельзя...
В базу я лезть не хочу, потом на меня всех собак и вывесят.. Да и у меня другая работа)
Не вижу смысла делать их работу, в ущерб своей работе, тем более когда сказали не лезь)) Да индуский код наверно будет почище чем их))
Спасибо за преложеную помощь)
Здравствуйте, wolfstain3d, Вы писали:
W>Возможно они предпологали, что у вас автогенерируемые первичные ключи в базе,т.е. Id поле базы автоматически генерирутся через сиквенс/автоинкремент. В обоих этих случаях транзакции могут отменяться, поля могут удаляться, и в базе имеются пропуски между первичными ключами имеющими значение например 1 и 21. И в несжатом виде максимальный элемент 20000000. Если ужать то будет например всего 100000.Сервер Oracle (и других бд) динамически выделяет данные под типы, т.е. под число 1 выделит меньше памяти чем под 20000000. И соответственно медленнее перебирает данные.А индексация сделает так чтобы между значениями первичного ключа(или других суррогатных полей) не было пропусков, и все работало быстрее.
Это их база. они ПРЕКРАСНО знают что там нужно оптимизировать, просто не хотят это делать по тому как дешевле и быстрее все время чинить и получать за это деньги, чем сделать один раз нормально. А рычагов давления у нас нет. Из базы практически нечего не удаляется, т.е просто идет накопление данных.
Дело не в индексах и обновлении статистика,а как кто-то сказал чтобы бы мы от них отстали..
.
он запускается раз в месяц. в остальных отчетах вроде блокировок нету.
