DB2 (LUW) ekvivalent pro Oracle „drop user cascade“
Možná by bylo užitečné si nejprve prohlédnout DB2 obecně.
Při instalaci DB2 se vytvoří instance. Představte si ji jako „server“. Instance může mít v sobě nula až mnoho databází (nemohu říci, že znám limit). Když jste vytvořili DB2 lokálně, vytvořila se vám instance s názvem DB2. Obvykle, když instalujete DB2 například na unixový server, pojmenováváte své instance. Na jednom fyzickém serveru můžete mít více instancí. ID dsinst1 je „vlastníkem“ instance (obvykle je instance pojmenována podle ID, které ji vlastní). Toto ID nikdy nechcete odstranit, aniž byste instanci vyřadili, jinak se můžete setkat s velmi podivným chováním. Toto ID (protože je vlastníkem instance) má pravomoc vytvářet databáze, ale nemusí. Tento příspěvek na blogu od kolegy Embera Crookse, uživatele DB2, pomáhá vysvětlit pojem instance těm, kteří jsou lépe obeznámeni se systémem Oracle.
Instance mohou mít v sobě vytvořené databáze. K tomu se vrátíme později.
DAS (neboli DB2 Administration Server) je ve skutečnosti spíše služba. Právě on umožňuje některým nástrojům s grafickým uživatelským rozhraním, jako je například DB2 Control Center, komunikovat s DB2. Pokud vím, tato služba není nutná pro běh DB2, ale je často nezbytná pro koncové uživatele, aby mohli s DB2 komunikovat z pohledu jiného než příkazového řádku. (Mustaccio, mám pravdu?). Bez ohledu na to, kolik instancí máte na fyzickém boxu, existuje pouze jedna instalace DAS. Tato jedna instalace může obsluhovat všechny instance. Obvykle existuje samostatné ID, které je potřeba ke spuštění služby DAS. Tím je vaše dasusr1. Toto ID opět nechcete odstranit. Toto ID obvykle nemá oprávnění vytvářet žádné objekty ve vaší databázi.
Nyní pro ID plotu (tj. db2fenc1). Mít jedno z nich je dobrý nápad. Při vytváření instance můžete zadat ID plotu. Pokud tak učiníte, stane se tímto ID. Pokud tak neučiníte, ID vlastníka instance se stane ID plotu. ID plotu se používá pro spouštění určitých uložených procedur v DB2. V DB2 existují dva způsoby spouštění uložených procedur: oplocené a neoplocené. Neoplocený znamená, že uložená procedura běží v paměti DB2 engine. Poběží rychleji, ale pokud je uložená procedura více než SQL (tj. obsahuje například kód v jazyce C++ nebo Java) a dojde k jejímu pádu, může to ohrozit motor a skutečně ho zhroutit a poškodit. Ohraničené uložené procedury běží mimo paměť jádra DB2. Jsou tedy pomalejší, ale pokud dojde k jejich pádu, neohrozí motor DB2, protože běžely ve vlastní chráněné oblasti paměti. Příklad, jak toho DB2 využívá: pokud spustíte nástroj db2 export z uložené procedury ADMIN_CMD, DB2 na vás přepne uživatele, který export skutečně provede. Je to proto, že provádíte vstup/výstup souboru a DB2 si přeje, aby byl tento proces spuštěn jako ohrazený, aby byl chráněn engine. Takže i když toto volání uložené procedury spouštíte jako vlastník instance, DB2 přepne ID na oplocené ID (bez možnosti, že byste toto chování změnili). Pokud se podíváte na oprávnění toho, kdo je vlastníkem exportního souboru, všimnete si, že je to oplocené ID, nikoli ID instance (nebo jiné ID, které jste použili pro spuštění uložené procedury). Samozřejmě pokud je vaše ID instance vaše ohrazené ID, pak vám to bude připadat jedno a to samé.
(Velký nádech).
OK. To vše jsem řekl, abych vás v kostce seznámil s DB2. Nyní se dostáváme k tomu, co vás pravděpodobně trápí – kdo co vlastní? Které ID databázi vytvoří, to ji vlastní. Existují „skupiny“, které DB2 akceptuje a které mají obecně oprávnění DBADM(tj. správce databáze) vytvářet databáze. Pokud jste tedy vytvořili databázi pomocí ID vlastníka instance, pak bude vlastníkem databáze a všech objektů, které v databázi vytvoří. Pokud se k databázi připojí jiné ID (pokud má správná oprávnění), může vytvářet objekty a vlastnit je.
Tady je zajímavá věc ohledně skupin a ID v rámci DB2. Z toho, co vidím, to vlastně nejsou objekty. Takže je nemůžete zrušit. Nemůžete je ani vytvořit (alespoň z toho, co vidím). Když udělíte nebo zrušíte oprávnění k ID, DB2 pak uloží zmínku o této skupině nebo ID. Ale DB2 je ve skutečnosti „nevytváří“. Nejčastěji jsem viděl, že DB2 odkazuje na operační systém nebo na LDAP nebo na obojí, aby ověřil ID. Pokud jsou ID odstraněna, je třeba ručně odebrat oprávnění ID a/nebo převést vlastnictví objektů. Na tom není nic magického. Položil jsem podobnou otázku, která měla co do činění s provedením zálohy/obnovy do jiného systému a jak to ovlivní oprávnění.
A nakonec k vaší poznámce o schématech: Obecně platí, že každé ID se mapuje na vlastní schéma. To, zda schéma existuje (vytvořené explicitně ID DBADM nebo koncovým uživatelem prostřednictvím oprávnění IMPLICIT_SCHEMA), je jiná otázka. Obecně platí, že ať už se k databázi připojuje jakékoliv ID, DB2 předpokládá, že schéma je stejné jako ID uživatele, a abyste s nimi mohli pracovat, musíte přepnout schéma (SET SCHEMA MYSCHEMA) nebo explicitně zmínit své objekty (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE).
Doufám, že to pomůže.