|
|
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
Абсолютно! В рамках здравого смысла, естественно. Не следует задавать размер буфера больше размера файла (хотя можно и попробовать). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 16:47 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
>Помимо нагрузки есть еще такая штука, как длинные транзакции. И что у вас транзакции длятся с неделю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 17:06 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
1M - это уже большой буфер, очень редко есть смысл делать его большим ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 17:09 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
2softbuilder откуда это ? >Принцип применения поменялся в 8.1.5. Если в 8.0.5 это значение означало кол-во блоков ОС после которого выполняется >контрольная точка, то в 8.1.5 это означает, кол-во блоков, которое остаётся не заполненным до конца файла редо-лога 8.1.7 reference: LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that can exist between an incremental checkpoint and the last block written to the redo log. >>Многие говорят что это связано с тем что arch не успевает заархивировать. Однако это происходит и в режиме noarchivelog. Мне кажется что arch здесь ни при чем. LGWR ждет завершения checkpoint а не архивации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 17:09 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
to Noname_: Первое: " Вы ищете оптимальные значения с точки зрения размеров (файлов, памяти и т.д.), а надо искать оптимум с точки зрения средней (лучше - среднестатистической) нагрузки на сервер. Второе: "Определитесь с частотой чекпоинтов и исходя из этого задавайте размеры буферов (в рамках физических возможностей, естественно)." Хочется прокомментировать ваше утверждение - мне кажется оно не совсем логичным. Ваше первое и второе утверждение не совсем согласуется. Если я вначале должен определится с частотой чекпоинтов, то я неизбежно должен в первую очередь думать о размере лог-файла, так как от размера файла зависит как часто он будет переключаться, а это в свою очередь определяет частоту чекпоинтов, так как чекпоинт всегда происходит при переключении. Далее. Из статьи "Открыто о СУБД Oracle на русском : Переключение журналов и немного терминологии": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. То есть если не правильно подобран размер файла, то переключение(соответственно и контрольная точка) будет происходить еще и при недостатке места в файле. Размер же этого недостатка не зависит от нагрузки на сервер, а зависит видимо от размера транзакции. При этом видимо размер лог-буфера тоже играет не последнюю роль. Потомучто перед переключением на новый журнал происходит сброс: Код: plaintext 1. 2. 3. 4. 5. Значит если размер буфера будет слишком большим, значит он сможет долго не делать сброс в файл - это значит меньше лишних дисковых операций. Но с другой стороны перед переключением будет накоплена большая порция и непосредственно в момент переключения будет "затор". Если размер буфера слишком маленький, то будет слишком частый сброс, что тоже не очень хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 17:23 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
">>Многие говорят что это связано с тем что arch не успевает заархивировать. Однако это происходит и в режиме noarchivelog. Мне кажется что arch здесь ни при чем. LGWR ждет завершения checkpoint а не архивации." to Lazy: Естественно, что если база не в режиме archivelog, то не причём. Я об этом и говорил. Только в режиме archivelog LGWR ждёт в том числе и ARCH, когда он заархивирует лог-файл, на который происходит переключение. Давай только не будет углублять тему LGWR и ARCH. Это имеет косвенное отношение к первоначальной теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 17:27 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
Не совсем понятен смысл слов: "Обычно журнал переключается, когда процесс, генерирующий информацию повторного выполнения, не может выделить место в буфере журнала, поскольку недостаточно места осталось в текущем файле журнала." Так как размер лог-файла обычно намного превосходит размер лог-буфера, то на одно заполнение файла приходится несколько заполнений и сбросов буфера. И еще цитата из доки: A rough guide is to switch logs at most once every twenty minutes. То есть размер лог-файла необходимо подбирать исходя из нагрузки на сервер, т.е. объема редо-информации, генерируемой в единицу времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 18:04 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
>>> Значит если размер буфера будет слишком большим, значит он сможет долго не делать сброс в файл - это значит меньше лишних дисковых операций. Но с другой стороны перед переключением будет накоплена большая порция и непосредственно в момент переключения будет "затор". No ne bolee 1MB, t.k. iz log bufera danniy sbrasivautsya v redo log: -- commit transaction -- 1/3 log buffer full -- 1 MB log buffer full ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2002, 20:08 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
Можно подробнее по 1Mb - откуда эта цифра растёт, источники? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2002, 13:35 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
>>No ne bolee 1MB, t.k. iz log bufera danniy sbrasivautsya v redo log: -- commit transaction -- 1/3 log buffer full -- 1 MB log buffer full значит, если подходить формально, log buffer нет смысла делать больше 3МБ. 2softbuilder Я имел ввиду что 'Checkpoint not complete' говорит о том что LGWR ждет CKPT or DBWR, а ARCH в любом случае ни при чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2002, 15:27 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
Про 1МБ есть в http://www.ixora.com.au/tips/tuning/log_buffer_size.htm, а сам Oracle молчит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2002, 15:35 |
|
||
|
Checkpoint not complete
|
|||
|---|---|---|---|
|
#18+
Pro 1 MB yavno propisano v Oracle ITL Viderrgka in Oracle fundamental I (9i) How Redo Logs Work The Oracle server sequentially records all changes made to the database in the redo log buffer. The redo entries are written from the redo log buffer to one of the online redo log groups called the current online redo log group by the LGWR process. LGWR writes under the following situations: -- When a transaction commits -- When the redo log buffer becomes one-third full -- When there is more than a megabyte of changed records in the redo log buffer -- Before the DBWn writes modified blocks in the database buffer cache to the data files Redo logs are used in a cyclic fashion. Each redo log file group is identified by a log sequence number that is overwritten each time the log is reused. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2002, 18:16 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=32078055&tid=1992481]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
156ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 478ms |
| 0 / 0 |
