Проблема с запуском Оракловой базы : Oracle

Прошу извинить за повтор темы, но уменя следующая проблема.
1. После того как, былла остановлена БД и соотв. службы СМ2000 и сделан Backup (который тоже сформировался криво), не может стартануть БД. На Open в DBA Studio, ругается :
ошибка ORA-03113 принят сигнал конца файла по коммуникационному каналу.

Пытаюсь удалить RBS -ы как рекомендовано не то, чтобы получается. Команда описанная в bat- нике раздела Программирование не очень понятна (каюсь чайник)

НИЧЕГО НЕ УДАЛЯЙТЕ! Успеете еще. Есть каталог \bdump в оракловой директории, в нем alert.log (созвучное название) давайте посмотрим, что в нем. Лучше всего переименовать его в другой файл, попробовать запустить базу и посмотреть, что в новом файле. Если есть кого параллельно послать сделать удаленку - посылаем, если нет - разбираем файлы.

После исправления в ini...ora rollback_segments на _corrupted,
база стартанула в ней идет ругань на RBS01 ORA03113.
Пересоздал RBS01 вернул назад параметр rolback_segments в ini.ora
база опять не стартует с той же ошибкой.

а все таки, 3113 - это внешнее проявление, что пишется в alert.log? На _corrupted рекомендуется переводить, если уже экспорт собрались делать.

ORA-01599
failed to acquire rollback segment (string), cache space is full
Cause
The amount statically allocated is not enough based on the value of the MAX_ROLLBACK_SEGMENTS parameter.
Action
For now, take another rollback segment offline or increase the value of the parameter MAX_ROLLBACK_SEGMENTS.

Вроде заработало. Большое спасибо.
Но есть еще один вопрос. В инициализационном файле в параметре rollback_segments перечисляются все существующие сегменты. Но при ручном создании дополнительных сегментов, эта строчка не обновляется. Вот и возник вопрос - нужно ли в этот параметр добавлять новые сегменты? И если нужно, то чем может грозить их не добавление?

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

Здравствуйте!!!
Проблема один в один:
вот мой alert.log
Dump file d:\ORACLE\admin\DIMON\bdump\dimonALRT.LOG
Mon May 28 15:24:25 2012
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.0 Service Pack 4, CPU type 586
Starting up ORACLE RDBMS Version: 8.1.6.3.0.
System parameters with non-default values:
processes = 150
shared_pool_size = 65399000
large_pool_size = 614400
java_pool_size = 32768
db_file_direct_io_count = 128
control_files = d:\ORACLE\oradata\DIMON\control01.ctl, d:\ORACLE\oradata\DIMON\control03.ctl, d:\ORACLE\oradata\DIMON\control02.ctl
db_block_buffers = 63864
db_block_size = 8192
db_block_lru_latches = 4
db_writer_processes = 2
compatible = 8.1.6
log_buffer = 10485760
log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800
db_files = 1024
db_file_multiblock_read_count= 32
max_rollback_segments = 99
max_enabled_roles = 30
remote_login_passwordfile= EXCLUSIVE
global_names = TRUE
distributed_transactions = 10
instance_name = DIMON
service_names = DIMON
sort_area_size = 8192000
sort_area_retained_size = 4096000
db_name = DIMON
open_cursors = 100
os_authent_prefix =
optimizer_index_cost_adj = 30
optimizer_index_caching = 90
job_queue_processes = 1
job_queue_interval = 60
parallel_max_servers = 5
hash_area_size = 16384000
background_dump_dest = d:\ORACLE\admin\DIMON\bdump
user_dump_dest = d:\ORACLE\admin\DIMON\udump
max_dump_file_size = 10240
oracle_trace_collection_name=
PMON started with pid=2
DBW0 started with pid=3
DBW1 started with pid=4
LGWR started with pid=5
CKPT started with pid=6
SMON started with pid=7
RECO started with pid=8
SNP0 started with pid=9
Mon May 28 15:24:27 2012
alter database mount exclusive
***
Corrupt block relative dba: 0x00000003 file=0. blocknum=3.
Bad check value found during controlfile block read
Data in bad block - type:21. format:2. rdba:0x00000003
last change scn:0xf7ff.001b22f7 seq:0x1 flg:0x04
consistancy value in tail 0x22f71501
check value in block header: 0x6ac, calculated check value: 0x800
spare1:0x0, spare2:0x0, spare2:0x0
LGWR: terminating instance due to error 227
Instance terminated by LGWR, pid = 1316

Подскажите что делать.

Миллион раз писалось, что нужно делать, чтобы не наступать на эти грабли...
Предполагаю, что file=0 это control. Предполагаю так же, что ты скрываешь, какие именно проблемы с железом или софтом еще были. Самое простое - восстанавливаться из бекапа. Для начала покажи, кусок алерта до останова БД и включительно (строчек 50). То, что показал, это сразу так было? Или уже постарался занулять редо? Верни все в состояние "как упало". Но сначала внимательно изучи железо. Что-то не то было.

Для истории: убит винт с БД, бекапы без Users. Восстанавливаться в принципе не из чего.
R.I.P.