25.06.2010 14:59
whitewizard
 
сделал с noresetlogs

ничего не изменилось, собственно :)
25.06.2010 15:00
whitewizard
 
конечно у меня есть копия до начала ковыряния :)
25.06.2010 15:08
kadr
 
Цитата:
whitewizard половина исправилась. теперь все выглядит так:

SVRMGR> connect internal/qqq@vel;
Connected.
SVRMGR> startup mount;
ORACLE instance started.
Total System Global Area 1041454044 bytes
Fixed Size 70620 bytes
Variable Size 549785600 bytes
Database Buffers 491520000 bytes
Redo Buffers 77824 bytes
Database mounted.
SVRMGR> recover database until cancel;
ORA-00279: change 282530336 generated at 06/25/2010 21:26:10 needed for thread 1

ORA-00289: suggestion : C:\ORACLE\ORA81\RDBMS\ARC00001.001
ORA-00280: change 282530336 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
d:\oracle\oradata\veles\redo03.log
Log applied.
Media recovery complete.
SVRMGR> alter database open resetlogs;
Statement processed.
SVRMGR> shutdown;
ORA-03113: end-of-file on communication channel
Зачем тебе после подъема базы делать её остановку?
Поднял базу, вытащил из неё данные, залил в чистую, эту похоронил. Иначе можно в дальнейшем на такой базе ещё голвную боль заработать и вылезет совершенно в неожиданном месте
25.06.2010 15:11
whitewizard
 
так прикол в том, что она поднимается и через пару секунд падает
25.06.2010 15:14
whitewizard
 
и после перезапуска табличные пространства TEMP не очищаются.
мож какая то зависшая транзакция всё ломает?
25.06.2010 15:15
baggio
 
пробуй экспорт импорт...
25.06.2010 15:20
whitewizard
 
экспорт начинает делаться и на exporting roles падает в ORA-03113
25.06.2010 15:33
whitewizard
 
сейчас лог выглядит так:

Dump file D:\ORACLE\admin\VELES\bdump\velesALRT.LOG
Fri Jun 25 22:28:19 2010
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.2 Service Pack 2, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.6.3.0.
System parameters with non-default values:
processes = 150
shared_pool_size = 536870912
large_pool_size = 614400
java_pool_size = 32768
control_files = D:\ORACLE\oradata\VELES\control01.ctl, D:\ORACLE\oradata\VELES\control02.ctl, D:\ORACLE\oradata\VELES\control03.ctl
db_block_buffers = 60000
db_block_size = 8192
compatible = 8.1.6
log_buffer = 32768
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
db_files = 1024
db_file_multiblock_read_count= 8
max_enabled_roles = 30
remote_login_passwordfile= EXCLUSIVE
global_names = TRUE
distributed_transactions = 10
instance_name = VELES
service_names = VELES
sort_area_size = 65536
sort_area_retained_size = 65536
db_name = VELES
open_cursors = 100
ifile = c:\ORACLE\admin\VELES\pfile\initVELES.ora
os_authent_prefix =
job_queue_processes = 3
job_queue_interval = 60
parallel_max_servers = 5
background_dump_dest = D:\ORACLE\admin\VELES\bdump
user_dump_dest = D:\ORACLE\admin\VELES\udump
max_dump_file_size = 10240
oracle_trace_collection_name=
PMON started with pid=2
DBW0 started with pid=3
LGWR started with pid=4
CKPT started with pid=5
SMON started with pid=6
RECO started with pid=7
SNP0 started with pid=8
SNP1 started with pid=9
SNP2 started with pid=10
Fri Jun 25 22:28:22 2010
alter database mount
Fri Jun 25 22:28:26 2010
Successful mount of redo thread 1, with mount id 3561614410.
Fri Jun 25 22:28:26 2010
Database mounted in Exclusive Mode.
Completed: alter database mount
Fri Jun 25 22:28:26 2010
alter database open
Beginning crash recovery of 1 threads
Fri Jun 25 22:28:26 2010
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 2 Seq 38360 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\VELES\REDO02.LOG
Fri Jun 25 22:28:26 2010
Thread recovery: finish rolling forward thread 1
Thread recovery: 19 data blocks read, 19 data blocks written, 41 redo blocks read
Crash recovery completed successfully
Fri Jun 25 22:28:26 2010
Thread 1 advanced to log sequence 38361
Thread 1 opened at log sequence 38361
Current log# 3 seq# 38361 mem# 0: D:\ORACLE\ORADATA\VELES\REDO03.LOG
Successful open of redo thread 1.
Fri Jun 25 22:28:26 2010
SMON: enabling cache recovery
SMON: enabling tx recovery
Fri Jun 25 22:28:27 2010
Completed: alter database open
Fri Jun 25 22:30:25 2010
DBW0: terminating instance due to error 472
Instance terminated by DBW0, pid = 2508
25.06.2010 15:39
baggio
 
может вот это поможет

_ALLOW_RESETLOGS_CORRUPTION = true
_CORRUPTED_ROLLBACK_SEGMENTS = true
_ALLOW_READ_ONLY_CORRUPTION = tue

с данными параметрами сделать resetlog...


Хотя мы по моему все закопались ... я так и не вижу , кто виноват то...
или я что то пропустил? кто знает почему база валится?
25.06.2010 15:44
John Doe
 
в последний раз предлагаю все rbs пересоздать... посмотри в FAQ про потерю роллбеков.

Админ виноват, который до сих пор на 8ке сидит и бекапов не делает.
Часовой пояс GMT +3, время: 10:46.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.