DB2 (LUW) svarer til Oracle “drop user cascade”
Det kan være nyttigt at gennemgå DB2 generelt først.
Når du installerer DB2, oprettes der en instans. Tænk på dette som en “server”. En instans kan have nul til mange databaser i den (kan ikke sige, at jeg kender grænsen). Da du oprettede DB2 lokalt, oprettede den en instans til dig med navnet DB2. Normalt, når du installerer DB2 på f.eks. en Unix-server, navngiver du dine instanser. Du kan have mere end én instans på den samme fysiske server. Dit dsinst1-id er “ejeren” af instansen (normalt er instansen opkaldt efter det ID, der ejer den). Du ønsker aldrig at slette dette ID uden at skrotte instansen, ellers kan du ende med nogle meget mærkelige adfærdsmønstre. Dette ID (da det er instansens ejer) har beføjelse til at oprette databaser, men behøver ikke at gøre det. Dette blogindlæg af DB2-brugerkollega Ember Crooks hjælper med at forklare begrebet instans for dem, der er mere fortrolige med Oracle.
Instanser kan få oprettet databaser i dem. Vi vender tilbage til dette senere.
DAS (eller DB2 Administration Server) er i virkeligheden mere som en tjeneste. Det er det, der gør det muligt for nogle af GUI-værktøjerne, som DB2 Control Center, at fungere som grænseflade med DB2. Så vidt jeg har forstået, er denne tjeneste ikke nødvendig for at DB2 kan køre, men den er ofte nødvendig for slutbrugerne for at få en grænseflade med DB2 fra et ikke-kommandolinjeperspektiv. (Mustaccio har jeg ret her?). Uanset hvor mange instanser du har på en fysisk boks, så er der kun én installation af DAS. Denne ene installation kan servicere alle instanserne. Der er normalt et separat ID, der er nødvendigt for at udføre DAS-tjenesten. Dette er dit dasusr1. Igen, du ønsker ikke at slette dette ID. Dette ID har normalt ingen autoritet til at oprette objekter i din database.
Nu til hegns-ID’et (dvs. db2fenc1). Det er en god idé at have en af disse. Når du opretter en instans, kan du angive et fence-ID. Hvis du gør det, bliver det dette ID. Hvis du ikke gør det, bliver instansens ejer-id til hegns-id’et. Fence ID’et bruges til at køre visse lagrede procedurer i DB2. I DB2 er der to måder at køre lagrede procedurer på: indhegnet og uindhegnet. Uindhegnet betyder, at den lagrede procedure køres i DB2-motorens hukommelse. Den kører hurtigere, men hvis den gemte procedure er mere end SQL (dvs. indeholder f.eks. C++- eller Java-kode), og den går ned, kan den true motoren og faktisk gå ned og forårsage skade. Indhegnede lagrede procedurer kører uden for DB2-motorens hukommelse. De er derfor langsommere, men hvis de går ned, truer de ikke DB2-motoren, fordi de kørte i deres eget beskyttede hukommelsesområde. Et eksempel på, hvordan dette bruges af DB2: Hvis du kører db2 export utility fra ADMIN_CMD stored procedure, skifter DB2 brugeren på dig af hvem der rent faktisk udfører eksporten. Dette skyldes, at du udfører file I/O, og DB2 ønsker at køre dette indhegnet for at beskytte motoren. Så selv hvis du kører dette kald til den lagrede procedure som instansens ejer, vil DB2 skifte ID til det indhegnede ID (uden mulighed for at ændre denne adfærd). Hvis du ser på tilladelserne for, hvem der ejer eksportfilen, vil du bemærke, at det er det indhegnede ID og ikke instans-ID’et (eller et andet ID, du brugte til at starte den lagrede procedure). Hvis dit instance ID er dit fenced ID, vil det selvfølgelig se ens ud for dig.
(Stor indånding).
OK. Så jeg sagde alt dette for at præsentere dig for DB2 i en nøddeskal. Nu kommer vi til det, som du sikkert er bekymret for – hvem ejer hvad? Det er det ID, der opretter databasen, der ejer databasen. Der er “grupper”, som DB2 accepterer, der generelt har DBADM (dvs. databaseadministrator) autoritet til at oprette databaser. Så hvis du oprettede en database ved hjælp af dit instans ejer-id, ville det være ejeren af databasen og alle objekter, som den opretter i databasen. Hvis et andet ID opretter forbindelse til databasen (så længe det har de korrekte tilladelser), kan det oprette objekter og eje dem.
Her er det interessante ved grupper og ID’er i DB2. De er ikke rigtig objekter efter hvad jeg kan se. Så du kan ikke droppe dem. Du kan heller ikke oprette dem (i hvert fald ikke efter hvad jeg kan se). Når du giver eller tilbagekalder en tilladelse til et ID, gemmer DB2 omtalen af den pågældende gruppe eller ID. Men DB2 “opretter” dem ikke rigtigt. Oftest har jeg set DB2 pege på OS eller på en LDAP eller begge dele for at autentificere ID’erne. Hvis ID’erne fjernes, skal man manuelt fjerne rettighederne fra ID’erne og/eller overføre ejerskabet af objekterne. Der er intet magisk ved dette her. Jeg stillede et lignende spørgsmål, der har at gøre med at lave en backup/gendannelse til et andet system, og hvordan det påvirker tilladelser.
Og til sidst til din kommentar om skemaer, generelt er hvert ID mapper til sit eget skema. Hvorvidt skemaet findes eller ej (oprettet af DBADM-ID’et eksplicit eller af slutbrugeren via tilladelsen IMPLICIT_SCHEMA) er et andet spørgsmål. Generelt antager DB2, uanset hvilket ID der forbinder til en database, at skemaet er det samme som bruger-id’et, og du skal skifte skema (SET SCHEMA MYSCHEMA) eller eksplicit nævne dine objekter (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) for at arbejde med dem.
Håber dette hjælper.