SQL> create database link timetest
2 connect to scotty identified by tiger
3 using ‚testdb1‘;
Datenbank-Link wurde angelegt.
und wollte dann auf über den Link einen Select machen:
SQL> select * from scotty.test@timetest;
select * from scotty.test@timetest
*
FEHLER in Zeile 1:
ORA-12640: Inititalisierung des Berechtigungspr³fungsadapters misslungen
wenn ich mir die doku im www so anschaue müßte alles richtig sein…
muß ich irgendwas besonderes irgendwo eintragen, damit die db weiß das sie nen db-link hat ?
auf dem server der startdb habe ich den tnseintrag für die testdb1 eingetragen.
ich habe nach einigem testen den DB-Link neu erstellt und zwar mit dem tnsnamen. dann habe ich noch alle tnsnames und listner genauestens angepaßt und siehe da, ein neuer fehler:
diesen fehler habe ich dann noch beseitigt indem ich in der
init.ora der startdatenbank „GLOBAL_NAMES“ auf „false“ gesetzt
habe und…
dieser „fehler“ ist meines wissens nach ein feature. es soll verhindern, dass einem arglosen anwender einfach so ein „gefälschter“ database link untergejubelt wird. im klartext: wenn es den server „testdb“ gibt und einen database link „testdb“ so stellt der obige parameter, dass der link auch auf den gleichnamigen server verweist. ansonsten könnte ja jemand einen link auf den server „hackerdb“ legen und damit ev. die datenkonsistenz gefährden.
wenn du aber die flexibilität bei der benennung deiner links brauchst, musst du den parameter deaktivieren.
wenn du aber die flexibilität bei der benennung deiner links
brauchst, musst du den parameter deaktivieren.
und die probleme ergeben sich erst, sobald man auf ein global_names=true angewiesen ist (z.b. replikation), jedoch bereits tonnen von db-links in einer applikation eingearbeitet sind und nun dies alle geändert werden muß …
lieber auf true lassen und den db-link „richtigstellen“ - ich sehe wenig flexibilität darin, db-links umzubenennen - vor allem in echtsystemen
lieber auf true lassen und den db-link „richtigstellen“ - ich
sehe wenig flexibilität darin, db-links umzubenennen - vor
allem in echtsystemen
unter normalen umständen würde ich dir jetzt voll und ganz zustimmen. ABER: ich habe eine kleine applikation, die auf 3 server verteilt ist.
wobei bei der verteilung mehrere modelle zur anwendung kommen: einige tabelle werden per read-only-snapshot von einem dezitierten master verteilt, andere tabellen werden per read-write-snapshots über alle 3 server verteilt.
das ganze lief mehrere jahre vor sich hin - bis irgendjemand auf die idee kam, den einen server abzubauen und die datenbank auf einen anderen server zu verlegen (hatte lizenztechnische gründe). und das ganze natürlich mit einer superlangen vorwarnzeit von einer woche. und natürlich habe ich für diese applikation gerade mal 1-2 stunden pro tag zeit.
möglichkeit a: jede verwendung des db-links auf den fraglichen server aufspüren und durch den neuen link ersetzen. => hoher aufwand
möglichkeit b: den namen des db-links leich lassen und nur den zielserver ausbessern. => 5 minuten aufwand
wer jetzt meint, dass das ganze ziemlich quick and dirty ist, hat definitiv recht. ändert nichts an der tatsache, dass ich für eine saubere lösung wichtigere projekte liegenlassen hätte müssen. abgesehen davon, dass bei „vergessenen“ links ein ziemlicher kuddelmuddel passiert wäre (der alte server blieb noch einige tage im netz und war unter dem alten tns-namen weiterhin erreichbar).
ich werde nicht für akademisch sauberes arbeiten bezahlt sondern dafür, dass die applikation läuft!
ich bin mir sicher das das auch mit „true“ geht, aber ich weiß nicht welches Problem der Link genau hat… auf welchen teil bezieht sich denn mein problem ? ist das die endung ? ich war halt schonmal froh das es überhaupt klappt…
Grüße
chris
lieber auf true lassen und den db-link „richtigstellen“ - ich
sehe wenig flexibilität darin, db-links umzubenennen - vor
allem in echtsystemen