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!
erwin
