Oracle błąd połączenia - ORA-12528, TNS:listener: all appropriate instances are blocking new connections

Witam, nie mogę zalogować się na żadnego użytkownika w BD Oracle.
Na użytkowniku hr sklep:
Status : Failure -Test failed: Listener refused the connection with the following error:
ORA-12528, TNS all appropriate instances are blocking new connections

Na użytkowniku hr dostaję:
Status : Failure -Test failed: Listener refused the connection with the following error:
ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

Wcześniej wszystko działało. Jest ktoś w stanie podpowiedzieć w jaki sposób można to naprawić?

Tutaj może jest problem?

Rozumiem że konfigurowales usera HR? Co to za tns?

Po pierwsze, zamykamy bazę przez shutdown immediate.
Shutdown abort używa się w wyjątkowych sytuacjach.
Rozjechały ci się pliki controlfile, a ich zawartość powinna być taka sama. Żeby nie zepsuć bardziej, zamknij usługę OracleDatabase w Panel Sterowania -> ... Usługi
Potem skopiuj cały katalog ORADATA\ORCL gdzieś na bok, zakładam że masz tam wszystkie pliki danych (zwykle .dbf), controlfile (.ctl) i redo logi (redoXX.log).

Przy zamkniętej bazie nadpisz plik CONTROL02.ctl zawartością pliku CONTROL01.ctl, a potem wystartuj usługę OracleDatabase. Poszukaj pliku alertORCL.log i zobacz czy baza się prawidłowo otworzyła.

Nie mam pliku alertORCL.log

Próbowałem zrobić to za pomocą - ale nic nie dało.
Post: "I have tried below steps and recovered control file from RMAN Backup. it works successfully..."
https://dba.stackexchange.com/questions/123917/database-not-able-to-startup-showing-control-file-is-inconsistent-with-another

Musi być gdzieś alertXXXX.log - poszukaj gdzieś w D:\dane\desktop\oracledb\diag\rdbms\orcl\orcl\trace

Znalazłem
Kilka ostatnich wpisów to

Started redo scan
2019-03-23T2259.268423+01:00
Slave encountered ORA-10388 exception during crash recovery
2019-03-23T2259.277424+01:00
Slave encountered ORA-10388 exception during crash recovery
2019-03-23T2259.285424+01:00
Slave encountered ORA-10388 exception during crash recovery
2019-03-23T2259.307425+01:00
Aborting crash recovery due to error 742
2019-03-23T2259.316426+01:00
Errors in file D:\DANE\DESKTOP\ORACLEDB\diag\rdbms\orcl\orcl\trace\orcl_ora_556.trc:
ORA-00742: Log read detects lost write in thread 1 sequence 197 block 12325
ORA-00312: online log 2 thread 1: 'D:\DANE\DESKTOP\ORACLEDB\ORADATA\ORCL\REDO02.LOG'
2019-03-23T2259.432432+01:00
Errors in file D:\DANE\DESKTOP\ORACLEDB\diag\rdbms\orcl\orcl\trace\orcl_ora_556.trc:
ORA-00742: Log read detects lost write in thread 1 sequence 197 block 12325
ORA-00312: online log 2 thread 1: 'D:\DANE\DESKTOP\ORACLEDB\ORADATA\ORCL\REDO02.LOG'
ORA-742 signalled during: alter database open...

Szukać jakiegoś konkretnego wpisu?

No to się nieźle posypało. Redo logi wyglądają na uszkodzone, a bez nich nie otworzysz bazy. Był jakiś nagły reset tego komputera czy coś?
Poszukaj czy w innej lokalizacji na kompie są bliźniacze kopie pliku REDO02.LOG, może będą w ...\flash_recovery_area...
Jesteś z tych co robią backup czy z tych co dopiero będą robić? ;)

Możliwe, że laptop mi się przegrzał i wyłączył. Nie potrzebuje tych BD, miałem tam tylko HR i jedną BD pod naukę, którą mogę odtworzyć. Żeby móc korzystać z BD i stworzyć nowego użytkownika muszę przeinstalować Oracle?
Gdzie znajdę \flash_recovery_area?

Dlaczego nie można otworzyć DB?

Nie musisz przeinstalowywać, użyj kreatora DBCA żeby utworzyć nową bazę. Lokalizację Flash Recovery Area będziesz miał w parametrze bazy o nazwie db_recovery_file_dest, a plik z parametrami jest w %ORACLE_HOME%\dbs

Jeśli to baza typu DEV, to możesz spróbować:

1. Uspójnić control file, tak jak pisał @robertos7778

2. Nazwy plików REDO nie wskazują żebyś miał dla nich duplikację ( 'D:\DANE\DESKTOP\ORACLEDB\ORADATA\ORCL\REDO02.LOG') ), więc możesz nie mieć z czego odtworzyć redo loga.
   Pokaż co masz w:

SELECT * FROM V$LOG;

i

SELECT * FROM V$LOGFILE;

Podnieś instancję, tak by był dostęp do struktu v$ - startup mount.

Możesz też odważnie zresetować logi, jeśli zależy Ci tylko na podniesieniu bazy, a niekoniecznie na danych, które być może da się uratować ;)

alter pluggable database ORCLDB shutdown abort;  
alter pluggable database ORCLDB mount;
alter pluggable database ORCLDB open resetlogs;

Masz 3 grupy redo logów, w każdej po 1 memberze (więc nie ma tworzonej kopii zapasowej redo loga). Dodatkowo redo logi nie zostały zarchiwizowane (ARCHIVED='NO').
Nie masz z czego naprawić uszkodzonego redologa.

ORA-00742: Log read detects lost write in thread 1 sequence 197 block 12325
ORA-00312: online log 2 thread 1: 'D:\DANE\DESKTOP\ORACLEDB\ORADATA\ORCL\REDO02.LOG'
2019-03-23T22:43:59.432432+01:00

Z v$log:

Grupa   |Sequence 
--------+---
1       | 196 --- ok 
3       | 195 --- ok
2       | 197 --- uszkodzony

195 i 196 wydają się ok, bo baza dojechała do 197 i poskarżyła się, że REDO2 jest uszkodzone.

Pozostaje recovery bazy do sekwencji 196 i otwarcie via open reset logs.

rman TARGET SYS/<tajne>@orcldb NOCATALOG 
run {
startup mount;
recover database unitl sequence 196;
alter database open resetlogs;
}

edited: Poprawiłem sekcję RMAN.

Tym poleceniem, które podałeś nie mogę się zalogować, ale samo RMAN działa. Wpisać tylko rman i dalej resztę poleceń?

Nie zadziałało, bo polecenie RMAN wydałeś w ramach sesji SQLPLUSa, a RMAN to osobne narzędzie. Uruchamisz RMANa i dalej resztę poleceń.

Wygląda jakbyś odpalił RMANa bez parametrów, a później w tym RMANie jeszcze raz RMAN TARGET ....

1. Uruchamiasz RMANa z linii poleceń: rman TARGET SYS/<tajne>@orcldb NOCATALOG
2. Jak się uruchomi, to wykonujesz sekcję run { ... }

Po wpisaniu tego polecenia nie odpala się RMAN

Ale działa to:

To

I to

Te polecenia też mogą być?

Zanim zresetujesz te redo logi, to zerknij jeszcze na Flash Recovery Area, tj. z sqlplusa:

set pagesize 50000 linesize 250 
show parameter db_reco
show parameter db_creat

Czy masz zdefiniowaną ścieżkę dla db_recovery_file_dest i jest w niej REDO02? Co prawda spodziewałbym się tej informacji w v$logfile, ale nie zaszkodzi sprawdzić dokładniej.

Znowu wyrzuciło błąd

Literówka była w poleceniu:
recover database until sequence 196;

Nadal błąd:

Czyli muszę zmienić nr sekwencji na niższy?

Obawiam się, że nie zrobisz recover - stan plików danych jest późniejszy niż ten, do którego chcesz odtworzyć. Jeśli nie masz backupu samej bazy (plików danych), to "se ne da". Recover bierze aktualny stan plików danych i uaktualnia je do wskazanego punktu (SCN, sequence lub timestamp). Wniosek z tego, że pliki muszą być starsze niż punkt odtwarzania.

A w ogóle ta baza jest w trybie ARCHIVELOG?

robertos7778 napisał(a):

Nie musisz przeinstalowywać, użyj kreatora DBCA żeby utworzyć nową bazę. Lokalizację Flash Recovery Area będziesz miał w parametrze bazy o nazwie db_recovery_file_dest, a plik z parametrami jest w %ORACLE_HOME%\dbs

W, którym miejscu muszę podać lokalizację Flash Recovery Area i parametry?

Czy wystarczy tylko polecenie

dbca ?

Jest jakieś znaczenie czy podam w/w informacje?

Skoro baza nie jest w ARCHIVELOG, to zawartość Flash Recovery Area jest pewnie pusta i nic tu nie da.
Twórz nową bazę. I nie pytaj o każdy drobiazg, wpisz "dbca 12c multitenant" w Google.

Możesz jeszcze spróbować jednego:

STARTUP MOUNT
RECOVER DATABASE UNTIL CANCEL
CANCEL
ALTER DATABASE OPEN RESETLOGS;

Dobra, nie masz archive logów, to recovery nie pójdzie po dobroci, więc można jeszcze spróbować wymusić przymknięcie oka na problemy z redo logami.

startup mount;
alter system set "_allow_resetlogs_corruption"= true scope=spfile;
alter system set undo_management=manual scope=spfile;
shutdown immediate;

startup mount;



alter database open resetlogs;



alter system set undo_management=manual scope = spfile;
create undo tablespace undo_new datafile 'd:\dane\desktop\oracledb\oradata\orcl\undo02.dbf' size 100m autoextend on maxsize 2g;
alter system set undo_tablespace=undo_new scope=spfile;
alter system set undo_management=auto scope=spfile;
alter system set "_allow_resetlogs_corruption"=false scope=spfile;

Nie mogę otworzyć BD

Tak, pierwszy przeszedł.

yarel napisał(a):

Dobra, nie masz archive logów, to recovery nie pójdzie po dobroci, więc można jeszcze spróbować wymusić przymknięcie oka na problemy z redo logami.

startup mount;
alter system set "_allow_resetlogs_corruption"= true scope=spfile;
alter system set undo_management=manual scope=spfile;
shutdown immediate;

startup mount;



alter database open resetlogs;



alter system set undo_management=manual scope = spfile;
create undo tablespace undo_new datafile 'd:\dane\desktop\oracledb\oradata\orcl\undo02.dbf' size 100m autoextend on maxsize 2g;
alter system set undo_tablespace=undo_new scope=spfile;
alter system set undo_management=auto scope=spfile;
alter system set "_allow_resetlogs_corruption"=false scope=spfile;

Działa. :) Wielkie dzięki wszystkim za pomoc!
Trzeba było dodać po drugim startup mount;

alter database open;

Co teraz zrobić, żeby uniknąć takich atrakcji w przyszłości?
Ustawić BD w tryb ARCHIVELOG i coś jeszcze?

Możesz zrobić:

• Multipleksowane redologi, tj. do każdej grupy należy dodać kolejnego membera. W praktyce robi się tak, że te zapasowe redologi są na osobnych urządzeniach (dyskach), wówczas nawet w przypadku awarii urządzenia mamy redologa na innym urządzeniu. Jak masz jeden dysk, to dodatkowy member uchroni Cię przed błędami w zapisie w jednym z redo logów.

alter database add logfile member 'd:\dane\desktop\oracledb\oradata\orcl\redo01.log' to group 1;
alter database add logfile member 'd:\dane\desktop\oracledb\oradata\orcl\redo02.log' to group 2;
alter database add logfile member 'd:\dane\desktop\oracledb\oradata\orcl\redo03.log' to group 3;

• Ustawienie bazy w tryb archiving, na bogato można zrobić zapis archive logów do dwóch lokalizacji
• Włączenie Flash Recovery Area

To w zupełności wystarczy do zabawy na laptopie.