Проблемы с transparent huge pages, их надо отключать в опциях загрузки и использовать обычные.
Также желательно убрать prelink из cron.
В остальном все Ок. Если SGA больше где-нибудь 10Gb, то никуда от huge pages не денешься.
Это всего лишь технология, ее можно применять как во благо, так и во зло.
imho, угроза перенаселения на Земле на данный момент очень даже реальна, угрозы же вымирания человечества нет.
У нас в России огромное количество сирот живущих в детских домах в ужасных условиях.
Казалось бы, в интересах государства разрешить однополые браки и усыновление, чтобы дети росли с родителями в комфорте и получали хорошее образование, что для страны будет очень хорошо.
Почему же этого не происходит? Ведь тогда не стало бы сирот, да еще из из других менее благополучных государств крох на воспитание начали брать, что еще лучше для страны.
Вопрос только в общем настрое общества, а не в выгоде государства.
Пожалуйста :)
Рекомендуемое oracle-ом время между log switch — 15-20 минут, так что рекомендую кроме количества также увеличить размер каждого redo хотя бы до 8Gb — это здорово снизит нагрузку по записи dwbr и немного увеличит mttr, что не так страшно.
По fractured блокам — попробуй на тестовой БД под умеренной нагрузкой провести эксперимент, разорвать синхронизацию и на стороне slave выполнить recover+open (restelogs). По моему опыту даже в синхронном режиме без begin backup не получится поднять копию БД.
Эта информация устарела. Oracle все ужесточил, теперь можно не лицензировать только если на failover сервере не установлен soft и он физически не подключен к массиву :) Круто, да? ;)
В таком случе хотел еще спросить — такой вариант с отстванием части разделов с dba согласован?
Он неработоспособен и при потере master массива невозможно будет запуститься на slave, кроме этого возможна потеря достаточно большого объема транзакций при последущем восстановлении с ленточек.
По потере — причина в том, что если БД работает достаточно активно и redo log switch происходит раз в минуту (что неправильно, но бывает), а в БД всего 3 группы redo, то через три минуты произойдет затирание redo, сгенерированного три минуты назад, а архивная копия лога из-за задержки на slave еще не доедет.
По невозможности подняться — из-за несинхронного режима 100% вероятность получить fractured oracle блоки (в которх разный rba в заголовке и в трейле) при пропадании master или просто при разрыве канала синхронизации. Fractured блоки oracle не умеет восстаналивать по redo (если только не был выполнен begin backup, но постоянно с этим жить нельзя — можно только включать на момент split mirror для получения косистентной копии, например), так что опять только вариант восстанавления с ленточек.
Рекомендую перевести всю синхронизацию oracle на синхронный режим.
При отставании записи в datafiles oracle должен восстановить все недописанное по archive и redo логам.
Что касается цены — второй сайт в любом случае подлежит полному лицензированию, так что разница в цене с DataGuard не столь велика должна быть.
У undo и redo принципиальная разная структура операций: по redo идут чисто последовательные запись и чтение, по undo идет random read-write.
redo гораздо более критичен по производительности.
И смысла иметь синхронно реплицируемое undo при отстающих остальных табличных пространствах совершенно никакого.
А можно реальный пример, когда действительно требуется выборка случайных строк?
Мне, кроме сбора статистики по большой таблице в ограниченное время, ничего в голову не приходит.
Да ладно, банк-то может перебрать 10000 вариантов PIN, чтобы получить тот же PVV за разумный срок :)
Также желательно убрать prelink из cron.
В остальном все Ок. Если SGA больше где-нибудь 10Gb, то никуда от huge pages не денешься.
А почему Голландию, а не США в пример привели?
И в странах, где гей-браки легализованы сирот нет.
imho, угроза перенаселения на Земле на данный момент очень даже реальна, угрозы же вымирания человечества нет.
Казалось бы, в интересах государства разрешить однополые браки и усыновление, чтобы дети росли с родителями в комфорте и получали хорошее образование, что для страны будет очень хорошо.
Почему же этого не происходит? Ведь тогда не стало бы сирот, да еще из из других менее благополучных государств крох на воспитание начали брать, что еще лучше для страны.
Вопрос только в общем настрое общества, а не в выгоде государства.
www.oracle.com/us/corporate/pricing/sig-070616.pdf
стр.23-24
Рекомендуемое oracle-ом время между log switch — 15-20 минут, так что рекомендую кроме количества также увеличить размер каждого redo хотя бы до 8Gb — это здорово снизит нагрузку по записи dwbr и немного увеличит mttr, что не так страшно.
По fractured блокам — попробуй на тестовой БД под умеренной нагрузкой провести эксперимент, разорвать синхронизацию и на стороне slave выполнить recover+open (restelogs). По моему опыту даже в синхронном режиме без begin backup не получится поднять копию БД.
Он неработоспособен и при потере master массива невозможно будет запуститься на slave, кроме этого возможна потеря достаточно большого объема транзакций при последущем восстановлении с ленточек.
По потере — причина в том, что если БД работает достаточно активно и redo log switch происходит раз в минуту (что неправильно, но бывает), а в БД всего 3 группы redo, то через три минуты произойдет затирание redo, сгенерированного три минуты назад, а архивная копия лога из-за задержки на slave еще не доедет.
По невозможности подняться — из-за несинхронного режима 100% вероятность получить fractured oracle блоки (в которх разный rba в заголовке и в трейле) при пропадании master или просто при разрыве канала синхронизации. Fractured блоки oracle не умеет восстаналивать по redo (если только не был выполнен begin backup, но постоянно с этим жить нельзя — можно только включать на момент split mirror для получения косистентной копии, например), так что опять только вариант восстанавления с ленточек.
Рекомендую перевести всю синхронизацию oracle на синхронный режим.
Что касается цены — второй сайт в любом случае подлежит полному лицензированию, так что разница в цене с DataGuard не столь велика должна быть.
redo гораздо более критичен по производительности.
И смысла иметь синхронно реплицируемое undo при отстающих остальных табличных пространствах совершенно никакого.
Мне, кроме сбора статистики по большой таблице в ограниченное время, ничего в голову не приходит.