|
|
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
Доброго времени, суток, Так случилось, что затопило серверную, естественно туда куда шли бэкапы тоже не вытащить, остался жесткий диск с самой базой, которая естественно некорректно выключилась. Теперь пытаюсь её поднять на другом компе, в общем делаю следующее, создаю сервис меняю init.ora на новые пути, но видимо этого недостаточно. >oradim -new -sid temp -pfile c:\oracle\temp\init.ora >set ORACLE_SID=temp > sqlplus "/ AS SYSDBA" На этой строке ошибка, проверил все пути файлы все присутствуют ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Идентификатор процесса: 0 Идентификатор сеанса: 0 Порядковый номер: 0 Как я полагаю, идет ошибка в коррекции init.ora, ткните носом что не так делаю. инит ############################################################################## # Copyright (c) 1991, 2001, 2002 by Oracle Corporation ############################################################################## ########################################### # Cache and I/O ########################################### db_block_size=8192 ########################################### # Cursors and Library Cache ########################################### open_cursors=300 ########################################### # Database Identification ########################################### db_domain="" db_name=DBDIM ########################################### # File Configuration ########################################### control_files=("d:\Database\DBDIM\control01.ctl", "d:\app\administrator\flash_recovery_area\DBDIM\control02.ctl") db_recovery_file_dest=d:\app\administrator\flash_recovery_area db_recovery_file_dest_size=4102029312 ########################################### # Miscellaneous ########################################### compatible=11.2.0.0.0 diagnostic_dest=d:\app\administrator memory_target=4214226944 ########################################### # NLS ########################################### nls_language="RUSSIAN" nls_territory="RUSSIA" ########################################### # Processes and Sessions ########################################### processes=300 sessions=335 ########################################### # Security and Auditing ########################################### audit_file_dest=d:\app\administrator\admin\DBDIM\adump audit_trail=db remote_login_passwordfile=EXCLUSIVE ########################################### # Shared Server ########################################### dispatchers="(PROTOCOL=TCP) (SERVICE=DBDIMXDB)" ########################################### # System Managed Undo and Rollback Segments ########################################### undo_tablespace=UNDOTBS1 Разница только в оперативной памяти... Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2018, 18:58 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
Естественно орадим выполняю так, где хранится сам spfile: oradim -new -sid DBDIM -pfile D:\Database\DBDIM\init.ora ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2018, 19:00 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
В общем удалось все инициализировать и база поднялась, но осталась еще ошибка: Errors in file c:\database\diag\rdbms\dbdim\dbdim\trace\tdpra_cjq0_2344.trc: ORA-00604: ошибка на рекурсивном SQL-уровне 1 ORA-06544: PL/SQL: внутр.ошибка, аргументы: [56327], [], [], [], [], [], [], [] ORA-06553: PLS-801: внутр.ошибка [56327] И не получается законнектится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2018, 20:02 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
Relic Hunter, Ну и зачем мне эта ссылка. Достаточно было запустить в migrated, всё заработало, всё взлетело! ORA-06553: PLS-801: internal error [56327] I now have a datafile from windows 2008 (X64) cold standby out above, now I put him to restore to win7 (X86) machine, the database version is 11R2, restored startup is fine, but the connection and execution sql statement will be reported when: SQL> conn user / userpassword ERROR: ORA-00604: recursive SQL level 1 error ORA-06553: PLS-801: internal error [56327] ORA-06553: PLS-801: internal error [56327] An error occurred while accessing the package DBMS_APPLICATION_INFO Is connected. SQL> --------- Is there any way to solve this problem. Reply: 1, Shutdown immediate 2, startup migrate Note: startup migrate expressed downgrade in 9i, regardless of the upgrade / downgrade databases are startup migrate; 10g parameters added after upgrade, the upgrade can be directly used startup upgrade, downgrade still a startup migrate. 3, @ $ ORACLE_HOME / rdbms / admin / utlirp.sql; 4, Shutdown immediate 5, Startup 6, @ $ ORACLE_HOME / rdbms / admin / utlrp.sql; 7, Shutdown immediate 8, Startup http://www.itpub.net/thread-1117964-1-1.html Try it, in theory, no problem ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.08.2018, 21:05 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
В общем я рано обрадовался, база подключается, пользователи sys, system доступны, созданные мною роли и пользователи тоже доступны, а вот таблицы, пакетники, процедуры и прочее, остались недоступны. Вылетала все та же ошибка. Ибо скрипты отказывались работать, выдавая очередную ошибку. Пришлось копать дальше, нашел следующее решение, которое выполняется успешно без ошибок, пока, пути надо указывать прямые к скриптам, которые начинают уже корректно обрабатывать таблички и приводить их в порядок. SQL> shutdown immediate; SQL> startup upgrade; SQL> @C:\OraBase\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlirp; SQL> shutdown immediate; SQL> startup; SQL> @@C:\OraBase\product\11.2.0\dbhome_1\RDBMS\ADMIN\utlrp; SQL> shutdown immediate; SQL> startup; Вот собственно всё и заработало, разница была в битности ораклов, так как я подымал на виртуалке, собственно и не обратил внимание на битность х32, а база была х64. Да и не предполагал, что возникнет такая проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 00:03 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
kiv-1980, Vadim LejninYuriYurich, Восстанавливай из backup У тебя мусор вместо базы То что произошло - аналог backup базы на горячую ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 00:25 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
Relic Hunter, Какой мусор? Полностью работоспособная база, ни одного некорректного блока и потери, по факту было отключение. Сейчас поднял последний файл temp01.dbf, снялся дамп, все таблички заработали и инициализировались на 100%. В алерте ни одной ошибки. С приведенной Вами ссылкой, моя ситуация, не имеет ничего общего. База заработала! Вопрос снят. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 00:55 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
Обычно после такого чудесного восстановления рекомендуется переделать базу с дампа. Внутри могут быть странные вещи, которые вылезут позже - при апгрейде или накатывании патчей, включении какого-нибудь OLAP и тд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 01:03 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
МутагенОбычно после такого чудесного восстановления рекомендуется переделать базу с дампа. Внутри могут быть странные вещи, которые вылезут позже - при апгрейде или накатывании патчей, включении какого-нибудь OLAP и тд.Может еще порекомендуете ТС.ру бекап делать и УПС поставить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 01:13 |
|
||
|
Восстановление базы 11g
|
|||
|---|---|---|---|
|
#18+
База крутилась на двух SSD которые стояли зеркалом, там где были бэкапы не было зеркала, хотя скорее всего и это не спасло. Так Вот оба SSD в Online (100% живые, туда вода не попала, просто потому, что они маленькие), но система улетела с бэкапами (такое я не мог предположить, форс-мажор). И я просто скопировал эту базу и поднимал на виртуалке, чтобы вытащить данные, первая проблема возникла с ролью ora_dba для доменного пользователя, в правах есть, а он все равно не впускал sql+ as sysdba, полечилось обычным пользователем с правами ora_dba, затем после изменения местоположения, появилась рекурсивная ошибка из-за разности х64 - х32, migrated и upgrated вкупе с переделкой и проверкой таблиц, отработали корректно, все попортил немного temp01.dbf (из-за него часть таблиц были с ошибками и естественно дамп не снимался), но после alter-ов, пары shutdown - startup, он тоже поднялся. Всё, после этого все таблички, процедуры, функции и прочее, без единой ошибки со всеми данными выгрузились в дамп. Первый взгляд и то что успел пройтись, вроде все данные корректны. Видимо хоть тут, немного повезло... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.08.2018, 08:11 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39684543&tid=1883635]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
39ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 324ms |

| 0 / 0 |
