ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Высокая генерация Redo, небольшой объём БД и бекап.
6 сообщений из 31, страница 2 из 2
  2  все
Высокая генерация 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
| Ответить | Цитировать | Написать  
6 сообщений из 31, страница 2 из 2
  2  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Высокая генерация Redo, небольшой объём БД и бекап.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&gotonew=1&tid=1887847]:
 0ms
get settings:
 6ms
get forum list:
 20ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 194ms
get topic data:
 7ms
get first new msg:
 4ms
get forum data:
 2ms
get page messages:
 31ms
get tp. blocked users:
 1ms
others: 189ms
total:  460ms
созд. / загр.: 460ms
x
x
Закрыть


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