Temat: Problemy

Witam,
jako że forum wydaje się być jak dotąd dość puste, zaproponuję temat który mam nadzieję się przyda.
Czasem trafiamy na problemy na prawdę trudne do rozwiązania i wówczas właściwa informacja jest tym co decyduje o Twoim humorze na końcu dnia i o tym czy ci ludzie wogóle mają po co jutro przychodzić do pracy...

W moim doświadczeniu miała miejsce sytuacja, dzięki której zdobyłem wiedzę z zakresu:
"Jak odzyskać bazę danych MS SQL z pojedynczego pliku mdf, jeśli funkcjonował więcej niż 1 plik logu i oczywiście nie mamy backupu".

Po ciężkich bojach udało się zaprojektować procedurę wykorzystującą wiele nieoficjalnych i nieudokumentowanych informacji o MS SQL, która jest skuteczna w takim przypadku. Oczywiście kluczowe znaczenie mają nieszczęsne pliki logu. Jeśli byłby standartowo jeden - nie ma problemu. W przypadku już dwóch...

No cóż, gdyby ktoś miał podobny problem, to proszę dać znać. Dysponuję odpowiednim rozwiązaniem.


Tomasz Maciej Jabłoński edytował(a) ten post dnia 12.09.06 o godzinie 01:16

Temat: Problemy

Cześć!
Temat jak najbardziej na topie. Przekonałem się o tym dziś. Właśnie spędziam słoneczny dzień na przywracaniu danych z (całe szczęscie) developerskiego serwera Oracle, a zaczęło się niewinnie...
W tablespace UNDO, pomimo jej dużych rozmiarów (30GB) brakło miejsca. Podczas importu dużych ilości danych (ok 120mln rek. w 3 cyklach) otrzymywałem błąd:

O.
ORA-30036: nie można rozszerzyć segmentu o 8 w przestrzeni tabel wycofywania

cóż... zostało przekroczone maksimum 4194303 bloków dla pliku...
Wychodząc problemowi na przciw (nie angażując aministratora bazy ;)) postanowiłem spróbować poszerzyć przestrzeń wycofywania o dodatkowy plik...

ALTER TABLESPACE UNDOTBS1 ADD DATAFILE '/u04/oradata/TEST/undotbs02.dbf' size 5554416K;

Udało się! Niestety błąd ORA-30036 pojawił się ponownie a statystyki pokazywały że mój nowy plik nie jest wogóle używany :(
Wydawało mi się sensowne wyczyszczenie całej zajętej przestrzeni UNDO. Pogrzebałem trochę w dokumentacji i znalazłem odpowiednie polecenia:

S.
ALTER DATABASE DATAFILE '/u04/oradata/TEST/undotbs01.dbf' OFFLINE DROP;

i się zaczęło...
najpierw dostałem komunikat:

O.
ORA-00603: sesja serwera ORACLE zakończona błędem krytycznym

Po ponownym połączeniu baza była niestabilna i co jakiś czas wyskakiwał ten sam komunikat. Statystyki pokazywały że DROP pliku udał się i chociaż przestrzeń jest w trybie ONLINE, plik jest pusty i posiada zerowy rozmiar. Nie pomogły komendy przywracania pliku do stanu poprzedniego.

SQL> ALTER DATABASE DATAFILE '/u04/oradata/TEST/undotbs01.dbf' ONLINE;
ALTER DATABASE DATAFILE '/u04/oradata/TEST/undotbs01.dbf' ONLINE
*
BŁĽD w linii 1:
ORA-01113: plik 2 wymaga zastosowania przywracania noników
ORA-01110: plik danych 2: '/u04/oradata/TEST/undotbs01.dbf'

SQL> Recover datafile '/u04/oradata/TEST/undotbs01.dbf';
ORA-00603: sesja serwera ORACLE zakończona błędem krytycznym

Po próbie przywrócenia pliku sesja została zakończona i nie można było się zalogować poprzez TCP/IP...
Po prostu katastrofa...

Kilka cykli myślowych później analizowałem pliki wykonania backupu bazy na moim lokalnym windowsowym serwerze Oracle XE ;)
Znalazłem takie solution:
Potrzebujemy skryptu który pozowli nam zalogować się do bazy lokalnie a następnie wykonać zapytanie które przełączy naszą przestrzeń w stan ONLINE.

bash-2.05$ echo 'connect / as sysdba;' > foo.sql
bash-2.05$ echo 'set head off' >> foo.sql
bash-2.05$ echo 'set echo off' >> foo.sql
bash-2.05$ echo 'set linesize 515' >> foo.sql
bash-2.05$ sqlplus /nolog @foo.sql
SQL*Plus: Release 9.2.0.6.0 - Production on Sob Wrz 23 14:17:39 2006

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Połšczono.
SQL> ALTER DATABASE DATAFILE '/u04/oradata/TEST/undotbs01.dbf' ONLINE;

Baza danych została zmieniona.

SQL> SELECT FILE_NAME, STATUS, USER_BYTES FROM DBA_DATA_FILES WHERE TABLESPACE_NAME = 'UNDOTBS1';

FILE_NAME
--------------------------------------------------------------------------------
STATUS USER_BYTES
--------- ----------
/u04/oradata/TEST/undotbs01.dbf
AVAILABLE 3,4360E+10

/u04/oradata/TEST/undotbs02.dbf
AVAILABLE 5687607296

Operacja powiodła się i wszystko działa. Ważnym momentem było wykonanie przywrócenia pliku przestrzeni UNDO.

SQL> Recover datafile '/u04/oradata/TEST/undotbs01.dbf';

i chociaż wykonanie tego zapytania spowodowało błąd krytyczny, plik został przywrócony do stanu poprzedniego. Później wystarczyło przywrócić go do stanu ONLINE.

Mam nadzieję, że wnioski z mojej przygody komuś się przydadzą ;)
A ja... mogę iść na spacer. Może spotkam jakąś piękną dziewczynę, która będzie chciała wysłuchać tej historii... heheheheh :D

Pozdrawiam.


Łukasz Schabek edytował(a) ten post dnia 23.09.06 o godzinie 14:59