DB2 (LUW) odpowiednik dla Oracle „drop user cascade”
Przydatne może być zapoznanie się najpierw z DB2 ogólnie.
Gdy instalujesz DB2, tworzy on instancję. Pomyśl o tym jako o „serwerze”. Instancja może mieć od zera do wielu baz danych wewnątrz niej (nie mogę powiedzieć, że znam limit). Kiedy utworzyłeś DB2 lokalnie, utworzył on dla Ciebie instancję o nazwie DB2. Zazwyczaj, gdy instalujesz DB2 na serwerze Unix, nadajesz nazwy swoim instancjom. Możesz mieć więcej niż jedną instancję na tym samym serwerze fizycznym. Twój identyfikator dsinst1 jest „właścicielem” instancji (zazwyczaj instancja jest nazywana po identyfikatorze, który jest jej właścicielem). Nigdy nie chcesz usuwać tego identyfikatora bez złomowania instancji lub możesz skończyć z bardzo dziwnym zachowaniem. Ten identyfikator (ponieważ jest właścicielem instancji) ma prawo do tworzenia baz danych, ale nie musi tego robić. Ten wpis na blogu autorstwa użytkownika DB2 Embera Crooksa pomaga wyjaśnić pojęcie instancji osobom lepiej zaznajomionym z Oracle.
Instancje mogą mieć utworzone bazy danych w ich obrębie. Wrócimy do tego później.
DAS (czyli DB2 Administration Server) to tak naprawdę bardziej usługa. To właśnie ona pozwala niektórym narzędziom GUI, takim jak DB2 Control Center, na współpracę z DB2. Z tego, co rozumiem, ta usługa nie jest niezbędna do działania DB2, ale jest często niezbędna dla użytkowników końcowych do interfejsu z DB2 z perspektywy innej niż wiersz poleceń. (Mustaccio, czy mam rację?). Bez względu na to, ile instancji masz na fizycznym pudełku, istnieje tylko jedna instalacja DAS. Ta jedna instalacja może obsługiwać wszystkie instancje. Zazwyczaj istnieje oddzielny identyfikator, który jest potrzebny do wykonania usługi DAS. To jest twój dasusr1. Ponownie, nie chcesz usuwać tego identyfikatora. Ten identyfikator zazwyczaj nie ma uprawnień do tworzenia żadnych obiektów w bazie danych.
Teraz identyfikator ogrodzenia (np. db2fenc1). Posiadanie jednego z nich jest dobrym pomysłem. Kiedy tworzysz instancję, możesz określić ID ogrodzenia. Jeśli to zrobisz, instancja staje się tym identyfikatorem. Jeśli tego nie zrobisz, wtedy ID właściciela instancji staje się ID ogrodzenia. Identyfikator ogrodzenia jest używany do uruchamiania niektórych procedur składowanych w DB2. W DB2 istnieją dwa sposoby uruchamiania procedur składowanych: z ogrodzeniem i bez ogrodzenia. Nieogrodzona oznacza, że procedura składowana działa w pamięci silnika DB2. Będzie ona działać szybciej, ale jeśli procedura składowana jest czymś więcej niż SQL (np. zawiera kod C++ lub Java) i ulegnie awarii, może zagrozić silnikowi, a nawet spowodować jego awarię i szkody. Procedury składowane ogrodzone działają poza pamięcią silnika DB2. Są przez to wolniejsze, ale w razie awarii nie zagrażają silnikowi DB2, ponieważ działały w swoim własnym chronionym obszarze pamięci. Przykład tego, jak jest to wykorzystywane przez DB2: jeśli uruchomisz narzędzie db2 export z procedury składowanej ADMIN_CMD, DB2 przełączy użytkownika na ciebie, który faktycznie wykonuje eksport. Dzieje się tak, ponieważ wykonujesz operacje wejścia/wyjścia pliku, a DB2 chce uruchomić to ogrodzone, aby chronić silnik. Więc nawet jeśli uruchamiasz to wywołanie procedury przechowywanej jako właściciel instancji, DB2 zmieni identyfikator na ogrodzony identyfikator (bez szansy na zmianę tego zachowania). Jeśli spojrzysz na uprawnienia do tego, kto jest właścicielem pliku eksportu, zauważysz, że jest to ogrodzony identyfikator, a nie identyfikator instancji (lub inny identyfikator, którego użyłeś do uruchomienia procedury przechowywanej). Oczywiście, jeśli twój identyfikator instancji jest twoim ogrodzonym identyfikatorem, wtedy będzie to wyglądać tak samo dla ciebie.
(Duży oddech).
OK. Więc powiedziałem to wszystko, aby wprowadzić Cię do DB2 w pigułce. Teraz przechodzimy do tego, o co prawdopodobnie się martwisz — kto jest właścicielem czego? Którykolwiek identyfikator tworzy bazę danych, jest jej właścicielem. Istnieją „grupy” akceptowane przez DB2, które zazwyczaj mają uprawnienia DBADM (tj. administrator bazy danych) do tworzenia baz danych. Jeśli więc utworzyłeś bazę danych przy użyciu identyfikatora właściciela instancji, będzie on właścicielem bazy danych i wszystkich obiektów utworzonych w bazie danych. Jeśli inny identyfikator połączy się z bazą danych (o ile ma odpowiednie uprawnienia), może tworzyć obiekty i być ich właścicielem.
Tutaj jest ciekawa rzecz dotycząca grup i identyfikatorów w DB2. Z tego, co widzę, nie są one tak naprawdę obiektami. Więc nie możesz ich upuścić. Nie można ich również tworzyć (przynajmniej z tego, co widzę). Kiedy nadajesz lub odbierasz uprawnienie do identyfikatora, DB2 przechowuje wzmianki o tej grupie lub identyfikatorze. Ale DB2 tak naprawdę nie „tworzy” ich. Najczęściej widziałem, jak DB2 wskazywał na system operacyjny lub LDAP lub oba, aby uwierzytelnić identyfikatory. Jeśli identyfikatory zostaną usunięte, musisz ręcznie usunąć uprawnienia z identyfikatorów i / lub przenieść własność obiektów. Nie ma w tym nic magicznego. Zadałem podobne pytanie związane z tworzeniem kopii zapasowej/przywracaniem do innego systemu i jak to wpływa na uprawnienia.
Na koniec, jeśli chodzi o Twój komentarz dotyczący schematów, generalnie każdy identyfikator mapuje do swojego własnego schematu. To, czy schemat istnieje, czy nie (utworzony przez ID DBADM jawnie lub przez użytkownika końcowego za pomocą uprawnienia IMPLICIT_SCHEMA), jest inną kwestią. Ogólnie rzecz biorąc, bez względu na to, jaki identyfikator łączy się z bazą danych, DB2 zakłada, że schemat jest taki sam jak identyfikator użytkownika i musisz przełączyć schematy (SET SCHEMA MYSCHEMA) lub jawnie wymienić swoje obiekty (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE), aby z nimi pracować.
Mam nadzieję, że to pomoże.
.