DB2 (LUW) motsvarande för Oracle ”drop user cascade”
Det kan vara bra att se över DB2 i allmänhet först.
När du installerar DB2 skapas en instans. Tänk på detta som en ”server”. En instans kan ha noll till många databaser inom den (kan inte säga att jag känner till gränsen). När du skapade DB2 lokalt skapade den en instans för dig med namnet DB2. När du installerar DB2 på t.ex. en Unix-server brukar du namnge dina instanser. Du kan ha mer än en instans på samma fysiska server. Ditt dsinst1-id är instansens ”ägare” (vanligtvis namnges instansen efter det ID som äger den). Du vill aldrig ta bort detta ID utan att skrota instansen, annars kan du få mycket märkliga beteenden. Detta ID (eftersom det är instansens ägare) har befogenhet att skapa databaser, men behöver inte göra det. Det här blogginlägget av DB2-användaren Ember Crooks hjälper till att förklara begreppet instans för dem som är mer bekanta med Oracle.
Instanser kan ha databaser skapade inom dem. Vi återkommer till detta senare.
DAS (eller DB2 Administration Server) är egentligen mer som en tjänst. Det är den som gör det möjligt för vissa av GUI-verktygen som DB2 Control Center att ha ett gränssnitt mot DB2. Vad jag förstår är denna tjänst inte nödvändig för att DB2 ska kunna köras, men den är ofta nödvändig för att slutanvändare ska kunna använda DB2 från ett icke kommandoradsperspektiv. (Mustaccio har jag rätt här?). Oavsett hur många instanser du har på en fysisk box finns det bara en installation av DAS. Denna enda installation kan betjäna alla instanser. Det finns vanligtvis ett separat ID som behövs för att exekvera DAS-tjänsten. Detta är ditt dasusr1. Återigen vill du inte ta bort detta ID. Detta ID har vanligtvis ingen behörighet att skapa några objekt i din databas.
Nu kommer ID:t för stängslet (dvs. db2fenc1). Att ha en av dessa är en bra idé. När du skapar en instans kan du ange ett fence-ID. Om du gör det blir det detta ID. Om du inte gör det blir instansens ägar-ID fence-ID. Fence-ID används för att köra vissa lagrade procedurer i DB2. I DB2 finns det två sätt att köra lagrade procedurer: inhägnad och ohägnad. Oskyddad innebär att den lagrade proceduren körs i DB2-motorns minne. Det går snabbare, men om den lagrade proceduren är mer än SQL (t.ex. innehåller C++- eller Javakod) och kraschar kan den hota motorn och faktiskt krascha den och orsaka skada. Inhägnade lagrade procedurer körs utanför DB2-motorns minne. De är därför långsammare, men om de kraschar hotar de inte DB2-motorn eftersom de kördes i sitt eget skyddade minnesområde. Ett exempel på hur detta används av DB2: Om du kör verktyget db2 export från den lagrade proceduren ADMIN_CMD kommer DB2 att byta användare på dig av vem som faktiskt utför exporten. Detta beror på att du utför file I/O och DB2 vill köra detta inhägnat för att skydda motorn. Så även om du kör anropet av den lagrade proceduren som instansägare kommer DB2 att byta ID till det inhägnade ID:t (utan möjlighet att du kan ändra detta beteende). Om du tittar på behörigheterna för vem som äger exportfilen kommer du att märka att det är det inhägnade ID:t, snarare än instans-ID:t (eller annat ID som du använde för att starta den lagrade proceduren). Om ditt instans-ID är ditt fenced ID kommer det naturligtvis att se likadant ut för dig.
(stort andetag).
OK. Så jag sa allt detta för att introducera dig till DB2 i ett nötskal. Nu kommer vi till det som du förmodligen oroar dig för – vem äger vad? Det ID som skapar databasen äger den. Det finns ”grupper” som DB2 accepterar och som i allmänhet har DBADM (dvs. databasadministratör) behörighet att skapa databaser. Så om du skapar en databas med hjälp av ditt instansägar-ID så är det ägaren till databasen och alla objekt som skapas i databasen. Om ett annat ID ansluter till databasen (så länge det har rätt behörighet) kan det skapa objekt och äga dem.
Här är det intressanta med grupper och ID i DB2. De är egentligen inte objekt vad jag kan se. Så du kan inte släppa dem. Du kan inte heller skapa dem (åtminstone inte vad jag kan se). När du beviljar eller återkallar en behörighet till ett ID, lagrar DB2 sedan omnämnandet av den gruppen eller ID:n. Men DB2 ”skapar” dem egentligen inte. Oftast har jag sett DB2 peka på operativsystemet eller en LDAP eller båda för att autentisera ID:erna. Om ID:erna tas bort måste man manuellt ta bort behörigheterna från ID:erna och/eller överföra äganderätten till objekten. Det finns inget magiskt i detta sammanhang. Jag ställde en liknande fråga som hade att göra med att göra en säkerhetskopiering/återställning till ett annat system och hur det påverkar behörigheterna.
Och slutligen, när det gäller din kommentar om scheman, så mappar i allmänhet varje ID till sitt eget schema. Huruvida schemat finns eller inte (skapat av DBADM-ID explicit eller av slutanvändaren genom behörigheten IMPLICIT_SCHEMA) är en annan fråga. Generellt sett, oavsett vilket ID som ansluter till en databas, antar DB2 att schemat är detsamma som användar-ID:t och du måste byta schema (SET SCHEMA MYSCHEMA) eller uttryckligen nämna dina objekt (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) för att kunna arbeta med dem.
Hoppas att detta hjälper.