stamattina ho fatto il mio primo danno. sto lavorando sul mio schema di database in un’istanza di oracle. il mio user ha grant di administer database trigger perchè ho bisogno di creare un logon trigger del tipo
create or replace trigger user_logon_trigger
after logon on database
begin
my_package.do_something();
end;
Insomma ricreo lo schema (trigger compreso), faccio logout-login. Non va, non riesco ad entrare.
Nel frattempo non si collegano nemmeno i miei tre colleghi, che aspettano di lavorare su altri schemi sulla stessa istanza. Il trigger sembra invalido, e caccia fuori tutti gli utenti.
Non vi dico i casini per recuperare il DBA, che non riusciva nemmeno lui a loggarsi, e alla fine fare un reboot della macchina.
Stavolta, il DBA fa riavviare il db modificando in init.ora la variabile
_system_trig_enabled = false
che permette di far partire il db senza trigger. bon. riabilitiamo il trigger e vediamo se tutto gira. Sì, gira tutto.
Tempo 5 minuti ed è di nuovo tutto TFU (Totally Fucked Up come dice il mio omonimo).
Alla fine si svela l’arcano: nel pacchetto my_package ho lasciato un dbms_pipe.send_message() che mi serviva per debug. Questa simpatica utility va a scrivere in un buffer i messaggi. Ma se il buffer non viene “svuotato” leggendolo, il buffer si riempie. E riempie la memoria dell’istanza oracle. Non sapete quanto… finchè implode tutto e non si riesce nemmeno a collegarsi…
Quindi, oggi ho imparato che: si può escludere l’attivazione di un trigger per un determinato utente:
create or replace trigger user_logon trigger
after logon on database when user not in ('sys', 'system', 'pippo')
begin
...
end;
Poi ho imparato che è meglio tenersi amico il DBA.
e che le cose di debug si fanno sull’istanza di debug.
e che dbms_pipe è una mer@a.