сколько-ж у вас отчеты считаются, что можно не успеть

Здравствуйте, AC1D, Вы писали:

ACD>Здравствуйте, octo47, Вы писали:

ACD>>>Да. в некоторых отчетах, есть блокировки.
O>>Ну так ССЗБ. При наличии транзакций необходимость блокировки для _read only_ операция
O>>типа отчетов ну очень сомнительна.

ACD>Есть отчет считающий остатки. Он делает полную выборку по этой здоровой таблице, складывает, считает. Вообщем когда его запускают можно идти пить чай. Если кто-то другой вносил в таблицу какие-то изменения, то отчет выдавал неверные данные.. поэтому они сделали блокировки в отчете.. слава богу это нужно делать раз в месяц)

Ну так делайте его ночью. По расписанию.

ACD>>>>> Данных за день не так много. 300 записей в среднем в эту таблицу.
O>>>>Ради новых 2100 строк в неделю? Действительно странно. А каков вставляемых данных?
ACD>>>ммм. непонял? каков что?
O>>Размер.
ACD>1 запись 1-5 кб. Просто ручками в базу вбивается там новые сделки и т.д.

Ну ради 10Мб данных индексы точно не стоит перестраивать .

Здравствуйте, rm822, Вы писали:

R>сколько-ж у вас отчеты считаются, что можно не успеть

30 минут в среднем месячный отчет.

Здравствуйте, octo47, Вы писали:


O>Ну так делайте его ночью. По расписанию.
его ставят на ночь. но это не вариант. дальше данных станет больше, и придеться все отчеты ставить на ночь..


O>Ну ради 10Мб данных индексы точно не стоит перестраивать .
да это явно был перебор.

Здравствуйте, AC1D, Вы писали:
есть возможность почистить данные? удалить старые данные, если есть такая возможность(сделав перед этим бекап)

Здравствуйте, FantomGood, Вы писали:

FG>Здравствуйте, AC1D, Вы писали:
FG>есть возможность почистить данные? удалить старые данные, если есть такая возможность(сделав перед этим бекап)
Нет. Вообще мы хотели разбить таблицу по годам. т.е оставить данные за 2008-2010 год в старой базе.
Для этого нужно было посчитать остатки, остатки посчитали, но дальше этого дело не пошло.
Сегодня разговаривал с начальником на эту тему, он типа сказал что это моя головная боль..
И типа я (начальник) этим буду теперь заниматься.. Ага как же..

Здравствуйте, AC1D, Вы писали:

ACD>Здравствуйте, FantomGood, Вы писали:

FG>>Здравствуйте, AC1D, Вы писали:
FG>>есть возможность почистить данные? удалить старые данные, если есть такая возможность(сделав перед этим бекап)
ACD>Нет. Вообще мы хотели разбить таблицу по годам. т.е оставить данные за 2008-2010 год в старой базе.
ACD>Для этого нужно было посчитать остатки, остатки посчитали, но дальше этого дело не пошло.
ACD>Сегодня разговаривал с начальником на эту тему, он типа сказал что это моя головная боль..
ACD>И типа я (начальник) этим буду теперь заниматься.. Ага как же..
— да подход "наш" ты ответственнен, сам разбирайся
— перестройка неизвестных индексов на неизвестной большой таблице, с неизвесными запросами — очень продуктивное занятие .
Ближе к делу
1)при формировании отчетов, индексы вообще могут не использоваться, а идет сканирование таблицы.
2) нужно смотреть отчеты, статистику и попробывать или передалить индексы или добавить необходимые
3) если различные варианты индексов не помогут можно побаловаться с секционированием таблицы, а для отчетов прикрутить материализированые вьюшки(если нет интенсивного ввода данных), вроде бы 9 оракл позволяет их создавать

On 18.04.2011 08:16, AC1D wrote:

> У нас есть программа некая программа в которой храняться данные по работе всей компании. Структура бд, организовано не грамотно. грубо говоря есть одна главная таблица в которую постоянно закидываются данные, их уже 7.5 миллионов.
> И все отчеты завязаны на ней. Т.е при вызове одного(любого!) отчета тормозится вся работа с программой.
>
> Разработчики советуют типа делать пересчет индексов каждую неделю причем для всей бд!!!

Поставить вторую БД, настроить репликацию с первой на вторую. Отчеты
делать только со второй.

Здравствуйте, 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% помогало оптимизировать запрос.

Короче, крутись, делай что-то. Поможем, чем сможем.

Здравствуйте, wolfstain3d, Вы писали:

W>А индексация сделает так чтобы между значениями первичного ключа(или других суррогатных полей) не было пропусков, и все работало быстрее.

Что за бред!

Здравствуйте, ZAMUNDA, Вы писали:

ZAM>Здравствуйте, AC1D, Вы писали:

ACD>>Я уже перебуилдил индексы во всей базе. Нехрена не изменилось)
ACD>>Задача как раз так и ставиться. Отчет работает медлено, надо ускорить)
ZAM>Ну тогда приступай к оптимизации. Попробуй план запроса посмотреть, что тормозит выделить.
ZAM>Если план не состраивается, разделяй скрипт на запросы и смотри их план и скорость.
ZAM>Поищи идусский код, мне это в 70% помогало оптимизировать запрос.

ZAM>Короче, крутись, делай что-то. Поможем, чем сможем.

Я же писал что меня отстранили) Сказали типа оптимизацией занимаюсь теперь я (начальник) , ну и естественно всё висит как и висело)
Сегодня начальник разговаривал о скорости какого-то отчета, типа они оптимизировали и он стал АЖ(!) 40 минут формироваться , его спрашивают, а нельзяли 15 минут сделать. Он грит нельзя...

В базу я лезть не хочу, потом на меня всех собак и вывесят.. Да и у меня другая работа)
Не вижу смысла делать их работу, в ущерб своей работе, тем более когда сказали не лезь)) Да индуский код наверно будет почище чем их))
Спасибо за преложеную помощь)

Здравствуйте, wolfstain3d, Вы писали:

W>Возможно они предпологали, что у вас автогенерируемые первичные ключи в базе,т.е. Id поле базы автоматически генерирутся через сиквенс/автоинкремент. В обоих этих случаях транзакции могут отменяться, поля могут удаляться, и в базе имеются пропуски между первичными ключами имеющими значение например 1 и 21. И в несжатом виде максимальный элемент 20000000. Если ужать то будет например всего 100000.Сервер Oracle (и других бд) динамически выделяет данные под типы, т.е. под число 1 выделит меньше памяти чем под 20000000. И соответственно медленнее перебирает данные.А индексация сделает так чтобы между значениями первичного ключа(или других суррогатных полей) не было пропусков, и все работало быстрее.

Это их база. они ПРЕКРАСНО знают что там нужно оптимизировать, просто не хотят это делать по тому как дешевле и быстрее все время чинить и получать за это деньги, чем сделать один раз нормально. А рычагов давления у нас нет. Из базы практически нечего не удаляется, т.е просто идет накопление данных.
Дело не в индексах и обновлении статистика,а как кто-то сказал чтобы бы мы от них отстали..

On 25.04.2011 14:22, AC1D wrote:
>Из базы
> практически нечего не удаляется, т.е просто идет накопление данных.

Ты знаешь, это не редкая практика в БД.