Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
Oracle 10.2 Солярис(спарк)

Задача - перевезти standby-сервер на новое место.
Сценарий, который на тестовых БД, располоденных на одном сервере работал отлично и многократно, но нагрузка на прамари БД там была невольшая:
1. На праймари приостановить (задержать) передачу архлогов на standby
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
После первого переключения журналов alter system switch logfile;
2.Остановить standby БД.
3. Выключить standby-сервер
4.Включить сервер standby-сервер на новом месте через 7 часов, standby БД откроется в реад-онли режиме, т.к. сработают rc-скрипты по автостарту БД.
4*. Запустить транспортировку архлогов с primary
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
Через секунд 30-40 они начали передаваться на standby
5.Запустить режим непрерывного восстановления standby БД.
6. Проверить, как прошла синхронизация баз

За время простоя standby на праймари образовалить архлоги 7484-7495.
Непрерывное восстановление standby запустилось, но не прошло. Были обнаружены дыры в архлогах, я их вручную ликвидировала, потом вручную архлоги регистрировала. Но синхронизации баз так и не добилась. Бросила это из-за нехватки времени.
Вот alert.log standby базы после её startup mount:

автор
Thu Jun 14 18:59:30 2007
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 922746880
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 16777216
sga_target = 8355053568
control_files = /oradata/onyma/control01.ctl, /data/oradata/onyma/control02.ctl, /data2/oradata/onyma/control03.ctl
db_block_size = 8192
__db_cache_size = 7365197824
compatible = 10.2.0.1.0
log_archive_config = DG_CONFIG=(db_main_onyma,db_reserve_onyma)
log_archive_dest_1 = location="/archivelog/onyma/", valid_for=(ONLINE_LOGFILE,ALL_ROLES)
log_archive_dest_2 = SERVICE=db-main-onyma LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db_main_onyma
log_archive_dest_10 = LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db_reserve_onyma
log_archive_dest_state_1 = ENABLE
log_archive_dest_state_2 = ENABLE
log_archive_dest_state_10= ENABLE
log_archive_max_processes= 10
log_archive_min_succeed_dest= 1
standby_archive_dest =
log_archive_trace = 0
log_archive_format = %t_%s_%r.arc
fal_client = db-reserve-onyma
fal_server = db-main-onyma
log_checkpoint_interval = 12800
log_checkpoint_timeout = 120
archive_lag_target = 0
db_file_multiblock_read_count= 16
db_create_file_dest =
db_recovery_file_dest = /flash/onyma
db_recovery_file_dest_size= 397284474880
standby_file_management = AUTO
fast_start_mttr_target = 0
db_flashback_retention_target= 1440
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 300
remote_login_passwordfile= EXCLUSIVE
db_domain =
job_queue_processes = 10
background_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/bdump
user_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/udump
core_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/cdump
audit_file_dest = /opt/oracle/product/10.2.0/admin/onyma/adump
db_name = onyma
db_unique_name = db_reserve_onyma
open_cursors = 300
pga_aggregate_target = 2780823552
dg_broker_start = FALSE
PMON started with pid=2, OS id=5592
PSP0 started with pid=4, OS id=5594
MMAN started with pid=6, OS id=5596
DBW0 started with pid=8, OS id=5598
DBW1 started with pid=3, OS id=5603
LGWR started with pid=5, OS id=5605
CKPT started with pid=10, OS id=5607
SMON started with pid=12, OS id=5609
RECO started with pid=14, OS id=5611
CJQ0 started with pid=16, OS id=5613
MMON started with pid=18, OS id=5615
MMNL started with pid=20, OS id=5617
Thu Jun 14 18:59:38 2007
ALTER DATABASE MOUNT
Thu Jun 14 18:59:42 2007
Setting recovery target incarnation to 1
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=22, OS id=5628
ARC1 started with pid=9, OS id=5630
ARC2 started with pid=24, OS id=5632
ARC3 started with pid=11, OS id=5634
ARC4 started with pid=26, OS id=5636
ARC5 started with pid=13, OS id=5638
ARC6 started with pid=28, OS id=5640
ARC7 started with pid=15, OS id=5642
ARC8 started with pid=30, OS id=5644
Thu Jun 14 18:59:43 2007
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
Thu Jun 14 18:59:43 2007
ARC7: Archival started
ARC9 started with pid=17, OS id=5646
ARC8: Archival started
ARC9: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Thu Jun 14 18:59:43 2007
ARC8: Becoming the 'no FAL' ARCH
ARC8: Becoming the 'no SRL' ARCH
ARC8: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC0: Becoming the heartbeat ARCH
ARC0: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC1: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC2: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC3: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC4: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC5: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC6: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC7: Thread not mounted
Thu Jun 14 18:59:43 2007
ARC9: Thread not mounted
Thu Jun 14 18:59:43 2007
Successful mount of redo thread 1, with mount id 2914097498
Thu Jun 14 18:59:43 2007
Allocated 15933248 bytes in shared pool for flashback generation buffer
Starting background process RVWR
RVWR started with pid=19, OS id=5648
Thu Jun 14 18:59:43 2007
Physical Standby Database mounted.
Completed: ALTER DATABASE MOUNT
Thu Jun 14 19:00:21 2007
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 5798
RFS[1]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
RFS LogMiner: Client disabled from further notification
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 5800
RFS[2]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 5806
RFS[3]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 5802
RFS[4]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 5804
RFS[5]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[6]: Assigned to RFS process 5808
RFS[6]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 5810
RFS[7]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 5814
RFS[8]: Identified database type as 'physical standby'
Thu Jun 14 19:00:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[9]: Assigned to RFS process 5812
RFS[9]: Identified database type as 'physical standby'
Thu Jun 14 19:00:22 2007
db_recovery_file_dest_size of 378880 MB is 10.07% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
RFS[2]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7484_372p062d_.arc'
Thu Jun 14 19:00:32 2007
RFS[9]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7490_372p071y_.arc'
Thu Jun 14 19:00:35 2007
RFS[4]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7485_372p06fz_.arc'
Thu Jun 14 19:01:28 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 19:01:28 2007
Attempt to start background Managed Standby Recovery process (onyma)
MRP0 started with pid=21, OS id=5926
Thu Jun 14 19:01:28 2007
MRP0: Background Managed Standby Recovery process started (onyma)
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7461_36zo3cvh_.arc
Thu Jun 14 19:01:35 2007
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 19:01:54 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7462_36zovt8l_.arc
Thu Jun 14 19:02:12 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7463_36zoxylm_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7464_36zsljz5_.arc
Thu Jun 14 19:02:25 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7465_36zx2tsm_.arc
Thu Jun 14 19:02:38 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7466_3700kjob_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7467_370433nd_.arc
Thu Jun 14 19:02:54 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7468_3707l626_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7469_370c2zfv_.arc
Thu Jun 14 19:03:11 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7470_370go5xh_.arc
Thu Jun 14 19:03:35 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_13/o1_mf_1_7471_370l4qvt_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7472_370mf6lp_.arc
Thu Jun 14 19:04:03 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7473_370opvf8_.arc
Thu Jun 14 19:04:16 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7474_370s5g8t_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7475_370wpbjr_.arc
Thu Jun 14 19:04:29 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7476_371073qk_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7477_3713q1pd_.arc
Thu Jun 14 19:04:42 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7478_3715cm0s_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7479_37177mrs_.arc
Thu Jun 14 19:04:55 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7480_371bq6wf_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7481_371g82kc_.arc
Thu Jun 14 19:05:09 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7482_371kss2j_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7483_371ndpys_.arc
Thu Jun 14 19:05:22 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7484_372p062d_.arc
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7485_372p06fz_.arc
Media Recovery Waiting for thread 1 sequence 7486 (in transit)
Thu Jun 14 19:14:17 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 7490
RFS[10]: Identified database type as 'physical standby'
Thu Jun 14 19:14:18 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_372p06ho_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372p06xt_.arc
Thu Jun 14 19:14:21 2007
Fetching gap sequence in thread 1, gap sequence 7486-7489
Thu Jun 14 19:14:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[11]: Assigned to RFS process 7495
RFS[11]: Identified database type as 'physical standby'
Thu Jun 14 19:14:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[12]: Assigned to RFS process 7497
RFS[12]: Identified database type as 'physical standby'
Thu Jun 14 19:14:21 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[13]: Assigned to RFS process 7499
RFS[13]: Identified database type as 'physical standby'
Thu Jun 14 19:14:54 2007
RFS[12]: File locked log 0 thread 1 sequence 7487
RFS: Forced Shutdown due to RFS_ERROR state
Thu Jun 14 19:15:23 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_372p06d9_.arc
Thu Jun 14 19:20:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[14]: Assigned to RFS process 8287
RFS[14]: Identified database type as 'physical standby'
Thu Jun 14 19:20:24 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_372ptfxp_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372ptg2d_.arc
Thu Jun 14 19:20:27 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[15]: Assigned to RFS process 8292
RFS[15]: Identified database type as 'physical standby'
Thu Jun 14 19:20:27 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[16]: Assigned to RFS process 8294
RFS[16]: Identified database type as 'physical standby'
Thu Jun 14 19:20:28 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_372p06w4_.arc
Thu Jun 14 19:23:27 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[17]: Assigned to RFS process 8594
RFS[17]: Identified database type as 'physical standby'
Thu Jun 14 19:24:28 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_372q5vbw_.arc
Thu Jun 14 19:27:31 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_372qchqs_.arc
Thu Jun 14 19:28:32 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[18]: Assigned to RFS process 9210
RFS[18]: Identified database type as 'physical standby'
Thu Jun 14 19:29:05 2007
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 7486-7489
DBID 2897747444 branch 608908980
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
Thu Jun 14 19:31:32 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 19:32:03 2007
ORA-1153 signalled during: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT...
Thu Jun 14 19:34:32 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[19]: Assigned to RFS process 9942
RFS[19]: Identified database type as 'physical standby'
Thu Jun 14 19:34:33 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372qo0kn_.arc
Thu Jun 14 19:34:34 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[20]: Assigned to RFS process 9947
RFS[20]: Identified database type as 'physical standby'
Thu Jun 14 19:34:34 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[21]: Assigned to RFS process 9949
RFS[21]: Identified database type as 'physical standby'
Thu Jun 14 19:34:34 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[22]: Assigned to RFS process 9951
RFS[22]: Identified database type as 'physical standby'
Thu Jun 14 19:34:35 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_372q5xcd_.arc
Thu Jun 14 19:35:29 2007
alter database recover managed standby database cancel
Thu Jun 14 19:35:30 2007
MRP0: Background Media Recovery cancelled with status 16037
Thu Jun 14 19:35:30 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_5926.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jun 14 19:35:31 2007
Waiting for MRP0 pid 5926 to terminate
Waiting for MRP0 pid 5926 to terminate
Thu Jun 14 19:35:32 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_5926.trc:
ORA-16037: user requested cancel of managed recovery operation
Thu Jun 14 19:35:32 2007
MRP0: Background Media Recovery process shutdown (onyma)
Thu Jun 14 19:35:33 2007
Managed Standby Recovery Canceled (onyma)
Completed: alter database recover managed standby database cancel
Thu Jun 14 19:35:40 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 19:35:40 2007
Attempt to start background Managed Standby Recovery process (onyma)
MRP0 started with pid=21, OS id=10136
Thu Jun 14 19:35:40 2007
MRP0: Background Managed Standby Recovery process started (onyma)
Managed Standby Recovery starting Real Time Apply
Media Recovery Waiting for thread 1 sequence 7486 (in transit)
Thu Jun 14 19:35:46 2007
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 19:37:35 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[23]: Assigned to RFS process 10329
RFS[23]: Identified database type as 'physical standby'
Thu Jun 14 19:38:36 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_372r0c1m_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_372r0dwo_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_372r0bwx_.arc
Thu Jun 14 19:38:46 2007
Fetching gap sequence in thread 1, gap sequence 7486-7489
Thu Jun 14 19:40:07 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[24]: Assigned to RFS process 10618
RFS[24]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[24]: Successfully opened standby log 6: '/oradata/onyma/standby06a.log'
Thu Jun 14 19:40:41 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[25]: Assigned to RFS process 10740
RFS[25]: Identified database type as 'physical standby'
RFS[25]: Successfully opened standby log 7: '/oradata/onyma/standby07a.log'
Thu Jun 14 19:43:47 2007
FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 7486-7489
DBID 2897747444 branch 608908980
FAL[client]: All defined FAL servers have been attempted.
-------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
-------------------------------------------------------------
Thu Jun 14 19:51:24 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
Thu Jun 14 19:51:24 2007
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Error locating archivelog filename '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc': 308
Thu Jun 14 19:51:24 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/udump/onyma_ora_5649.trc:
ORA-00308: cannot open archived log '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Thu Jun 14 19:52:06 2007
Error locating archivelog filename '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc...ДЁ': 308
Thu Jun 14 19:52:06 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/udump/onyma_ora_5649.trc:
ORA-00308: cannot open archived log '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc...ДЁ'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Error locating archivelog filename '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc...ДЁ': 308
Thu Jun 14 19:52:06 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/udump/onyma_ora_5649.trc:
ORA-00308: cannot open archived log '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc...ДЁ'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00308: cannot open archived log '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-308 signalled during: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_MAIN_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_37
Thu Jun 14 19:53:33 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
Thu Jun 14 19:53:33 2007
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Completed: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
Thu Jun 14 19:53:47 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc
Media Recovery Waiting for thread 1 sequence 7487
Fetching gap sequence in thread 1, gap sequence 7487-7489
Thu Jun 14 19:53:58 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[26]: Assigned to RFS process 12277
RFS[26]: Identified database type as 'physical standby'
Thu Jun 14 19:53:58 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[27]: Assigned to RFS process 12279
RFS[27]: Identified database type as 'physical standby'
Thu Jun 14 19:53:58 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[28]: Assigned to RFS process 12281
RFS[28]: Identified database type as 'physical standby'
Thu Jun 14 19:53:59 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372r5zdg_.arc
Thu Jun 14 19:54:15 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc'
Thu Jun 14 19:54:15 2007
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Register archivelog /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7486_371rp2m2_.arc already exists
ORA-16089 signalled during: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_74
Thu Jun 14 19:54:15 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_371w6mjc_.arc'
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Completed: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_371w6mjc_.arc'
Thu Jun 14 19:54:15 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_371zq31j_.arc'
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Completed: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_371zq31j_.arc'
Thu Jun 14 19:54:37 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[29]: Assigned to RFS process 12380
RFS[29]: Identified database type as 'physical standby'
Thu Jun 14 19:58:39 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372s4r8c_.arc
Thu Jun 14 20:09:41 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[30]: Assigned to RFS process 14197
RFS[30]: Identified database type as 'physical standby'
Thu Jun 14 20:12:43 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[31]: Assigned to RFS process 14579
RFS[31]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[31]: Successfully opened standby log 8: '/oradata/onyma/standby08a.log'
Thu Jun 14 20:14:43 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372t261w_.arc
Thu Jun 14 20:23:45 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[32]: Assigned to RFS process 15908
RFS[32]: Identified database type as 'physical standby'
Thu Jun 14 20:23:45 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[33]: Assigned to RFS process 15910
RFS[33]: Identified database type as 'physical standby'
Thu Jun 14 20:28:47 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372twkks_.arc
Thu Jun 14 20:29:35 2007
Shutting down instance: further logons disabled
Thu Jun 14 20:29:35 2007
Stopping background process MMNL
Thu Jun 14 20:29:35 2007
Stopping background process CJQ0
Thu Jun 14 20:29:36 2007
Stopping background process MMON
Thu Jun 14 20:29:41 2007
MRP0: Background Media Recovery cancelled with status 16037
Thu Jun 14 20:29:41 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_10136.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jun 14 20:29:42 2007
Waiting for MRP0 pid 10136 to terminate
Waiting for MRP0 pid 10136 to terminate
Thu Jun 14 20:29:43 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_10136.trc:
ORA-16037: user requested cancel of managed recovery operation
Thu Jun 14 20:29:43 2007
MRP0: Background Media Recovery process shutdown (onyma)
Thu Jun 14 20:29:44 2007
Shutting down instance (immediate)
License high water mark = 13
Thu Jun 14 20:29:44 2007
Stopping Job queue slave processes
Thu Jun 14 20:29:44 2007
Job queue slave processes stopped
Thu Jun 14 20:29:45 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7492_372p0644_.arc
Thu Jun 14 20:29:49 2007
Process OS id : 5798 alive after kill
Errors in file /opt/oracle/product/10.2.0/admin/onyma/udump/onyma_ora_5649.trc
Thu Jun 14 20:29:50 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:30:02 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:30:14 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:30:26 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7493_372p07c7_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_372s4p5m_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7491_372p0708_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7495_372p0mm2_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7494_372p0k52_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_372s4p9k_.arc
Thu Jun 14 20:30:34 2007
ALTER DATABASE CLOSE NORMAL
Thu Jun 14 20:30:34 2007
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
Thu Jun 14 20:30:34 2007
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Thu Jun 14 20:30:39 2007
ARCH shutting down
ARC9: Archival stopped
Thu Jun 14 20:30:43 2007
ARC0: Archival disabled due to shutdown: 1089
Shutting down archive processes
Thu Jun 14 20:30:44 2007
ARCH shutting down
ARC8: Archival stopped
Thu Jun 14 20:30:49 2007
ARCH shutting down
ARC7: Archival stopped
Thu Jun 14 20:30:54 2007
ARCH shutting down
ARC6: Archival stopped
Thu Jun 14 20:30:59 2007
ARCH shutting down
ARC5: Archival stopped
Thu Jun 14 20:31:04 2007
ARCH shutting down
ARC4: Archival stopped
Thu Jun 14 20:31:09 2007
ARCH shutting down
ARC3: Archival stopped
Thu Jun 14 20:31:14 2007
ARCH shutting down
ARC2: Archival stopped
Thu Jun 14 20:31:19 2007
ARCH shutting down
ARC1: Archival stopped
Thu Jun 14 20:31:24 2007
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH shutting down
ARC0: Archival stopped
Thu Jun 14 20:31:27 2007
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Thu Jun 14 20:31:43 2007
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 922746880
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 16777216
sga_target = 8355053568
control_files = /oradata/onyma/control01.ctl, /data/oradata/onyma/control02.ctl, /data2/oradata/onyma/control03.ctl
db_block_size = 8192
__db_cache_size = 7365197824
compatible = 10.2.0.1.0
log_archive_config = DG_CONFIG=(db_main_onyma,db_reserve_onyma)
log_archive_dest_1 = location="/archivelog/onyma/", valid_for=(ONLINE_LOGFILE,ALL_ROLES)
log_archive_dest_2 = SERVICE=db-main-onyma LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db_main_onyma
log_archive_dest_10 = LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db_reserve_onyma
log_archive_dest_state_1 = ENABLE
log_archive_dest_state_2 = ENABLE
log_archive_dest_state_10= ENABLE
log_archive_max_processes= 10
log_archive_min_succeed_dest= 1
standby_archive_dest =
log_archive_trace = 0
log_archive_format = %t_%s_%r.arc
fal_client = db-reserve-onyma
fal_server = db-main-onyma
log_checkpoint_interval = 12800
log_checkpoint_timeout = 120
archive_lag_target = 0
db_file_multiblock_read_count= 16
db_create_file_dest =
db_recovery_file_dest = /flash/onyma
db_recovery_file_dest_size= 397284474880
standby_file_management = AUTO
fast_start_mttr_target = 0
db_flashback_retention_target= 1440
undo_management = AUTO
undo_tablespace = UNDOTBS1
undo_retention = 300
remote_login_passwordfile= EXCLUSIVE
db_domain =
job_queue_processes = 10
background_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/bdump
user_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/udump
core_dump_dest = /opt/oracle/product/10.2.0/admin/onyma/cdump
audit_file_dest = /opt/oracle/product/10.2.0/admin/onyma/adump
db_name = onyma
db_unique_name = db_reserve_onyma
open_cursors = 300
pga_aggregate_target = 2780823552
dg_broker_start = FALSE
....
Thu Jun 14 20:31:57 2007
Successful mount of redo thread 1, with mount id 2914052856
Thu Jun 14 20:31:57 2007
Allocated 15933248 bytes in shared pool for flashback generation buffer
Starting background process RVWR
RVWR started with pid=19, OS id=17003
Thu Jun 14 20:31:57 2007
Physical Standby Database mounted.
Completed: ALTER DATABASE MOUNT
Thu Jun 14 20:32:55 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 20:32:56 2007
Attempt to start background Managed Standby Recovery process (onyma)
MRP0 started with pid=34, OS id=17097
Thu Jun 14 20:32:56 2007
MRP0: Background Managed Standby Recovery process started (onyma)
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7487_371w6mjc_.arc
Thu Jun 14 20:33:02 2007
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
Thu Jun 14 20:33:26 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7488_371zq31j_.arc
Media Recovery Waiting for thread 1 sequence 7489
Fetching gap sequence in thread 1, gap sequence 7489-7489
Thu Jun 14 20:33:36 2007
Using STANDBY_ARCHIVE_DEST parameter default value as USE_DB_RECOVERY_FILE_DEST
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 17165
RFS[1]: Identified database type as 'physical standby'
Thu Jun 14 20:33:36 2007
RFS LogMiner: Client disabled from further notification
db_recovery_file_dest_size of 378880 MB is 10.23% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu Jun 14 20:35:48 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 17487
RFS[2]: Identified database type as 'physical standby'
Thu Jun 14 20:37:52 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_372vh0o5_.arc
Thu Jun 14 20:39:37 2007
ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_3722q97r_.arc'
Thu Jun 14 20:39:37 2007
There are 1 logfiles specified.
ALTER DATABASE REGISTER [PHYSICAL] LOGFILE
Completed: ALTER DATABASE REGISTER PHYSICAL LOGFILE '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_3722q97r_.arc'
Thu Jun 14 20:39:55 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7489_3722q97r_.arc
Thu Jun 14 20:40:06 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 17953
RFS[3]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 9: '/oradata/onyma/standby09a.log'
Thu Jun 14 20:40:20 2007
Media Recovery Log /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7490_372p071y_.arc
Media Recovery Waiting for thread 1 sequence 7491
Fetching gap sequence in thread 1, gap sequence 7491-7500
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 17977
RFS[4]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 17981
RFS[5]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[6]: Assigned to RFS process 17979
RFS[6]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 17985
RFS[7]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 17989
RFS[8]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[9]: Assigned to RFS process 17987
RFS[9]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 17983
RFS[10]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
RFS[4]: Successfully opened standby log 7: '/oradata/onyma/standby07a.log'
Thu Jun 14 20:42:35 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[11]: Assigned to RFS process 18282
RFS[11]: Identified database type as 'physical standby'
RFS[11]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7499_372vzvny_.arc'
Thu Jun 14 20:42:49 2007
RFS[11]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7500_372w05jj_.arc'
Thu Jun 14 20:48:51 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Thu Jun 14 20:48:52 2007
MRP0: Background Media Recovery cancelled with status 16037
Thu Jun 14 20:48:52 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_17097.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jun 14 20:48:53 2007
Waiting for MRP0 pid 17097 to terminate
Waiting for MRP0 pid 17097 to terminate
Thu Jun 14 20:48:55 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_17097.trc:
Media Recovery Waiting for thread 1 sequence 7491
Fetching gap sequence in thread 1, gap sequence 7491-7500
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 17977
RFS[4]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[5]: Assigned to RFS process 17981
RFS[5]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[6]: Assigned to RFS process 17979
RFS[6]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 17985
RFS[7]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 17989
RFS[8]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[9]: Assigned to RFS process 17987
RFS[9]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[10]: Assigned to RFS process 17983
RFS[10]: Identified database type as 'physical standby'
Thu Jun 14 20:40:22 2007
RFS[4]: Successfully opened standby log 7: '/oradata/onyma/standby07a.log'
Thu Jun 14 20:42:35 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[11]: Assigned to RFS process 18282
RFS[11]: Identified database type as 'physical standby'
RFS[11]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7499_372vzvny_.arc'
Thu Jun 14 20:42:49 2007
RFS[11]: Archived Log: '/flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7500_372w05jj_.arc'
Thu Jun 14 20:48:51 2007
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Thu Jun 14 20:48:52 2007
MRP0: Background Media Recovery cancelled with status 16037
Thu Jun 14 20:48:52 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_17097.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jun 14 20:48:53 2007
Waiting for MRP0 pid 17097 to terminate
Waiting for MRP0 pid 17097 to terminate
Thu Jun 14 20:48:55 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_17097.trc:
Thu Jun 14 20:53:59 2007
Shutting down instance: further logons disabled
Thu Jun 14 20:53:59 2007
Stopping background process MMNL
Thu Jun 14 20:53:59 2007
Stopping background process CJQ0
Thu Jun 14 20:54:00 2007
Stopping background process MMON
Thu Jun 14 20:54:04 2007
MRP0: Background Media Recovery cancelled with status 16037
Thu Jun 14 20:54:04 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_19090.trc:
ORA-16037: user requested cancel of managed recovery operation
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Thu Jun 14 20:54:05 2007
Waiting for MRP0 pid 19090 to terminate
Thu Jun 14 20:54:06 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_mrp0_19090.trc:
ORA-16037: user requested cancel of managed recovery operation
Thu Jun 14 20:54:06 2007
MRP0: Background Media Recovery process shutdown (onyma)
Waiting for MRP0 pid 19090 to terminate
Thu Jun 14 20:54:07 2007
Shutting down instance (immediate)
License high water mark = 11
Thu Jun 14 20:54:07 2007
Stopping Job queue slave processes
Thu Jun 14 20:54:07 2007
Job queue slave processes stopped
Thu Jun 14 20:54:07 2007
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7492_372vvp86_.arc
Thu Jun 14 20:54:12 2007
Process OS id : 17981 alive after kill
Errors in file /opt/oracle/product/10.2.0/admin/onyma/udump/onyma_ora_17004.trc
Thu Jun 14 20:54:12 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:54:24 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:54:36 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Thu Jun 14 20:54:48 2007
PMON failed to acquire latch, see PMON dump
PMON failed to acquire latch, see PMON dump
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7494_372vvq0z_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7495_372vvpyk_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7493_372vvp1t_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7491_372vvptm_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7498_372vw36z_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7496_372vvprw_.arc
Deleted Oracle managed file /flash/onyma/DB_RESERVE_ONYMA/archivelog/2007_06_14/o1_mf_1_7497_372vvpw9_.arc
Thu Jun 14 20:54:56 2007
ALTER DATABASE CLOSE NORMAL

Что я делала не так?
15 июн 07, 11:36    [4271114]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Не по теме.

PMON failed to acquire latch, see PMON dump
Патчик бы приложить, чтобы инстанс не вешался после shutdown immediate.
15 июн 07, 14:38    [4272718]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DВА
Member

Откуда:
Сообщений: 5439
1. настроить fal_client, fal_server
стендбай после запуска наката сам идентифицирует пропущенные логи и тянет их с примари

2. ручками переписать логи и запустить recover standby database до синхронизации, после этого вернуться в режим standby managed
15 июн 07, 14:46    [4272784]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
GL
Member

Откуда: Харьков
Сообщений: 1513
Aliona
Что я делала не так?
На стендбае точно правильно проставлен FAL_SERVER и с TNSNAMES всё в порядке? В смысле, после переезда его не забыли поправить?
Ещё вопрос, на примари архивлоги ещё не были удалены? Например, как заархивированные RMAN'ом при недостатке места в RECOVERY_FILE_DEST?
И последнее, а зачем вам столько ARCx процессов?
15 июн 07, 14:52    [4272840]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
DВА
1. настроить fal_client, fal_server
стендбай после запуска наката сам идентифицирует пропущенные логи и тянет их с примари

2. ручками переписать логи и запустить recover standby database до синхронизации, после этого вернуться в режим standby managed


1.fal_client, fal_server настроены.
Я пределала стэндбай их холодного бэкапа.
Всё прекрасно работает, праймари или стээндбай останавливаю, запускаю все накатывается, параметы никакие не меняла.

2. я и писала, что обнаруженную дыру архлогов я ркчкаит переписала, их зарегистрировала, заново запускада процесс восстановления.
Это в приложенном протоколе видно.
15 июн 07, 15:33    [4273195]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
GL
Aliona
Что я делала не так?
На стендбае точно правильно проставлен FAL_SERVER и с TNSNAMES всё в порядке? В смысле, после переезда его не забыли поправить?
Ещё вопрос, на примари архивлоги ещё не были удалены? Например, как заархивированные RMAN'ом при недостатке места в RECOVERY_FILE_DEST?
И последнее, а зачем вам столько ARCx процессов?


не в параметрах FAL_SERVER и не TNSNAMES причина, Я пределала стэндбай их холодного бэкапа.
Всё прекрасно работает, я в этом и не сомневалась.
15 июн 07, 15:36    [4273229]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DВА
Member

Откуда:
Сообщений: 5439
Aliona
Всё прекрасно работает, я в этом и не сомневалась.

а в чем тогда проблемы?
15 июн 07, 15:42    [4273293]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Может быть вам это тоже как-то поможет.
В 10g есть еще вот такая возможность как
Using Incremental Backups to Refresh a Standby Database


автор

RMAN enables you to synchronize a standby database with a primary database by creating an incremental backup at the source database that contains all changed blocks since the duplicate was created or last refreshed. You then apply the incremental backup to the standby database, which updates it with all changes.
15 июн 07, 15:47    [4273359]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
EugeneS
Может быть вам это тоже как-то поможет.
В 10g есть еще вот такая возможность как
Using Incremental Backups to Refresh a Standby Database


автор

RMAN enables you to synchronize a standby database with a primary database by creating an incremental backup at the source database that contains all changed blocks since the duplicate was created or last refreshed. You then apply the incremental backup to the standby database, which updates it with all changes.

Очень полезная инфа.
Спасиба !
15 июн 07, 15:53    [4273432]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
DВА
Aliona
Всё прекрасно работает, я в этом и не сомневалась.

а в чем тогда проблемы?

Проблема в том сценарии, который я описала.
Почему он не сработал
15 июн 07, 16:23    [4273661]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DВА
Member

Откуда:
Сообщений: 5439
сложно сказать...
по идее, даже без ручной переброски логов и их регистрации, стендбай должен был обнаружить gap и перетянуть логи с примари. Но не смог и выдал ошибку

FAL[client]: Failed to request gap sequence
GAP - thread 1 sequence 7486-7489
DBID 2897747444 branch 608908980
FAL[client]: All defined FAL servers have been attempted

90% что fal_server и fal_client настроены неверно... либо сетевые проблемы с доступом.

По идее, вам достаточно было накатить отсутствующие логи вручную.
15 июн 07, 17:12    [4274088]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
GL
Member

Откуда: Харьков
Сообщений: 1513
DВА
90% что fal_server и fal_client настроены неверно... либо сетевые проблемы с доступом.
Либо по какой-то причине архивных логов не оказалось на примари по пути в LOG_ARCHIVE_DEST_n=LOCATION=(...) Например, из-за забэкапливания их RMAN'ом и недостатка места в DB_RECOVERY_FILE_DEST или из-за ручного переноса их оттуда (мда, сам я понял, что написал ;) например, раз в час...
15 июн 07, 17:26    [4274194]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
вроде был баг
на основной базе,что то вроде этого нужно было сделать, после длительной потери связи

--запомнить LOG_ARCHIVE_DEST_2
alter system set LOG_ARCHIVE_DEST_2='';

alter system set LOG_ARCHIVE_DEST_2='венруть назад';
15 июн 07, 18:11    [4274572]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
DimaR
вроде был баг
на основной базе,что то вроде этого нужно было сделать, после длительной потери связи

--запомнить LOG_ARCHIVE_DEST_2
alter system set LOG_ARCHIVE_DEST_2='';

alter system set LOG_ARCHIVE_DEST_2='венруть назад';


Т.е. вы хотите сказать, что этих команд не достаточно:
1. На праймари приостановить (задержать) передачу архлогов на standby
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
...
4*. Запустить транспортировку архлогов с primary
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Но ведь часть архлогов все-таки переписалась на standby, а часть нет.
18 июн 07, 17:06    [4281547]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
MaineCoon
Member

Откуда:
Сообщений: 55
Два момента неясно.
1. gap-ы тоже просто так не возникают. По крайней мере, я наблюдал такое только раз по причине собственной ошибки в настройках standby-базы. Предполагается какая-то регулярная беда с сетью? Не проверяли? Это все с учетом, что настройки FAL, имен и путей не менялись/не ломались.

2. Имеется опыт остановки синхронизации почти на сутки без каких либо манипуляций с log_archive_dest. Никаких последствий, кроме обильной заливки логов после восстановления синхронизации, не было. Gap-ов, естественно, тоже.
18 июн 07, 17:37    [4281748]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Aliona
DimaR
вроде был баг
на основной базе,что то вроде этого нужно было сделать, после длительной потери связи

--запомнить LOG_ARCHIVE_DEST_2
alter system set LOG_ARCHIVE_DEST_2='';

alter system set LOG_ARCHIVE_DEST_2='венруть назад';


Т.е. вы хотите сказать, что этих команд не достаточно:
1. На праймари приостановить (задержать) передачу архлогов на standby
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
...
4*. Запустить транспортировку архлогов с primary
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;

Но ведь часть архлогов все-таки переписалась на standby, а часть нет.


нет
Был какойто баг, я на 10.2 пару раз сталкивался, передача логов востанавливается именно после манипуляции с LOG_ARCHIVE_DEST_2
(LOG_ARCHIVE_DEST_STATE_2 я так навсякий случай привел)

но не факт что у вас тоже самое
18 июн 07, 17:55    [4281873]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
С сетью проблемы скорее всего были. вот alert.log c праймари бд:
Thu Jun 14 18:55:10 2007
ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH;
Thu Jun 14 18:55:21 2007
Error 12514 received logging on to the standby
Thu Jun 14 18:55:21 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc6_14767.trc:
ORA-12514: TNS:listener does not currently know of service requested in connect descriptor
PING[ARC6]: Heartbeat failed to connect to standby 'db-reserve-onyma'. Error is 12514.
Thu Jun 14 19:09:12 2007
ARC7: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC7: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:09:12 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc7_14769.trc:
ORA-03135: connection lost contact
Thu Jun 14 19:09:13 2007
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:09:13 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc1_14757.trc:
ORA-03135: connection lost contact
Thu Jun 14 19:09:14 2007
ARC4: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC4: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:09:14 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc4_14763.trc:
ORA-03135: connection lost contact
Thu Jun 14 19:09:16 2007
FAL[server, ARC1]: FAL archive failed, see trace file.
Thu Jun 14 19:09:16 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc1_14757.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:09:16 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:09:16 2007
ARC6: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC6: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:09:16 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc6_14767.trc:
ORA-03135: connection lost contact
Thu Jun 14 19:09:16 2007
FAL[server, ARC4]: FAL archive failed, see trace file.
Thu Jun 14 19:09:16 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc4_14763.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:09:16 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:09:17 2007
FAL[server, ARC7]: FAL archive failed, see trace file.
Thu Jun 14 19:09:17 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc7_14769.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:09:17 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:09:17 2007
FAL[server, ARC6]: FAL archive failed, see trace file.
Thu Jun 14 19:09:17 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc6_14767.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:09:17 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:09:17 2007
ARC0: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC0: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:09:17 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc0_14755.trc:
ORA-03135: connection lost contact
FAL[server, ARC0]: FAL archive failed, see trace file.
Thu Jun 14 19:09:18 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc0_14755.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:09:18 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:12:37 2007
Thread 1 advanced to log sequence 7497
Current log# 1 seq# 7497 mem# 0: /oradata/onyma/redo01a.log
Current log# 1 seq# 7497 mem# 1: /data/oradata/onyma/redo01b.log
Current log# 1 seq# 7497 mem# 2: /data2/oradata/onyma/redo01c.log
Thu Jun 14 19:13:26 2007
ARC9: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC9: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:13:26 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc9_14773.trc:
ORA-03135: connection lost contact
FAL[server, ARC9]: FAL archive failed, see trace file.
Thu Jun 14 19:13:29 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc9_14773.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:13:29 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:14:24 2007
ARC3: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3135)
ARC3: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:14:24 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc3_14761.trc:
ORA-03135: connection lost contact
FAL[server, ARC3]: FAL archive failed, see trace file.
Thu Jun 14 19:14:24 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc3_14761.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
Thu Jun 14 19:14:24 2007
ORACLE Instance onyma - Archival Error. Archiver continuing.
Thu Jun 14 19:14:54 2007
ARC0: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (16040)
ARC0: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Thu Jun 14 19:14:54 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc0_14755.trc:
ORA-16040: standby destination archive log file is locked
FAL[server, ARC0]: Error 16040 creating remote archivelog file 'db-reserve-onyma'
FAL[server, ARC0]: FAL archive failed, see trace file.
Thu Jun 14 19:14:54 2007
Errors in file /opt/oracle/product/10.2.0/admin/onyma/bdump/onyma_arc0_14755.trc:
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing
....
18 июн 07, 17:56    [4281879]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
если дыры образовались, то как их ликвидировать?
Кто-то писал, накатить вручную. Что это значит? поясните, пожалуйста.
18 июн 07, 17:58    [4281895]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
juks@gala.net
Member

Откуда: Киев
Сообщений: 4212
Aliona
если дыры образовались, то как их ликвидировать?
Кто-то писал, накатить вручную. Что это значит? поясните, пожалуйста.

Если есть логи переписать их вручную и накатить командой
recover standby database
Если уже нет. Накатить инкрементальный бекап. Или
сделать полный бекап РМАНом и с новым стендбайным контролфайлом восстановить
командой restore.Дальше recoever managed standby database.
18 июн 07, 18:13    [4281995]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
juks@gala.net
Aliona
если дыры образовались, то как их ликвидировать?
Кто-то писал, накатить вручную. Что это значит? поясните, пожалуйста.

Если есть логи переписать их вручную и накатить командой
recover standby database
Если уже нет. Накатить инкрементальный бекап. Или
сделать полный бекап РМАНом и с новым стендбайным контролфайлом восстановить
командой restore.Дальше recoever managed standby database.


Алена, вы специально все грабли по пути собираете??

Я вам уже писал - сделайте стендбай СТАНДАРТНО и через OEM и не надо будет задавать странных вопросов. все что нужно будет делать в вашем случае - это выключить стендбай сервер (хоть питанием), перевезти его и включить назад. Через пару часов все само синхронизуется куда надо, и даже база САМА встает в нужный режим, и FAL отрабатывает как нужно САМ... Ну НИЧЕГО ВООБЩЕ делать не нужно. Зачем что то приостанавливать, что то руками запускать, какие то рекавери трогать... У вас же стендбай, и у вас же DataGuard, ну там НИЧЕГО руками делать не нужно по идее.

Он же сам должен дыры ликвидировать. Если это не происходит, то значит у вас неверно что то настроено. Естественно, можно просто с бэкапа еще раз поставиться, но я никак не пойму - у вас там стоит задача по изучению стендбая или все таки нужно _ехать а не шашечки?_

Почему то при использовании стандартных путей таких вопросов вообще не возникало - там все уже предусмотрено, а если даже и нет - так одной кнопкой все пересоздается еще раз... А изучать как оно там устроено лучше на кошечках, то бишь в лабе, а не на рабочих серверах при переезде.

(Серверы я не перетаскивал... Но выключал и включал через два часа тестовый сервер в лабе, при постоянной нагрузке на праймари... Ничего, повисела в режиме _не синхронизованы_, как то там стартовала сама подтаскивание логов, и через где то с полчаса - час синхронизовалась... И при старте базы она сама видит что это стендбай и стартует рекавери а не открывает ее... Я еще понимаю сценарий _оба сервера убило молнией, и через 2 часа удалось поднять стендбай - как теперь восстановить все при неработающем праймери и аварийном падении стендбая.... а уж штатная то операция - выключение стендбая на хоть полсуток - проблем вызвать не должна... Странно все там у вас.)
18 июн 07, 22:21    [4282630]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Alex Roudnev
а уж штатная то операция - выключение стендбая на хоть полсуток - проблем вызвать не должна... Странно все там у вас.)


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

недели 3 назад, уже на рабочей базе, я пересоздавал стендбай из бекапа, работающая база упорно не хотела передавать логи, пока опять не переопределил параметры LOG_ARCHIVE_DEST_2 в '' и обратно
19 июн 07, 11:22    [4284301]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
DВА
Member

Откуда:
Сообщений: 5439
DimaR
недели 3 назад, уже на рабочей базе, я пересоздавал стендбай из бекапа, работающая база упорно не хотела передавать логи, пока опять не переопределил параметры LOG_ARCHIVE_DEST_2 в '' и обратно

аналогично :)
во время создания стендбая сделала 2 инстанса, один принимал логи с примари, второй разворачивал бэкап... Когда бэкап развернулся стала переключать передачу на второй, логи не пошли. Провозилась пол-ночи, переопределить LOG_ARCHIVE_DEST не сообразила... списала все на собственный сдвиг по фазе ввиду недосыпания :) и подсунула базу тому инстансу который уже был согласен принимать логи.
19 июн 07, 11:44    [4284536]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
MacDuck
Member

Откуда: Москва-Подольск
Сообщений: 6387
Alex Roudnev
и через OEM


Ты уверен, что у нее GC стоит?
19 июн 07, 11:51    [4284622]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
Aliona
Member

Откуда: Питер
Сообщений: 4023
Алена, вы специально все грабли по пути собираете??

Я вам уже писал - сделайте стендбай СТАНДАРТНО и через OEM и не надо будет задавать странных вопросов.

А я вам уже 100 раз писала, что OEM у меня нет и поставить его некуда.
19 июн 07, 11:57    [4284693]     Ответить | Цитировать Сообщить модератору
 Re: Oracle 10g, остановка Standby на 7 часов и последующая синхронизация?  [new]
GL
Member

Откуда: Харьков
Сообщений: 1513
Aliona
Алена, вы специально все грабли по пути собираете??

Я вам уже писал - сделайте стендбай СТАНДАРТНО и через OEM и не надо будет задавать странных вопросов.

А я вам уже 100 раз писала, что OEM у меня нет и поставить его некуда.
Тогда изучайте Data Guard Broker - по моему опыту даже более удачное решение возникающих проблем, чем OEM. Т.е. для того, чтобы сделать стендбай, необходимо только настроить брокера, чуть (ЧУТЬ!) подправить pfile, создать standby-контролфайл и развернуть бэкап основной базы на стендбае. Да, RMAN DUPLICATE не люблю, а так можно было бы и без всех этих пунктов обойтись...
19 июн 07, 13:44    [4285633]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить