DB_RECOVERY_FILE_DEST_SIZE

Artem.Kvazar
Дата: 09.06.2006 13:47:39
DB_RECOVERY_FILE_DEST_SIZE - кто сталкивался с этим параметром? Как просмотреть его значение, не видя фалй init.ora
Oleg Afanasiev
Дата: 09.06.2006 13:54:30
select * from v$parameter
???


-----------------------
Вечны налоги,
Смерть и потеря данных.
Что на этот раз?
Картинка с другого сайта.
SeaGate
Дата: 09.06.2006 13:55:29
Artem.Kvazar
DB_RECOVERY_FILE_DEST_SIZE - кто сталкивался с этим параметром? Как просмотреть его значение, не видя фалй init.ora

А так:
sho parameter db_recovery_file_dest_size
или
select value,description from v$parameter where name='db_recovery_file_dest_size'
?
Artem.Kvazar
Дата: 09.06.2006 14:00:09
Спасибо, нашёл. Стоит по умаолчанию 2ГГб. Но есть вопрос.
База встала изза того, что лимит исчерпан. Как его обнулить? Удалить файлы журналов повтора? Или увеличить этот параметр?
Oleg Afanasiev
Дата: 09.06.2006 14:10:34
Дока saies

Setting Up and Configuring Backup and Recovery

Setting Up a Flash Recovery Area for RMAN


The DB_RECOVERY_FILE_DEST_SIZE Initialization Parameter

This parameter specifies the maximum storage in bytes of data to be used by the flash recovery area for this database. Note, however, that this value does not include certain kinds of disk overhead:

* Block 0 or the OS block header of each Oracle file is not included in this size. Allow an extra 10% for this data when computing the actual disk usage required for the flash recovery area.
* DB_RECOVERY_FILE_DEST_SIZE does not indicate the real size occupied on disk when the underlying filesystem is mirrored, compressed, or in some other way affected by overhead not known to Oracle. For example, if you can configure the flash recovery area on a normal redundancy (2-way mirrored) ASM disk group, each file of X bytes occupies 2X bytes on the ASM disk group. In such a case, DB_RECOVERY_FILE_DEST_SIZE must be set to no more than 1/2 the size of the disks for the ASM disk group. Likewise, when using a high redundancy (three-way mirrored) ASM disk group, DB_RECOVERY_FILE_DEST_SIZE must be no more than 1/3 the size of the disks in the disk group, and so on.



Artem.Kvazar

а причём тут квазар??
Artem.Kvazar
Дата: 09.06.2006 14:19:03
Artem.Kvazar

а причём тут квазар??[/quot]




Квазары - квазизвездные радиоисточники, внегалактические объекты уникально высокой светимости

А вообще (наверно), не понял вопроса.
MacDuck
Дата: 09.06.2006 14:34:45
Artem.Kvazar
Спасибо, нашёл. Стоит по умаолчанию 2ГГб. Но есть вопрос.
База встала изза того, что лимит исчерпан. Как его обнулить? Удалить файлы журналов повтора? Или увеличить этот параметр?


А это зависит от того что и как ты хочешь. Мало информации для конкретного своета.

Что у тебя там? Flashback logging включен (
select flashback_on FROM v$database;
? Если да, то сколько стоит DB_FLASHBACK_RETENTION_TARGET?
Посмотри сколько сможешь освободить исходя из своих политик удержания:
SELECT space_reclaimable/1024/1024 FROM v$RECOVERY_FILE_DEST;

Проще всего почистить RMAN-поддерживаемые obsolete объекты, если бэкапишься туда.

Хотя общая политика партии (позиция банды Ларри) - все, что тебе нужно, по возможности должно туда вмещаться, т.е. тенденция на увеличение DB_RECOVERY_FILE_DEST_SIZE.
SERG1257
Дата: 09.06.2006 21:38:58
Скорее всего там создаются архивлоги (по умолчанию) соответственно надо их почистить
(запустить бакап скрипт с backup archivelogs delete input)
Увеличение этого параметра только отодвинет проблему.
MacDuck
Дата: 09.06.2006 22:26:18
SERG1257
Скорее всего


Уточняя свой пост + отквоченное:

Радикально прояснить ситуацию поможет v$flash_recovery_area_usage. Наглядно и доступно.