ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Высокая генерация Redo, небольшой объём БД и бекап.
31 сообщений из 31, показаны все 2 страниц
  все  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274326
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Здравствуйте!
Есть задача от начинающего dba. Возможно, для кого-то тривиальная, но я пока смутно представляю, как её решить. Если вы поделитесь своими соображением, опытом, советом, буду очень благодарен.

Вводная информация:

Есть БД, в которой довольно большое количество DML операций, подавляющее количество это UPDATE, вот немного информации за последний час:
Код: plsql
1.
2.
3.
4.
select COUNT(*) from v$sqlstats where last_active_time > to_date('2016-07-15 09:00','YYYY-MM-DD HH24:MI') and UPPER(sql_text) LIKE '%UPDATE%';
---
COUNT(*)
40089



Код: plsql
1.
2.
3.
4.
select COUNT(*) from v$sqlstats where last_active_time > to_date('2016-07-15 09:00','YYYY-MM-DD HH24:MI') and UPPER(sql_text) LIKE '%INSERT%';
---
COUNT(*)
106



Да, здесь hardparse, но это затраты на него пока не сильно волнуют.

Как следствие - объём БД не растёт сильно, но генерируется довольно большое количество redo => arhcived log'ов.

Задача: Организовать еженочный бекап. БД должна быть доступна 24/7.

Теперь немного об ограничениях: В данный момент полный объём файловой системы для арклогов - приблизительно равен объёму сгенерированных арклогов за двое суток. Но скоро начнётся продакшн и увеличится поступление информации в 300 раз. Насколько понимаю, ни о каком хранении арклогов до точки краха БД не может быть речи, негде будет хранить арклоги. Отказаться от архайв режима не могу, не будет доступен горячий бекап.
Посоветуйте: каким образом/чем можно организовать бекап, чтобы он был хотя бы для восстановления на момент бекапа при данных условиях?

Пока вижу ситуацию так: В виду высокой генерации арклогов, думаю удалять их по шедулеру, скажем, каждые 20 минут. Потом, часов в 12, начинается горячее резервирование, возможно, при помощи RMAN. Сформированный бекапсет (контрольник, файлы данных и арклоги) буду хранить для восстановления. Остальные, вновь сформированные, арклоги будут продолжаться удаляться.

Может быть есть смысл думать в другом направление, уменьшение генерации redo или что-нибудь ещё.

Если вы поделитесь своим мнением
...
Рейтинг: 0 / 0
15.07.2016, 10:01:02
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274332
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Грубо - 40000/3600=11 updates per sec

для начала разобраться что апдейтится(сколько строк изменяется), может там запросы
кривые и каждый раз апдейтят всю большую таблицу одним и тем же значением
...
Рейтинг: 0 / 0
15.07.2016, 10:13:39
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274348
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
landy,

Масса апдейтов в таблицу W_WLD_MA
Содержание одного из низ:
UPDATE W_WLD_MA SET LAST_COMM_DATE = '15072016101427' WHERE MAIN_PROC_CD = '485' AND LR_GUBUN = '1' AND SUB_PROC_CD = '0'

Т.е. обновляется дата состояния объекта. Объектов довольно много получается.

 
+Небольшая поправка, я ошибся, выданная ранее информация была за пол часа:
Грубо получается - 40000/1800=22 updates per sec
...
Рейтинг: 0 / 0
15.07.2016, 10:25:49
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274367
ora601
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ora601
Участник
JaBong,

Индексы избыточные есть ? И логтику переписывать если применимо(темп таблички).
...
Рейтинг: 0 / 0
15.07.2016, 10:35:14
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274370
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Не знаю скрытого смысла - но зачем обновлять 22 раза в секунду LAST_COMM_DATE (имхо вероятность
смены условия за этот период мала, но опять же нужно знать специфику приложения)
Я бы обратил внимание разработчиков на это - пусть подумают как правильнее сделать
Ну либо пусть от своего бюджета отпилят на диски для хранения архивлогов )))
...
Рейтинг: 0 / 0
15.07.2016, 10:38:37
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274376
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Вообще-то надо смотреть sum(executions) по всяким AWR-срезам
А уж ни как количество различных курсоров
...
Рейтинг: 0 / 0
15.07.2016, 10:42:23
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274545
KoTTT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KoTTT
Участник
Кто мешает бэкапить только архивлоги хоть каждый час, полчаса и т.д.?
...
Рейтинг: 0 / 0
15.07.2016, 12:44:01
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274585
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
landyНе знаю скрытого смысла - но зачем обновлять 22 раза в секунду LAST_COMM_DATE (имхо вероятность
смены условия за этот период мала, но опять же нужно знать специфику приложения)
Я бы обратил внимание разработчиков на это - пусть подумают как правильнее сделать
Ну либо пусть от своего бюджета отпилят на диски для хранения архивлогов )))
Приходит сигнал от робота о смене состояния контроллера, измерений. В одном роботе таких котроллеров и измерителей очень много. Таких роботов очень много. Получается такой вот udpatовый шквал.
...
Рейтинг: 0 / 0
15.07.2016, 13:12:45
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274596
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Вячеслав Любомудров, спасибо за замечание.
Per sec
Executes (SQL): 632.1



Из этого блока подойдёт инфа для корректного анализа?
...
Рейтинг: 0 / 0
15.07.2016, 13:18:23
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274597
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Ты можешь делать консистентный экспорт и отказаться от ARCHIVELOG
...
Рейтинг: 0 / 0
15.07.2016, 13:18:29
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274602
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
KoTTTКто мешает бэкапить только архивлоги хоть каждый час, полчаса и т.д.?
Не мешает никто, было бы куда бэкатить, здесь сталкиваемся с ограничениями в ресурсах :( нет места для такого объёма арклогов.
...
Рейтинг: 0 / 0
15.07.2016, 13:20:15
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274606
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Вячеслав Любомудров,

Да, это хороший вариант, спасибо, теперь нужно будет только позаботиться о достаточно большом UNDO. Правильно понимаю?
...
Рейтинг: 0 / 0
15.07.2016, 13:21:51
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274622
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
JaBongВячеслав Любомудров, спасибо за замечание.
Per sec
Executes (SQL): 632.1Вообще-то я имел ввиду именно для тех курсоров, которые получились в твоем запросе
JaBongИз этого блока подойдёт инфа для корректного анализа?Ну а почему бы и нет
Например, 250к редо в секунду -- это примерно 900 мег в час (пусть гиг)
Это, в общем-то, не очень много, но как ты собрался его увеличивать в 300 раз? 300 гигов в час -- это очень серьезный редо-поток.

А если у тебя в основном UPDATE, то путей уменьшения redo практически нет

Твое желание "хотя бы для восстановления на момент бекапа" (а если ты трешь логи, то другого и не получится) легко реализуется каким-нибудь параллельным консистентным expdp в NOARCHIVELOG

Если БД гигов до 300 -- наверное, в часик-полтора уложится. Плюс ты можешь не бэкапить какие-нибудь промежуточные таблицы

Хотя я всегда против обзывания экспорта бэкапом.
...
Рейтинг: 0 / 0
15.07.2016, 13:31:19
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274636
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Вячеслав Любомудров,

из-за смутного понимания и не определённых вариантов к действию, хочу сказать Вам большое спасибо за то, что рассеяли это непонимание.
...
Рейтинг: 0 / 0
15.07.2016, 13:43:29
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274646
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
Непонимание у тебя в постановке:
"БД должна быть доступна 24/7" и "восстановления на момент бекапа" -- как-то не сходится
...
Рейтинг: 0 / 0
15.07.2016, 13:50:39
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274686
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Ну я бы не апдейтил, а сделал таблицу еще одну с nologging и связал ее с первой по ID
И просто делал insert /*+append*/ для условия по первой таблице
Это бы уменьшило генерацию редо
А для просмотра результатов запрос для этих двух таблиц или вьюшку
Как то так - опять же это вопрос дизайна и разработчиков
Они просто тупо не хотят думать имхо
...
Рейтинг: 0 / 0
15.07.2016, 14:28:08
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274708
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Кстати, если БД EE - можно посмотреть в эту сторону
Включить block change tracking, сделать инкрементально обновляемую копию(обновлять раз в час или два)
И хранить архивлоги только за последний час/два - удалять ненужные после обновления копии
Как-то так
...
Рейтинг: 0 / 0
15.07.2016, 14:39:27
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274710
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Т е у вас будет копия БД которую вы сможете быстро поднять
...
Рейтинг: 0 / 0
15.07.2016, 14:40:25
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274791
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Вячеслав ЛюбомудровНепонимание у тебя в постановке:
"БД должна быть доступна 24/7" и "восстановления на момент бекапа" -- как-то не сходится
Насколько известно, более критично - наличие доступной БД, чем отсутствие в ней части данных за время с последнего бекапа до возобновления работы БД. Так и получается.
...
Рейтинг: 0 / 0
15.07.2016, 15:56:36
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274796
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
landyКстати, если БД EE - можно посмотреть в эту сторону
Включить block change tracking, сделать инкрементально обновляемую копию(обновлять раз в час или два)
И хранить архивлоги только за последний час/два - удалять ненужные после обновления копии
Как-то так
О, вот это довольно хороший вариант. Спасибо, landy!
...
Рейтинг: 0 / 0
15.07.2016, 15:58:43
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274798
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
JaBongболее критично - наличие доступной БД, чем отсутствие в ней части данных за время с последнего бекапа до возобновления работы БД. Так и получается. Имеется ввиду именно этот частный случай.
...
Рейтинг: 0 / 0
15.07.2016, 15:59:58
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39274804
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
JaBonglandyКстати, если БД EE - можно посмотреть в эту сторону
Включить block change tracking, сделать инкрементально обновляемую копию(обновлять раз в час или два)
И хранить архивлоги только за последний час/два - удалять ненужные после обновления копии
Как-то так
О, вот это довольно хороший вариант. Спасибо, landy!Это слишком навороченный стендбай (который можно сделать и не обязательно в EE)

Вообще, с таким потоком данных работают по другому (ну нахрена тебе несколько раз в секунду обновлять какое-то поле одного датчика, тем более если не хранится история?).
Сыпешь всю эту хрень непрерывным потоком в плоские файлы ОС, а потом раз в какой-то период (1-5-10 сек) обновляешь данные в оракл последними значениями для каждого датчика, полученными из этого плоского файла простыми утилитами (а в это время данные сыпятся в другой плоский файл)
...
Рейтинг: 0 / 0
15.07.2016, 16:10:34
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39275066
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Конечно можно и на SE, только грубо change tracking - индекс измененных блоков, а в SE будут
сканироваться датафайлы на предмет измененных блоков.
Все зависит от размера БД и как часто это можно будет делать.
И да - это стендбай, который не нарушает лицензионность БД
...
Рейтинг: 0 / 0
16.07.2016, 11:34:37
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39275263
Фотография Vadim Lejnin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vadim Lejnin
Участник
landyКонечно можно и на SE, только грубо change tracking - индекс измененных блоков, а в SE будут
сканироваться датафайлы на предмет измененных блоков.
Все зависит от размера БД и как часто это можно будет делать.
И да - это стендбай, который не нарушает лицензионность БД

BCT нет для SE:
Oracle Database Editions

feature/optionSE1SE/SE2EEBlock change tracking for fast incremental backupNNY
...
Рейтинг: 0 / 0
17.07.2016, 19:51:31
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39275266
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Так и написано - для ЕЕ change tracking
Для SE - будет проверка всех датафайлов на предмет изменения страниц
(и для ЕЕ если change tracking не включен)
...
Рейтинг: 0 / 0
17.07.2016, 20:39:53
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39276252
Taciturn12
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Taciturn12
Гость
А есть ли возможность создания StandBy? Возможно это решение будет выгодней чем бекап. Он обеспечит быстрое восстановление работоспособности без потери данных. Может помочь инкрементальный бекап если количество меняющихся блоков невелико.

Но если поток изменений будет реально 300 гигов в час, считаю необходимо менять логику работы приложений с базой. Процесс записи буфера скорее всего не справится с таким потоком. У меня проблемы с этим начинались с примерно 100 гигов в час при параллелизации Redo в 2 места. После чего время ожидания коммитов начинало расти. При высокой частоте смены значений в таблице без наличия истории изменений они скорее всего не имеют ценности и возможно эти таблицы не требуется логировать, что снизит поток изменений в разы и уберет проблему на корню? А таблицам хватит резервирования раз в сутки при выполнении полного бекапа.

Еще нужно больше данных: какой объем базы? сколько времени занимает бекап? какой объем под бекап? может есть возможность делать полный бекап каждые 2 часа ).
...
Рейтинг: 0 / 0
19.07.2016, 13:44:50
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39276463
Фотография Vadim Lejnin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vadim Lejnin
Участник
Taciturn12А есть ли возможность создания StandBy? Возможно это решение будет выгодней чем бекап. Он обеспечит быстрое восстановление работоспособности без потери данных. Может помочь инкрементальный бекап если количество меняющихся блоков невелико.

Но если поток изменений будет реально 300 гигов в час, считаю необходимо менять логику работы приложений с базой. Процесс записи буфера скорее всего не справится с таким потоком. У меня проблемы с этим начинались с примерно 100 гигов в час при параллелизации Redo в 2 места. После чего время ожидания коммитов начинало расти. При высокой частоте смены значений в таблице без наличия истории изменений они скорее всего не имеют ценности и возможно эти таблицы не требуется логировать, что снизит поток изменений в разы и уберет проблему на корню? А таблицам хватит резервирования раз в сутки при выполнении полного бекапа.

Еще нужно больше данных: какой объем базы? сколько времени занимает бекап? какой объем под бекап? может есть возможность делать полный бекап каждые 2 часа ).

1) Если EE и есть лицензии на CPU standby сервера - проблем нет
Ставишь
Код: plsql
1.
ARCHIVELOG DELETION POLICY TO APPLIED ON   [ALL] STANDBY



2) Если SE и есть лицензии на CPU standby сервера
Лепишь самодельный велосипед, который проверяет что archivelog применился и удаляешь
Удалять лучше через RMAN

3) Если лицензий нет, мутишь что-то вроде Дискового Oracle Fail Safe
И пару redo log location на SAN, чтобы гарантированно иметь копии REDO
Недорогой SAN - будет дешевле чем лицензии на Standby, вопрос в производительности...
...
Рейтинг: 0 / 0
19.07.2016, 16:30:55
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39277228
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Taciturn12Но если поток изменений будет реально 300 гигов в час, считаю необходимо менять логику работы приложений с базой. Процесс записи буфера скорее всего не справится с таким потоком. У меня проблемы с этим начинались с примерно 100 гигов в час при параллелизации Redo в 2 места. После чего время ожидания коммитов начинало расти. При высокой частоте смены значений в таблице без наличия истории изменений они скорее всего не имеют ценности и возможно эти таблицы не требуется логировать, что снизит поток изменений в разы и уберет проблему на корню? А таблицам хватит резервирования раз в сутки при выполнении полного бекапа.


По идее, у БД должен быть стендбай.

Если убрать логирование с таблиц, полученный горячий бекап будет консистентным?

Да, согласен, при "заявленном" потоке redo нужно будет менять логику приклада.
...
Рейтинг: 0 / 0
20.07.2016, 16:53:21
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39277231
JaBong
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JaBong
Гость
Vadim Lejnin1) Если EE и есть лицензии на CPU standby сервера - проблем нет
Ставишь
Код: plsql
1.
ARCHIVELOG DELETION POLICY TO APPLIED ON   [ALL] STANDBY



2) Если SE и есть лицензии на CPU standby сервера
Лепишь самодельный велосипед, который проверяет что archivelog применился и удаляешь
Удалять лучше через RMAN

3) Если лицензий нет, мутишь что-то вроде Дискового Oracle Fail Safe
И пару redo log location на SAN, чтобы гарантированно иметь копии REDO
Недорогой SAN - будет дешевле чем лицензии на Standby, вопрос в производительности...

Это что за фишка, "ARCHIVELOG DELETION POLICY" доступен только ЕЕ?
...
Рейтинг: 0 / 0
20.07.2016, 16:54:56
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39277258
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
NOLOGGING can be used to minimize the amount of redo generated by Oracle. Only the following operations can make use of nologging:

    SQL*Loader in direct mode
    INSERT /*+APPEND*/ ...
    CTAS
    ALTER TABLE statements (move/add/split/merge partitions)
    CREATE INDEX
    ALTER INDEX statements (move/add/split/merge partitions)



У Вас update - nologging не поможет
...
Рейтинг: 0 / 0
20.07.2016, 17:33:24
| Ответить | Цитировать | Написать  
Высокая генерация Redo, небольшой объём БД и бекап.
    #39277265
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Вы так и не озвучили какая версия (EE SE) у вас.
Предполагаемый объем БД, критичность простоя, требования к времени восстановления и т п
...
Рейтинг: 0 / 0
20.07.2016, 17:39:28
| Ответить | Цитировать | Написать  
31 сообщений из 31, показаны все 2 страниц
  все  
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Высокая генерация Redo, небольшой объём БД и бекап.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=52&tid=1887847]:
 0ms
get settings:
 5ms
get forum list:
 16ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 155ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 196ms
total:  437ms
созд. / загр.: 437ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]