так... даты нужны более подробные, с указанием времени.
1 В какое время был сделан бэкап 2007-03-23 online?
2 на какое время 2007-03-23 нужно восстановится (т.е. самый последний час када данные в системе еще не были испорчены)?

Смотря как настроен бэкап. Обычно скидываются.
Но сначала посмотри какие есть на диске системы архивные логи. Если нет - ищи на ленте и доставай оттуда их на диск.
логи нужны только те, у которых дата _ПОЗЖЕ_ 2007-03-23 online бэкапа...

пиши icq 161723920

вот, четкий и понятный ответ, спасибо. Ладно, будем восстанавливаться с оффлайна... А докатиться я потом смогу до нужной точки используя онлайн бэкапы?[/quote]

сложно сказать - именно в таком варианте восстанавливать DB я не пробовал, но я склоняюсь к отрицательному ответу, т.к. восстановление из on-line backup-а сопряжено с рядом довольно жестких условий(например, управляющие файлы не архивируются во время on-line -а и не восстанавливаются во время restore из этого backup и т.д.). Дополнительно SAPDBA уже зафиксировал вашу удачную(и не удачную) попытку восстановления. Более того, ахивные redologs помечены как "использованные"(возможно у вас есть их копии - это спасает) и т.д. Возможно придется восстанавливать DB в ручную, не используя SAPDBA, вариантов много...

Во всяком случае - надо пробовать, сообщи потом результаты, очень интересно.

привожу заключительный кусок лога восстановления из оффлайн бэкапа и команды, которые набирал после:

...
BR406I End of file restore: rduyxtql.rsb 2007-04-05 13.11.50
BR280I Time stamp 2007-04-05 13.11.50
BR403I BRRESTORE terminated successfully with warnings

C:\>svrmgrl

Oracle Server Manager Release 3.1.7.0.0 - Production

Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.

Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production

SVRMGR> connect internal;
Connected.
SVRMGR> startup mount;
ORACLE instance started.
Total System Global Area 842450972 bytes
Fixed Size 75804 bytes
Variable Size 344047616 bytes
Database Buffers 497270784 bytes
Redo Buffers 1056768 bytes
Database mounted.
SVRMGR> alter database open resetlogs;
alter database open resetlogs
*
ORA-01139: RESETLOGS option only valid after an incomplete database recovery
SVRMGR> recover database using backup controlfile until cancel;
ORA-00279: change 94988293 generated at 03/18/2007 01:01:43 needed for thread 1
ORA-00289: suggestion : E:\ORACLE\KTS\SAPARCH\KTSARCHARC00049.001
ORA-00280: change 94988293 for thread 1 is in sequence #49
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
^C
C:\>svrmgrl

Oracle Server Manager Release 3.1.7.0.0 - Production

Copyright (c) 1997, 1999, Oracle Corporation. All Rights Reserved.

Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production

SVRMGR> connect internal;
Connected.
SVRMGR> startup mount;
ORACLE instance started.
Total System Global Area 842450972 bytes
Fixed Size 75804 bytes
Variable Size 344047616 bytes
Database Buffers 497270784 bytes
Redo Buffers 1056768 bytes
Database mounted.
SVRMGR> alter database open resetlogs;
Statement processed.
SVRMGR> exit
Server Manager complete.

Усё. Все красиво стартануло.
Вот теперь бы докатиться до нужного состояния. Хотя бы еще 2-3 дня после оффлайн бэкапа восстановить. Это возможно?

DmitryF, почему не читаеш что пишут?
Докатить возможно. Если есть on-line бэкап и архивные логи.
НО. Придется восстановиться с этого on-line бэкапа + накатить архивыне логи до нужного тебе момента.

nazarov_serg303 посмотрите личные сообщения пожалуйста

Всё возможно, если сохранились редологи после того оффлайн бэкапа (от 18 марта) в течение нужных Вам 2-3 дней. И, конечно, если в течение этих 2-3 дней не было resetlogs. Оракловый процесс ACRH копирует редологи не проверяя, что с таким же именем уже есть. Он их просто затирает. Поэтому если было 2 resetlogs с небольшим интервалом, то логи после последнего сброса через небольшое время начнут затирать редологи от предыдущего сброса. Но, надеюсь, это не Ваш случай. Я предполагаю, что попытки восстановления и, соответственно, сбросы номеров редологов у вас начались много позже, а перед этим был долгий период без сброса номеров, так что нужные Вам редологи затереться не успели.

Так что для доката базы до нужного Вам состояния у Вас всё должно быть. Если sapdba не хочет этого делать - не беда, всё можно сделать вручную. Вам надо сделать следующее:

1. Восстановить датафайлы (и только их, контролфайлы восстанавливать не надо) от оффлайн бэкапа 18 марта. Это можно сделать brrestore с опцией '-m all'.
2. Восстановить контролфайлы от последнего онлайн бэкапа до resetlogs (ну на самом деле достаточно, чтоб он был после той даты, на которую вы хотите докатывать базу - то есть от 22 или от 23 марта). sapdba это умеет, в точности не напишу как - под рукой sapdba сейчас нет. Но можно в крайнем случае это сделать ручками.

1 и 2 можно выполнять в любом порядке, главное, чтоб в итоге датафайлы были от 18 марта, а контролфайлы от 22 или от 23.

3. startup mount
4. recover database until time 'YYYYMMDD HH:MM:SS'
5. alter database open resetlogs.

Необходимо сделать ещё пару замечаний:
а) Перед докатом не стоит проверять "как восстановилась база". То есть если вместо "startup mount" вы сделаете "starup;shutdown;startup mount", то толку не будет. Вещь вроде бы очевидная, и на курсах всегда это объясняют, но все оракловые админы на это нарываются обычно по разу :-/.
б) Посмотрите внимательно на даты сохранения редологов. Если Вас устроит время одного из сохранений, то recover предпочтительно делать не 'until time', а 'until cancel' до этого редолога. В этом случае Вы сможете открыть базу с опцией NORESETLOGS. Что сохранит преемственность бэкапов.

написал тебе в аську еще с утра

Это кто вам такое сказал
Control-файлы всегда бэкапятся! Иначе как база придет в состояние mount для доката?


Ой Это кто ж их пометил как "использованные"? а я ни раз докатывался уже "использованными"

диву даешься сколько "сказочников" администрят Oracle

А зачем восстанавливать Control-файлов за 2007-03-19? про "именно возможную", но не необходимую операцию восстановления Control-файла из on-line backup указано в документации:
1. Set Point In Time for Recovery phase

You enter the recovery end-point in BRRECOVER by choosing one of the following:

¡ Point in time

¡ Redo log sequence number

¡ System change number
2. Select Database Backup phase
BRRECOVER determines the eligible backups using the entries in the BRBACKUP summary log file back<DBSID>.log (return code 0 or 1). The associated detail logs show whether the required data files were in the backup. The data files can be compiled from various backups. To minimize the subsequent recovery time, BRRECOVER always suggests the most recent backup.
BRRECOVER also roughly checks the availability of offline redo log files.
You can also select an incremental backup to be restored before applying offline redo log files. In this case, BRRECOVER automatically selects the corresponding full backup to restore all data files.
3. Check Status of Database Files phase
BRRECOVER checks the status of database files to determine which will be overwritten.
4. Restore Control Files phase
BRRECOVER calls BRRESTORE to restore control files if needed, that is, if they are unavailable or unsuitable for the selected backups.

на практике ни разу не возникала необходимость восстанавливать Control-файлы из on-line...

О причинах того, что надо резервировать архивные redologs также выше писал VKB и SAP-AG также настоятельно рекомендует иметь как минимум 2 копии архивных redo-логов.
и с чего бы это?

Господа, пока вы тут спорили, DmitryF походу был порван на клочки
юзерами и начальнегами

зато теперь они знают зачем нужен квалифицированный админ

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

Порядок следующий:
1) вручную достаешь из архива и раскладываешь в соотв. каталоги файлы данных, контр.файл, арх.логи с момента начала восстанавливаемого бэкапа до момента, на который надо восстановиться.
2) startup mount;
3) recover automatic database until cancel using backup controlfile;
или
recover automatic database until time 'ГГГГ-ММ-ДД:ЧЧ:ММ:CC' using backup controlfile;
4) alter database open resetlogs;

В общем всё, база восстановлена.

Примечание: последовательность арх.логов, которые докатываются, не должна прерываться

Прочел ветку и волосы дыбом встали Где таких ламеров набирают?

может быть у "frEd" хватит "волос" ответить на http://sapboard.ru/forum/viewtopic.php?t=25052? А просто так, в холостую, "подымать волосы" в разных местах не имеет смысла...
заранее прошу - не надо впаривать теорию, как это делается оракловскими методами.