Echivalentul DB2 (LUW) pentru Oracle „drop user cascade”
S-ar putea fi util să analizați mai întâi DB2 în general.
Când instalați DB2, acesta creează o instanță. Gândiți-vă la aceasta ca la un „server”. O instanță poate avea de la zero la mai multe baze de date în ea (nu pot spune că știu limita). Când ați creat DB2 local, acesta a creat o instanță pentru dvs. numită DB2. De obicei, atunci când instalați DB2 pe un server Unix, de exemplu, denumiți instanțele. Puteți avea mai multe instanțe pe același server fizic. Id-ul dvs. dsinst1 este „proprietarul” instanței (de obicei, instanța este numită după ID-ul care o deține). Nu doriți niciodată să ștergeți acest ID fără a desființa instanța, altfel vă puteți trezi cu comportamente foarte ciudate. Acest ID (deoarece este proprietarul instanței) are puterea de a crea baze de date, dar nu este obligat să o facă. Această intrare pe blog a colegului Ember Crooks, utilizator DB2, ajută la explicarea conceptului de instanță pentru cei mai familiarizați cu Oracle.
Instanțele pot avea baze de date create în cadrul lor. Vom reveni la acest lucru mai târziu.
DAS (sau DB2 Administration Server) este de fapt mai degrabă un serviciu. Este ceea ce permite unora dintre instrumentele GUI, cum ar fi DB2 Control Center, să se interfațeze cu DB2. Din câte am înțeles, acest serviciu nu este necesar pentru ca DB2 să funcționeze, dar este adesea necesar pentru ca utilizatorii finali să se interfațeze cu DB2 dintr-o perspectivă diferită de linia de comandă. (Mustaccio, am dreptate aici?). Nu contează câte instanțe aveți pe o cutie fizică, există o singură instalare a DAS. Această singură instalare poate deservi toate instanțele. De obicei, există un ID separat care este necesar pentru a executa serviciul DAS. Acesta este dasusr1. Din nou, nu doriți să ștergeți acest ID. De obicei, acest ID nu are autoritatea de a crea niciun obiect în baza de date.
Acum pentru ID-ul de împrejmuire (de exemplu, db2fenc1). A avea unul dintre acestea este o idee bună. Când creați o instanță, puteți specifica un ID de împrejmuire. Dacă o faceți, acesta devine acel ID. Dacă nu o faceți, atunci ID-ul proprietarului instanței devine ID-ul de împrejmuire. ID-ul de gard este utilizat pentru a rula anumite proceduri stocate în DB2. În DB2 există două moduri de a rula proceduri stocate: cu sau fără gardă. Unfenced înseamnă că procedura stocată se execută în memoria motorului DB2. Aceasta va rula mai repede, dar dacă procedura stocată este mai mult decât SQL (adică, conține cod C++ sau Java, de exemplu) și se blochează, poate amenința motorul și, de fapt, îl poate prăbuși și provoca daune. Procedurile stocate cu gardă se execută în afara memoriei motorului DB2. Prin urmare, sunt mai lente, dar dacă se prăbușesc nu amenință motorul DB2, deoarece au rulat în propria lor zonă de memorie protejată. Un exemplu al modului în care acest lucru este folosit de DB2: dacă executați utilitarul db2 export din procedura stocată ADMIN_CMD, DB2 va schimba utilizatorul pe dvs. de cel care execută efectiv exportul. Acest lucru se datorează faptului că efectuați I/O de fișier și DB2 dorește să ruleze acest lucru îngrădit pentru a proteja motorul. Astfel, chiar dacă executați acest apel de procedură stocată ca proprietar al instanței, DB2 va schimba ID-ul în ID-ul îngrădit (fără nicio șansă de a modifica acest comportament). Dacă vă uitați la permisiunile privind persoana care deține fișierul de export, veți observa că este vorba de ID-ul îngrădit, mai degrabă decât de ID-ul instanței (sau de alt ID pe care l-ați folosit pentru a lansa procedura stocată). Bineînțeles, dacă ID-ul de instanță este ID-ul dvs. îngrădit, atunci pentru dvs. va părea unul și același lucru.
(Respirație mare).
OK. Așadar, am spus toate acestea pentru a vă prezenta DB2 pe scurt. Acum ajungem la ceea ce probabil vă îngrijorează – cine deține ce? Orice ID care creează baza de date deține baza de date. Există „grupuri” pe care DB2 le acceptă și care, în general, au autoritatea DBADM (adică, administratorul bazei de date) de a crea baze de date. Astfel, dacă ați creat o bază de date folosind ID-ul proprietarului instanței, atunci acesta ar fi proprietarul bazei de date și al oricăror obiecte pe care le creează în cadrul bazei de date. Dacă un alt ID se conectează la baza de date (atâta timp cât are permisiunile corecte), acesta poate crea obiecte și le poate deține.
Iată care este lucrul interesant despre grupuri și ID-uri în cadrul DB2. Ele nu sunt cu adevărat obiecte din câte văd eu. Deci nu le puteți renunța. Nu le puteți nici crea (cel puțin din câte văd eu). Atunci când acordați sau revocați o permisiune unui ID, DB2 stochează apoi mențiunea acelui grup sau ID. Dar DB2 nu le „creează” cu adevărat. De cele mai multe ori am văzut că DB2 a indicat către sistemul de operare sau către un LDAP sau ambele pentru a autentifica ID-urile. Dacă ID-urile sunt eliminate, trebuie să eliminați manual permisiunile de la ID-uri și/sau să transferați proprietatea asupra obiectelor. Nu există nimic magic în acest sens aici. Am pus o întrebare similară având legătură cu efectuarea unei copii de rezervă/restaurări pe un sistem diferit și modul în care acest lucru afectează permisiunile.
Și, în cele din urmă, pentru comentariul dvs. despre scheme, în general, fiecare ID se mapează la propria sa schemă. Dacă schema există sau nu (creată de ID-ul DBADM în mod explicit sau de către utilizatorul final prin permisiunea IMPLICIT_SCHEMA) este o altă întrebare. În general, indiferent de ID-ul care se conectează la o bază de date, DB2 presupune că schema este aceeași cu ID-ul utilizatorului și trebuie să schimbați schemele (SET SCHEMA MYSCHEMA) sau să menționați în mod explicit obiectele (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) pentru a lucra cu ele.
Sperăm că vă ajută.
.