Читаю книгу Том Клайта про Oracle и там пишет про "checkpoint not complete", и решил глянуть в базе есть подобная запись или нет и оказалась, что присутствует, почитал в других источников про это сообщение и все как один пишут, что это сообщение грозит серьезным последствиям при попытки восстановление БД в случае сбоя и требует внимания админа.

Решение конечно есть, но опять же ссылаясь на том клайта они пишет что панацея это вкл асинхроный режим для ввода\вывода в базе данных, у меня включен как оказалось.

И есть еще решение добавить redo logs, но это как он пишет временное решение.

Вопрос кто уже сталкивался с такой проблемой?
И как ее решил?

склеротик_SAS2014Вопрос кто уже сталкивался с такой проблемой?
И как ее решил?

когда мне нехрен делать я набираю здесь в поиске: checkpoint not complete и читаю до опупения.

молодец, а когда я прочитал инфу, а теперь хочу знать кто с такой проблемой сталкивался и как решил ..

123ййSAS2014Читаю книгу Том Клайта про Oracle
если не секрет, кто это такой ?
эксперт в области в области СУБД

проходил мимо...SAS2014,

у того, который эсперт, нет буквы "л" в фамилии.

ну да Кайт, Л лишняя согласен, но сутьи не меняет... то кто читал книгу поняли меня о ком я

проходил мимо...SAS2014,

с таким отнощением к имени автора совсем не факт, что вы правильно прочитали написанное в книге.
т.е. проблемы с checkpoint not complete действительно бывают, но к сбоям и восстановлениям они в достаточной мере параллельны.
мой вам совет - прочтите ещё раз и внимательней.
а зачем, когда и как с этим бороться на форуме действительно обсуждалось десятки раз.

если хотите можете прочитать и написать свое мнение

проходил мимо...давайSAS2014,

да я-то читал.
в первый раз - почти 15 лет назад :)
давайте сюда цитату, которая, с вашей точки зрения, означает опасность для восстановления после сбоя, и мы продолжим диалог. да, цитату лучше из оригинала, а не перевода, а то у нас бывают такие переводчики...

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

StaxSAS2014Решение конечно есть, но опять же ссылаясь на том клайта они пишет что панацея это вкл асинхроный режим для ввода\вывода в базе данных, у меня включен как оказалось.

авторДля решения этой проблемы можно сделать следующее.
• Ускорить работу процесса DBWR. Пусть администратор базы данных настроит
процесс DBWR: включит поддержку асинхронного ввода/вывода, используя под-
чиненные процессы ввода/вывода DBWR или запустив несколько процессов
DBWR. Посмотрите на статистическую информацию о вводе/выводе в системе —
может обнаружиться "горячий" диск или ряд дисков, ввод/вывод на которые надо
распределить. Такой же общий совет относится и к процессу ARCH. Преимуще-
ство этого решения в том, что оно "бесплатное" — повышение производительно-
сти достигается без изменения логики/структур/кода. Недостатков у него по сути
нет.
• Добавить файлы в журнал повторного выполнения. Это отсрочит возникновение
сообщений Checkpoint not complete, причем, после добавления определенного ко-
личества — настолько, что они вообще не будут выдаваться (у процесса DBWR
появляется пространство для обработки контрольной точки). Это же относится и
к сообщению Archival required. Преимущество этого подхода — устранение "пауз"
в работе системы. Недостаток — требуется больше дискового пространства, но пре-
имущество в данном случае намного перевешивает недостаток.
• Пересоздать файлы журнала, сделав их больше. Это отсрочит заполнение актив-
ного файла журнала повторного выполнения и увеличит период времени, после
которого он снова понадобится. Это решает и проблему с выдачей сообщений
Archival required, если файлы журнала повторного выполнения используются в
"пульсирующем" режиме. Если за периодами интенсивного генерирования дан-
ных повторного выполнения (еженощные загрузки данных, пакетная обработка)
следуют периоды относительного затишья, увеличив активные журналы повтор-
ного выполнения, можно дать процессу ARCH дополнительное время для рабо-
ты в периоды затишья. Преимущества и недостатки этого подхода те же, что и в
случае добавления файлов. Кроме того, может быть отсрочена обработка конт-
рольной точки, поскольку она выполняется при переходе с одного логического
журнала на другой, а переключения будут происходить реже.
• Вызвать более частую и постоянную обработку контрольной точки. Для этого можно
уменьшить буферный кэш (что вообще-то нежелательно) или изменить значения не-
которых параметров инициализации, в частности FAST_START_IO_TARGET,
DB_BLOCK_MAX_DIRTY_TARGET, LOG_CHECKPOINT_INTERVAL и
LOG_CHECKPOINT_TIMEOUT. Это приведет к более частому сбросу грязных
блоков на диск процессом DBWR. К преимуществам этого подхода можно отне-
сти уменьшение времени восстановления в случае сбоя. Будет оставаться меньше
изменений в активных журналах повторного выполнения для сброса на диск. Не-
достаток же в том, что блоки будут записываться на диск чаще. Буферный кэш
будет работать с меньшей эффективностью, да и весь описанный далее механизм
очистки блоков может при этом пострадать.
Выбор подхода зависит от обстоятельств. Эту проблему надо решать на уровне всей
базы данных, с учетом работы экземпляра в целом.


спс за инфу

Думаю тему можно закрыть!

склеротик_SAS2014Думаю тему можно закрыть!
неужели ты понял ,что зря вообще ее открывал?

когда нечего сказать по делу можно просто написать что-нибудь, даже если это не к месту