Одна опция состоит в том, чтобы использовать резервный инструмент как backup2l
, это может быть настроено к любому уровню дифференциального резервного копирования и любому количеству полного резервного копирования. backup2l
работал как cronjob в любой частоте, которую Вы любите, и она настроена путем устанавливания некоторых значений в ее conf файл. Это - на самом деле обертка для tar или afio, это сохраняет списки файлов с хешами для нахождения изменений и обеспечивает простой способ получить состояние или восстановить файл по дате.
Вторая опция состоит в том, чтобы использовать систему управления версиями такой как cvs
, svn
, git
и т.д. Установите cronjob, который сделает автоматические фиксации (и возможно ежедневно отмечающий). На основе vcs выбора Вам, возможно, понадобятся некоторые сценарии, чтобы добавить новые файлы или удалить старые.
Для частоты каждого получаса я рекомендовал бы vcs опцию. Но можно объединить два при помощи backup2l
(или любой другой резервный инструмент), чтобы также скопировать vcs репозиторий (дублирование резервных копий всегда хорошо).
Oracle на самом деле упорно работает для предотвращения кэшей файловой системы для файлов данных (и управление и файлы журнала) в системах, где это может быть сделано. Это имеет место для AIX и JFS2 с Параллельным вводом-выводом (см. Администрирование База данных Oracle по AIX для настройки совета также).
Идея состоит в том, чтобы избежать двойной буферизации данных. Блоки кэшей Oracle в SGA. Если ОС кэширует их также, у Вас есть они дважды в RAM, которая является отходами. И Oracle, как предполагается, может управлять своим кэшем более точно, чем политики замены кэша ОС могут - она иметь больше информации о важности/жаркости блоков относительно текущей рабочей нагрузки, чем ОС делает при нормальных обстоятельствах.
(Oracle также делает некоторую очень необычную "запись, буферизующую", который только база данных может сделать для поддержания свойств ACID и должна управлять точно, когда и что сбросить и синхронизировать.)
Если у Вас есть свободная RAM, и Ваше отношение удачного обращения в кэш Oracle не хорошо, необходимо рассмотреть увеличение размера SGA (кэш-буфер DB в особенности). Действительно посмотрите на V$DB_CACHE_ADVICE
и другие настраивающие представления, и имеют в виду необходимость в RAM для других вещей также (особенно PGA, но также и приложения не-Oracle) не выделяйте всю RAM SGA.
При использовании Oracle, 11 г, настраивая Автоматическое управление памятью нужно рассмотреть так, можно установить емкость памяти единой цели и позволить Oracle сбалансировать различные области самой. (Для предыдущего выпуска изучите автоматический SGA и управление PGA.)
Как всегда, тест (и сравнительный тест) любые изменения Вы делаете перед применением к производственным системам. И не исчерпайте ресурсы ОС, оставьте "разумный" объем памяти вне областей памяти Oracle для других потребностей.
Обратите внимание, что, является ли механизм базы данных (какой бы ни бренд) или файловая система/ОС лучшим при кэшировании, старые дебаты. Хорошо настроенная база данных должна быть лучше в кэшировании при нормальных обстоятельствах. ОС, вероятно, разобьет неправильно сконфигурированную базу данных.