DB2 (LUW) equivalent for Oracle “drop user cascade”
Először hasznos lehet a DB2 általános áttekintése.
A DB2 telepítésekor létrehoz egy példányt. Gondolj erre úgy, mint egy “szerverre”. Egy példányon belül nulla és sok adatbázis lehet (nem mondhatom, hogy ismerem a határt). Amikor a DB2-t lokálisan létrehoztad, létrehozott neked egy DB2 nevű példányt. Általában amikor a DB2-t telepítjük mondjuk egy Unix szerverre, elnevezzük a példányokat. Egynél több példány is lehet ugyanazon a fizikai szerveren. A dsinst1 azonosító a példány “tulajdonosa” (általában a példányt a tulajdonos azonosítójáról nevezik el). Ezt az azonosítót soha nem akarod törölni a példány selejtezése nélkül, különben nagyon furcsa viselkedésekkel járhatsz. Ez az azonosító (mivel ő a példány tulajdonosa) jogosult adatbázisokat létrehozni, de nem köteles. A DB2-felhasználó Ember Crooks blogbejegyzése segít elmagyarázni a példány fogalmát azoknak, akik jobban ismerik az Oracle-t.
A példányokon belül létrehozhatók adatbázisok. Erre később még visszatérünk.
A DAS (vagy DB2 Administration Server) valójában inkább egy szolgáltatás. Ez teszi lehetővé, hogy néhány GUI eszköz, mint például a DB2 Control Center, kapcsolódjon a DB2-hez. Amennyire én tudom, ez a szolgáltatás nem szükséges a DB2 futtatásához, de gyakran szükséges a végfelhasználók számára, hogy a DB2-vel nem parancssoros szemszögből kapcsolódhassanak. (Mustaccio jól gondolom?). Nem számít, hogy hány példány van egy fizikai dobozon, a DAS-nak csak egy telepítése van. Ez az egy telepítés képes kiszolgálni az összes példányt. Általában van egy külön azonosító, ami a DAS szolgáltatás futtatásához szükséges. Ez a dasusr1. Ismétlem, ezt az azonosítót nem szabad törölni. Ennek az azonosítónak általában nincs jogosultsága objektumok létrehozására az adatbázisban.
Következik a kerítés azonosítója (azaz a db2fenc1). Jó ötlet, ha van egy ilyen. Egy példány létrehozásakor megadhat egy kerítés azonosítót. Ha ezt megteszi, akkor ez lesz az az ID. Ha nem, akkor a példány tulajdonosának azonosítója lesz a kerítés azonosítója. A fence ID-t bizonyos tárolt eljárások futtatásához használjuk a DB2-n belül. A DB2-ben a tárolt eljárások futtatásának két módja van: a bekerített és a bekerítés nélküli. A kerítés nélküli azt jelenti, hogy a tárolt eljárás a DB2 motor memóriájában fut. Gyorsabban fut, de ha a tárolt eljárás több mint SQL (azaz például C++ vagy Java kódot tartalmaz), és összeomlik, akkor veszélyeztetheti a motort, és ténylegesen összeomolhat, és kárt okozhat. A bekerített tárolt eljárások a DB2 motor memóriáján kívül futnak. Így lassabbak, de ha összeomlanak, nem fenyegetik a DB2 motort, mert a saját védett memóriaterületükön futnak. Egy példa arra, hogyan használja ezt a DB2: ha a ADMIN_CMD tárolt eljárásból futtatjuk a db2 export segédprogramot, akkor a DB2 átállítja a felhasználót, aki ténylegesen végrehajtja az exportot. Ez azért van így, mert fájl I/O-t hajt végre, és a DB2 ezt elkerítve kívánja futtatni, hogy megvédje a motort. Tehát még akkor is, ha ezt a tárolt eljáráshívást példánytulajdonosként futtatod, a DB2 átváltja az azonosítót a bekerített azonosítóra (anélkül, hogy ezt a viselkedést megváltoztathatnád). Ha megnézi a jogosultságokat, hogy ki a tulajdonosa az exportfájlnak, akkor észre fogja venni, hogy az a bekerített azonosító, nem pedig a példányazonosító (vagy más azonosító, amellyel a tárolt eljárást elindította). Természetesen, ha a példányazonosítód a bekerített azonosítód, akkor ez neked egy és ugyanaz lesz.
(Nagy levegővétel).
OK. Szóval mindezt azért mondtam, hogy dióhéjban bemutassam neked a DB2-t. Most pedig rátérünk arra, ami miatt valószínűleg aggódsz — kié mi? Amelyik azonosító létrehozza az adatbázist, azé az adatbázis. Vannak “csoportok”, amelyeket a DB2 elfogad, és amelyek általában DBADM (azaz adatbázis-adminisztrátor) jogosultsággal rendelkeznek az adatbázisok létrehozására. Tehát ha Ön a példánytulajdonos azonosítójával hoz létre egy adatbázist, akkor ez lesz az adatbázis és az általa az adatbázisban létrehozott objektumok tulajdonosa. Ha egy másik azonosító csatlakozik az adatbázishoz (feltéve, hogy rendelkezik a megfelelő jogosultságokkal), akkor létrehozhat objektumokat és birtokolhatja azokat.
Itt jön a DB2-n belüli csoportok és azonosítók érdekessége. Ezek nem igazán objektumok, amennyire én látom. Tehát nem tudod őket eldobni. Létrehozni sem tudod őket (legalábbis amennyire én látom). Amikor engedélyt adsz vagy visszavonsz egy azonosítóhoz, akkor a DB2 tárolja az adott csoport vagy azonosító megemlítését. De a DB2 nem igazán “hozza létre” őket. Leggyakrabban azt láttam, hogy a DB2 az operációs rendszerre vagy egy LDAP-ra vagy mindkettőre mutat az azonosítók hitelesítésére. Ha az azonosítókat eltávolítják, akkor manuálisan el kell távolítani a jogosultságokat az azonosítókról és/vagy át kell adni az objektumok tulajdonjogát. Itt nincs semmi varázslatos dolog. Én egy hasonló kérdést tettem fel, amelynek köze van a más rendszerre történő mentéshez/visszaállításhoz, és ahhoz, hogy ez hogyan befolyásolja az engedélyeket.
És végül a sémákkal kapcsolatos megjegyzésedhez: általában minden azonosító a saját sémájához tartozik. Az, hogy a séma létezik-e (a DBADM azonosító által explicit módon létrehozott vagy a végfelhasználó által az IMPLICIT_SCHEMA engedélyen keresztül létrehozott), az egy másik kérdés. Általában bármilyen azonosítóval is csatlakozik egy adatbázishoz, a DB2 feltételezi, hogy a séma megegyezik a felhasználói azonosítóval, és sémát kell váltani (SET SCHEMA MYSCHEMA) vagy explicit módon megemlíteni az objektumokat (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE), hogy dolgozni tudjunk velük.
Remélem, ez segít.