DB2 (LUW) equivalent voor Oracle “drop user cascade”
Het is misschien handig om eerst DB2 in het algemeen te bekijken.
Wanneer je DB2 installeert, wordt er een instantie aangemaakt. Zie dit als een “server”. Een instantie kan nul tot veel databases bevatten (ik kan niet zeggen dat ik de limiet weet). Toen je DB2 lokaal aanmaakte, creëerde het een instantie voor jou met de naam DB2. Gewoonlijk als je DB2 installeert op bijvoorbeeld een Unix server, geef je je instanties een naam. Je kunt meer dan één instantie op dezelfde fysieke server hebben. Je dsinst1 id is de “eigenaar” van de instantie (meestal wordt de instantie genoemd naar de ID die de eigenaar is). Je wilt deze ID nooit verwijderen zonder de instantie te slopen, anders kun je te maken krijgen met vreemd gedrag. Dit ID (omdat het de eigenaar van de instantie is) heeft de macht om databases te maken, maar hoeft dat niet te doen. Deze blog entry van mede DB2 gebruiker Ember Crooks helpt om het concept van een instantie uit te leggen aan diegenen die meer bekend zijn met Oracle.
Instances kunnen databases in zich hebben aangemaakt. We komen hier later op terug.
De DAS (of DB2 Administration Server) is eigenlijk meer een service. Het is wat sommige van de GUI tools zoals DB2 Control Center in staat stelt om te interfacen met DB2. Van wat ik begrepen heb, is deze service niet noodzakelijk om DB2 te laten draaien, maar is vaak noodzakelijk voor eindgebruikers om te kunnen interfacen met DB2 vanuit een niet-command line perspectief. (Heb ik het goed, Mustaccio?). Het maakt niet uit hoeveel instances je op een fysieke doos hebt, er is maar één installatie van de DAS. Deze ene installatie kan alle instanties bedienen. Er is meestal een aparte ID nodig om de DAS service uit te voeren. Dit is je dasusr1. Nogmaals, je wilt deze ID niet verwijderen. Deze ID heeft meestal geen bevoegdheid om objecten in je database aan te maken.
Nu de hek-ID (bijv. db2fenc1). Het is een goed idee om er zo een te hebben. Wanneer je een instantie aanmaakt, kun je een fence ID opgeven. Als je dat doet, wordt het dat ID. Doe je dat niet, dan wordt de instance owner ID de fence ID. Het fence ID wordt gebruikt voor het uitvoeren van bepaalde opgeslagen procedures in DB2. In DB2 zijn er twee manieren om stored procedures uit te voeren: fenced en unfenced. Unfenced betekent dat de opgeslagen procedure binnen het geheugen van de DB2 engine draait. Het zal sneller lopen, maar als de opgeslagen procedure meer is dan SQL (bijvoorbeeld C++ of Java code bevat) en het crasht, kan het de engine bedreigen en daadwerkelijk crashen en schade veroorzaken. Afgeschermde stored procedures lopen buiten het geheugen van de DB2 engine. Ze zijn dus langzamer, maar als ze crashen vormen ze geen bedreiging voor de DB2 engine omdat ze in hun eigen beschermde geheugengebied lopen. Een voorbeeld van hoe dit door DB2 wordt gebruikt: als je de db2 export utility uitvoert vanuit de ADMIN_CMD stored procedure, zal DB2 de gebruiker die de export feitelijk uitvoert, omwisselen. Dit is omdat je file I/O doet en DB2 dit omheind wil uitvoeren om de engine te beschermen. Dus zelfs als je deze stored procedure aanroept als de instance owner, zal DB2 de ID veranderen in de afgeschermde ID (zonder kans dat je dit gedrag kunt veranderen). Als je kijkt naar de permissies van wie de eigenaar is van het export bestand, zul je zien dat het de afgeschermde ID is, in plaats van de instance ID (of andere ID die je gebruikte om de stored procedure af te vuren). Natuurlijk, als je instance ID je omheinde ID is, dan zal het er voor jou hetzelfde uitzien.
(Grote zucht).
OK. Dus ik zei dat allemaal om u DB2 in een notendop voor te stellen. Nu komen we bij waar je je waarschijnlijk zorgen over maakt — wie is de eigenaar van wat? De ID die de database aanmaakt, is eigenaar van de database. Er zijn “groepen” die DB2 accepteert die over het algemeen de DBADM (d.w.z. database administrator) authoriteit hebben om databases aan te maken. Dus als je een database aanmaakt met je instance owner ID, dan is die de eigenaar van de database en alle objecten die in de database worden aangemaakt. Als een andere ID verbinding maakt met de database (zolang het de juiste rechten heeft), kan het objecten maken en er eigenaar van zijn.
Hier is het interessante van groepen en ID’s binnen DB2. Het zijn niet echt objecten, van wat ik kan zien. Dus je kunt ze niet laten vallen. Je kunt ze ook niet maken (althans niet voor zover ik kan zien). Als je een toestemming aan een ID geeft of intrekt, dan slaat DB2 de vermelding van die groep of ID op. Maar DB2 “creëert” ze niet echt. Meestal heb ik DB2 zien verwijzen naar het OS of naar een LDAP of beide om de ID’s te authenticeren. Als de ID’s worden verwijderd, moet je handmatig de rechten van de ID’s verwijderen en/of het eigendom van de objecten overdragen. Er is hier niets magisch aan. Ik heb een soortgelijke vraag gesteld over het maken van een backup/restore naar een ander systeem en de invloed daarvan op de permissies.
En tot slot je opmerking over schema’s: over het algemeen is elke ID gekoppeld aan zijn eigen schema. Of het schema al dan niet bestaat (expliciet aangemaakt door de DBADM ID of door de eindgebruiker via de IMPLICIT_SCHEMA permissie) is een andere vraag. In het algemeen, welke ID ook verbinding maakt met een database, DB2 neemt aan dat het schema hetzelfde is als de gebruiker id en je moet schema’s wisselen (SET SCHEMA MYSCHEMA) of expliciet je objecten vermelden (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) om ermee te kunnen werken.
Hoop dat dit helpt.