Я создаю образ Docker для базы данных Oracle, и из одного и того же образа будет создано много различных контейнеров.
Когда я запускаю экземпляр Oracle, по какой-то причине несколько байт записываются во все активные файлы данных. Docker сохраняет разницу между контейнером и базовым образом, и эта разница — весь измененный файл, поэтому каждый раз, когда я запускаю контейнер, на диск записывается более 6 ГБ только для запуска базы данных.
Итак, почему Oracle пишет в файлы данных при запуске базы данных? Наиболее логичным поведением было бы писать в файлы данных только тогда, когда данные изменяются и фиксируются. Могу ли я что-то сделать, чтобы это изменить?
Помимо Oracle Linux (который является основой моего образа), я также пробовал это на Windows, и поведение было таким же, все файлы данных записывались.
Я попробовал установить табличные пространства в режим только для чтения. Это позволяет избежать операции записи, однако, когда я устанавливаю табличное пространство в режим чтения и записи, оно немедленно записывает данные в файл, что снова приводит к проблеме.
Для ясности: мне нужно, чтобы табличные пространства были доступны для записи, но только тогда, когда данные действительно изменяются.
решение1
Избежать этого невозможно. Помимо данных пользователей Oracle также содержит много метаданных — их тоже нужно поддерживать. Внутри Oracle поддерживается номер, называемый SCN (System Change Number). Этот номер увеличивается всякий раз, когда в базе данных что-то меняется.
Этот номер SCN записывается в заголовок каждого файла данных, а также в каждый файл управления. При открытии (запуске) базы данных Oracle проверяет, что этот номер одинаков во всех файлах. Затем он предполагает, что файлы согласованы.
Этот SCN увеличивается даже если нет нагрузки на базу данных. Также есть фоновые задания, такие как сбор статистики, которые делают некоторую нагрузку. Также пользователи могут создать системный триггер ON DATABASE STARTUP, который будет выполнять некоторую задачу при запуске базы данных.
Обычно серверы баз данных Oracle не являются хорошими кандидатами для виртуализации. Персонал, занимающийся журналированием Oracle, тоже делает это внутри, поэтому вы сохраняете одни и те же данные дважды (эти файлы называются архивными журналами повторного выполнения). Поэтому если вы удалите контейнерные diffs (только для файлов данных), Oracle сможет это пережить, поскольку он сможет воспроизвести транзакции из журналов повторного выполнения.
PS: При клонировании баз данных вам также следует подумать об изменении SID базы данных на уникальный. Или, по крайней мере, вам следует использовать nid для изменения уникального номера базы данных DBID. В противном случае у вас могут возникнуть проблемы при восстановлении резервных копий баз данных RMAN.