:: Не фоксом единым
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Конечно, если разработчики идиоты, то всякое возможно - может они напихали коммитов абы куда...
Хм...
При загрузке или при удалении очень большого количества записей, я через N-е количество делаю коммит. Разве это плохо ?
Как раз все время наблюдаю как сначала заполняется UNDO, а потом очищается (правда на это влияет как раз параметр undo_retention).
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
....



Исправлено 1 раз(а). Последнее : ВладимирС, 05.08.19 15:38
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Делая коммит БЕЗ привязки к логике сохраняемых данных ты как раз и получаешь в случае сбоя непойми-какое состояние БД. Часть записей сохранилась, другая часть - нет. Это, конечно, не то чтобы катастрофа - но восстановление и повторный запуск "с того места где остановились" целиком и полностью на твои плечи ложится.
Так делают в некритичных случаях, или если заливаемые данные в принципе адекватны (непротиворечивы) и будучи залиты "частично" (и можно сравнительно просто определить что ещё надо добавить). Иначе ты просто очень прилично усложняешь себе жизнь, по сути отказываясь от транзакций...


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Делая коммит БЕЗ привязки к логике сохраняемых данных ты как раз и получаешь в случае сбоя непойми-какое состояние БД. Часть записей сохранилась, другая часть - нет. Это, конечно, не то чтобы катастрофа - но восстановление и повторный запуск "с того места где остановились" целиком и полностью на твои плечи ложится.
Так делают в некритичных случаях, или если заливаемые данные в принципе адекватны (непротиворечивы) и будучи залиты "частично" (и можно сравнительно просто определить что ещё надо добавить). Иначе ты просто очень прилично усложняешь себе жизнь, по сути отказываясь от транзакций...
Спасибо...
При загрузке данных я понимаю, что гружу, в какой последовательности, соблюдая целостность данных, и понимаю, почему делаю коммит.
>> восстановление и повторный запуск "с того места где остановились" целиком и полностью на твои плечи ложится.
Это точно.

Хм... А ты как делаешь ? Методологию примерно можешь описать ? Загрузка/удаление большого объема данных, что может повлечь переполнение UNDO.
Ratings: 0 negative/0 positive
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
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спасибо большое за разъяснения.
Ratings: 0 negative/0 positive
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
Ratings: 0 negative/0 positive
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 ]
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 10 PuMa  (Гостей: 9)

© 2000-2024 Fox Club 
Яндекс.Метрика