Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Хм... При загрузке или при удалении очень большого количества записей, я через N-е количество делаю коммит. Разве это плохо ? Как раз все время наблюдаю как сначала заполняется UNDO, а потом очищается (правда на это влияет как раз параметр undo_retention). |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
....
Исправлено 1 раз(а). Последнее : ВладимирС, 05.08.19 15:38 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Делая коммит БЕЗ привязки к логике сохраняемых данных ты как раз и получаешь в случае сбоя непойми-какое состояние БД. Часть записей сохранилась, другая часть - нет. Это, конечно, не то чтобы катастрофа - но восстановление и повторный запуск "с того места где остановились" целиком и полностью на твои плечи ложится.
Так делают в некритичных случаях, или если заливаемые данные в принципе адекватны (непротиворечивы) и будучи залиты "частично" (и можно сравнительно просто определить что ещё надо добавить). Иначе ты просто очень прилично усложняешь себе жизнь, по сути отказываясь от транзакций... ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо... При загрузке данных я понимаю, что гружу, в какой последовательности, соблюдая целостность данных, и понимаю, почему делаю коммит. >> восстановление и повторный запуск "с того места где остановились" целиком и полностью на твои плечи ложится. Это точно. Хм... А ты как делаешь ? Методологию примерно можешь описать ? Загрузка/удаление большого объема данных, что может повлечь переполнение UNDO. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Я никак не делаю Я уже не занимаюсь администрированием оракла. Да и вручную ETL задачи выполнять - не думаю что лучший вариант. Ну разве что ты именно что разрабатываешь ETL инструмент. Там стратегий много - можно и на логически непротиворечивые порции делить заливаемую инфу и после каждой порции коммитить, можно предварительно загрузить в staging таблицы данные, там "подработать" их и потом из них уже скопом перегонять в рабочие...
В любом случае не думаю что это хоть как-то уменьшит объём используемого undo пространства, и гарантирует от ошибок если место для "активных" транзакций таки закончится. Множество "мелких" транзакций будут в общем случае порождать больше undo данных чем одна мега-крупная транзакция (т.к. запросто окажется что в десятке мелких транзакций меняется один и тот же блок данных - если не сама таблица, то её индексы - а значит он 10 раз попадёт в сегменты отката). Но с другой стороны, мелкие транзакции позволяют записям undo становится "неактивными", и система сможет их переписывать. Если у тебя стоит undo_retention на 15 минут, а "процесс" заливки занимает 3 часа, то по сути оракл будет хранить лишь данные отката для активных транзакций, и транзакций завершившихся не более чем 15 минут назад. НО для этого объёма данных он раздует undo пространство до тех пределов, до каких ты ему это позволяешь делать. Если ты принудительно "задушишь" авторасширение, скажем ограничив его 1Гб-ом, то оракл уже станет выкидывать (переписывать, т.е. повторно использовать место) из undo данные по транзакциям завершённым и всего 1 минуту назад - т.е. undo_retention это не "гарантия", а лишь мягкая рекомендация. Ну и да, если для активных на текущий момент времени транзакций потребуется таки больше места чем доступно, то они начнут сыпаться (с ошибкой "невозможно расширить экстент") - откатываясь к своему исходному состоянию. ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо большое за разъяснения.
|
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Прошу еще помощи...
Люди с Проекта попросили меня разобраться... Ситуация: Проект, как всегда располагается на 3 площадках: Тест, Предпрод, Прод. Тест обычно у нас, Предпрод и Прод на площадках типа заказчика. Заказчик решил поменять сервера для площадок Предпрод, Прод, видимо из-за старости оборудования. После смены площадок запросы начали выполняться медленнее. На Тесте запрос выполняется 8 сек. На Предпроде 25-30 минут. Т.к. сервер Предпрода мощнее, то решил сделать такую работу. 1. На Тесте сделал дамп схемы. 2. Перекинул на Предпрод, т.к. Прод - это святое и его не трогаем. Развернул схему на Предпроде. 3. Запустил скрипт запроса. Вижу что запрос выполняется на Предпроде 25 минут, что ни в какие ворота не лезет, что подтверждает, что "запросы начали выполняться медленнее". На Предпроде заново собрал статистику схемы. Все равно запрос выполняется медленно, 24 минуты. Но скорее он ни о чем не говорит. Но ведь выполняется на Тесте за 8 сек. Пераметры серверов: [attachment 31802 02.png] Куда копать ? Исправлено 4 раз(а). Последнее : ВладимирС, 05.09.19 06:26 |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
В добавление:
ОС на Предпроде: Red Hat Enterprise Linux Server release 7.6 (Maipo) ОС на Тесте: Red Hat Enterprise Linux Server release 6.4 (Santiago) В процессе работы скрипта: Предпрод TOP [attachment 31803 ] Тест TOP [attachment 31804 ] |
© 2000-2024 Fox Club  |