Добро пожаловать, Гость
Логин: Пароль: Запомнить меня
Теоретические аспекты и практические реализации создания, внедрения и использования баз данных, СУБД, хранилищ.
  • Страница:
  • 1
  • 2
  • 3
  • 4

ТЕМА:

Re: Oracle: Checkpoint not complete 12 года 9 мес. назад #2498

Вы ищете оптимальные значения с точки зрения размеров (файлов, памяти и т.д.), а надо искать оптимум с точки зрения средней (лучше - среднестатистической) нагрузки на сервер. Определитесь с частотой чекпоинтов и исходя из этого задавайте размеры буферов (в рамках физических возможностей, естественно).

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Re: Oracle: Checkpoint not complete 12 года 9 мес. назад #2499

Получается... Значит если я вас правильно понял размер лог-буфера абсолютно никак на связан с рамером самого лог-файла?

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Re: Oracle: Checkpoint not complete 12 года 9 мес. назад #2500

Абсолютно! В рамках здравого смысла, естественно. Не следует задавать размер буфера больше размера файла (хотя можно и попробовать, Но я считаю это нежелательно...)

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Re: Oracle: Checkpoint not complete 12 года 9 мес. назад #2501

Помимо нагрузки есть еще такая штука, как длинные транзакции.


И что у вас бывает такое, что транзакции длятся с неделю? Или может быть еще дольше?))
1M - это уже большой буфер, очень редко есть смысл делать его большим

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Re: Oracle: Checkpoint not complete 12 года 9 мес. назад #2502

Первое:
" Вы ищете оптимальные значения с точки зрения размеров (файлов, памяти и т.д.), а надо искать оптимум с точки зрения средней (лучше - среднестатистической) нагрузки на сервер.

Второе:
"Определитесь с частотой чекпоинтов и исходя из этого задавайте размеры буферов (в рамках физических возможностей, естественно)."

Хочется прокомментировать ваше утверждение - мне кажется оно не совсем логичным.

Ваше первое и второе утверждение не совсем согласуется. Если я вначале должен определится с частотой чекпоинтов, то я неизбежно должен в первую очередь думать о размере лог-файла, так как от размера файла зависит как часто он будет переключаться, а это в свою очередь определяет частоту чекпоинтов, так как чекпоинт всегда происходит при переключении.

Далее. Из статьи "Открыто о СУБД Oracle на русском : Переключение журналов и немного терминологии":
Переключение

журнала процессом LGWR может произойти по одной из трех причин.

 1. Обычно журнал переключается, когда процесс, генерирующий информацию

    повторного выполнения, не может выделить место в буфере журнала,

    поскольку недостаточно места осталось в текущем файле журнала. Тогда

    процесс обращается к процессу LGWR с требованием переключить журнал, и

    сеанс "засыпает" в ожидании события log file switch completion.

.....................

То есть если не правильно подобран размер файла, то переключение(соответственно и контрольная точка) будет происходить еще и при недостатке места в файле. Размер же этого недостатка не зависит от нагрузки на сервер, а зависит видимо от размера транзакции.

При этом видимо размер лог-буфера тоже играет не последнюю роль. Потомучто перед переключением на новый журнал происходит сброс:
"Он сбрасывает любую оставшуюся в буфере журнала повторного выполнения

    информацию на диск, а затем записывает номер системного изменения (SCN)

    последней записи повторного выполнения в журнальном файле (максимальный

    SCN, high SCN) в блок заголовка журнального файла. Как только эти

    записи завершены, процесс LGWR закрывает журнальный файл"

Значит если размер буфера будет слишком большим, значит он сможет долго не делать сброс в файл - это значит меньше лишних дисковых операций. Но с другой стороны перед переключением будет накоплена большая порция и непосредственно в момент переключения будет "затор".

Если размер буфера слишком маленький, то будет слишком частый сброс, что тоже не очень хорошо.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

  • Страница:
  • 1
  • 2
  • 3
  • 4
Время создания страницы: 0.255 секунд