DB2 (LUW) equivalent for Oracle ”drop user cascade”
Voi olla hyödyllistä tarkastella DB2:ta ensin yleisesti.
Kun asennat DB2:n, se luo instanssin. Ajattele tätä ”palvelimena”. Instanssissa voi olla nollasta moneen tietokantaan (en voi sanoa tietäväni rajaa). Kun luot DB2:n paikallisesti, se loi sinulle DB2-nimisen instanssin. Yleensä kun asennat DB2:n esimerkiksi Unix-palvelimelle, annat instansseille nimen. Samalla fyysisellä palvelimella voi olla useampi kuin yksi instanssi. Sinun dsinst1-tunnuksesi on instanssin ”omistaja” (yleensä instanssi nimetään sen omistavan tunnuksen mukaan). Et koskaan halua poistaa tätä tunnusta romuttamatta instanssia, tai saatat päätyä hyvin omituiseen käyttäytymiseen. Tällä tunnuksella (koska se on instanssin omistaja) on valtuudet luoda tietokantoja, mutta sen ei tarvitse. Tämä toisen DB2-käyttäjän Ember Crooksin blogikirjoitus auttaa selittämään instanssin käsitettä niille, jotka tuntevat Oraclen paremmin.
Instansseihin voidaan luoda tietokantoja. Palaamme tähän myöhemmin.
DAS (eli DB2 Administration Server) on oikeastaan enemmänkin palvelu. Se mahdollistaa joidenkin GUI-työkalujen, kuten DB2 Control Centerin, käyttöliittymän DB2:n kanssa. Ymmärtääkseni tämä palvelu ei ole välttämätön DB2:n toimimiselle, mutta se on usein välttämätön, jotta loppukäyttäjät voivat käyttää DB2:ta muusta kuin komentorivin näkökulmasta. (Mustaccio, olenko oikeassa?). Riippumatta siitä, kuinka monta instanssia sinulla on fyysisessä laatikossa, DAS-asennuksia on vain yksi. Tämä yksi asennus voi palvella kaikkia instansseja. DAS-palvelun suorittamiseen tarvitaan yleensä erillinen tunnus. Tämä on dasusr1. Et myöskään halua poistaa tätä tunnusta. Tällä tunnuksella ei yleensä ole valtuuksia luoda mitään objekteja tietokantaan.
Nyt aidan tunnus (eli db2fenc1). On hyvä idea, että sinulla on yksi näistä. Kun luot instanssin, voit määrittää fence ID:n. Jos teet niin, siitä tulee kyseinen ID. Jos et anna, instanssin omistajan ID:stä tulee aidan ID. Fence ID:tä käytetään tiettyjen tallennettujen proseduurien suorittamiseen DB2:ssa. DB2:ssa on kaksi tapaa suorittaa tallennettuja proseduureja: fenced ja unfenced. Unfenced tarkoittaa, että tallennettu proseduuri suoritetaan DB2-moottorin muistissa. Se toimii nopeammin, mutta jos tallennettu proseduuri on muutakin kuin SQL:ää (eli sisältää esimerkiksi C++- tai Java-koodia) ja se kaatuu, se voi uhata moottoria ja itse asiassa kaataa sen ja aiheuttaa vahinkoa. Aidatut tallennetut proseduurit suoritetaan DB2-moottorin muistin ulkopuolella. Ne ovat siten hitaampia, mutta jos ne kaatuvat, ne eivät uhkaa DB2-moottoria, koska ne toimivat omalla suojatulla muistialueellaan. Esimerkki siitä, miten DB2 käyttää tätä: jos suoritat db2 export -apuohjelman ADMIN_CMD tallennetusta proseduurista, DB2 vaihtaa käyttäjän sinuun, joka itse asiassa suorittaa viennin. Tämä johtuu siitä, että teet tiedosto I/O:ta ja DB2 haluaa suorittaa tämän suojattuna moottorin suojaamiseksi. Vaikka siis suorittaisitkin tämän tallennetun proseduurikutsun instanssin omistajana, DB2 vaihtaa tunnuksen aidatuksi tunnukseksi (eikä sinulla ole mahdollisuutta muuttaa tätä käyttäytymistä). Jos tarkastelet vientitiedoston omistajan oikeuksia, huomaat, että se on aidattu tunnus eikä instanssin tunnus (tai muu tunnus, jota käytit tallennetun proseduurin käynnistämiseen). Tietenkin jos instanssitunnuksesi on aidattu tunnuksesi, se näyttää sinusta yhdeltä ja samalta.
(Hengitä syvään).
OK. Sanoin siis kaiken tämän esitelläkseni sinulle DB2:n pähkinänkuoressa. Nyt päästään siihen, mikä sinua luultavasti huolestuttaa – kuka omistaa mitä? Se, mikä tahansa tunnus luo tietokannan, omistaa tietokannan. DB2 hyväksyy ”ryhmiä”, joilla on yleensä DBADM (eli tietokannan ylläpitäjällä) valtuudet luoda tietokantoja. Jos siis loisit tietokannan käyttämällä instanssin omistajatunnusta, se olisi tietokannan ja sen tietokantaan luomien objektien omistaja. Jos eri tunnus muodostaa yhteyden tietokantaan (kunhan sillä on oikeat oikeudet), se voi luoda objekteja ja omistaa ne.
Tässä on mielenkiintoinen asia ryhmien ja tunnusten suhteen DB2:ssa. Ne eivät käsittääkseni ole varsinaisesti objekteja. Joten niitä ei voi pudottaa. Niitä ei voi myöskään luoda (ainakaan nähdäkseni). Kun myönnät tai peruutat oikeuden tunnukselle, DB2 tallentaa maininnan kyseisestä ryhmästä tai tunnuksesta. Mutta DB2 ei oikeastaan ”luo” niitä. Useimmiten olen nähnyt DB2:n osoittavan käyttöjärjestelmään tai LDAP:hen tai molempiin tunnusten todentamiseksi. Jos tunnukset poistetaan, tunnusten käyttöoikeudet on poistettava manuaalisesti ja/tai objektien omistusoikeus on siirrettävä. Tässä ei ole mitään maagista. Esitin samanlaisen kysymyksen, joka liittyy varmuuskopioinnin/palauttamisen tekemiseen eri järjestelmään ja siihen, miten se vaikuttaa käyttöoikeuksiin.
Ja lopuksi kommenttiisi skeemoista: yleensä jokainen ID vastaa omaa skeemaansa. Se, onko skeema olemassa (DBADM-tunnuksen nimenomaisesti luoma vai loppukäyttäjän IMPLICIT_SCHEMA-oikeuden kautta luoma), on toinen kysymys. Yleensä mikä tahansa ID yhdistää tietokantaan, DB2 olettaa, että skeema on sama kuin käyttäjätunnus ja sinun on vaihdettava skeemaa (SET SCHEMA MYSCHEMA) tai mainittava eksplisiittisesti objektisi (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) voidaksesi työskennellä niiden kanssa.
Toivottavasti tämä auttaa.