DB2 (LUW) equivalente per Oracle “drop user cascade”
Potrebbe essere utile rivedere DB2 in generale prima. Pensate a questo come ad un “server”. Un’istanza può avere da zero a molti database al suo interno (non posso dire di conoscere il limite). Quando hai creato DB2 localmente ha creato un’istanza per te chiamata DB2. Di solito quando installi DB2 su un server Unix, dai un nome alle tue istanze. Puoi avere più di un’istanza sullo stesso server fisico. Il vostro id dsinst1 è il “proprietario” dell’istanza (di solito l’istanza prende il nome dall’ID che la possiede). Non si vuole mai cancellare questo ID senza eliminare l’istanza o si può finire con alcuni comportamenti molto strani. Questo ID (poiché è il proprietario dell’istanza) ha il potere di creare database, ma non deve farlo. Questo post sul blog del collega Ember Crooks, utente di DB2, aiuta a spiegare il concetto di istanza a coloro che hanno più familiarità con Oracle.
Le istanze possono avere database creati al loro interno. Torneremo su questo più tardi.
Il DAS (o DB2 Administration Server) è davvero più simile a un servizio. È ciò che permette ad alcuni strumenti GUI come DB2 Control Center di interfacciarsi con DB2. Da quello che ho capito, questo servizio non è necessario per il funzionamento di DB2, ma è spesso necessario per gli utenti finali per interfacciarsi con DB2 da una prospettiva di linea non di comando. (Mustaccio, ho ragione?). Non importa quante istanze hai su una scatola fisica, c’è solo un’installazione del DAS. Questa installazione può servire tutte le istanze. Di solito c’è un ID separato che è necessario per eseguire il servizio DAS. Questo è il vostro dasusr1. Di nuovo, non vuoi cancellare questo ID. Questo ID di solito non ha autorità per creare alcun oggetto all’interno del vostro database.
Ora per l’ID del recinto (cioè, db2fenc1). Avere uno di questi è una buona idea. Quando create un’istanza potete specificare un ID del recinto. Se lo fate, diventa quell’ID. Se non lo fate, allora l’ID del proprietario dell’istanza diventa l’ID del recinto. L’ID del recinto è usato per eseguire certe procedure memorizzate in DB2. In DB2 ci sono due modi per eseguire le stored procedure: fenced e unfenced. Unfenced significa che la stored procedure viene eseguita all’interno della memoria del motore DB2. Verrà eseguita più velocemente, ma se la stored procedure è più che SQL (cioè, contiene codice C++ o Java per esempio) e si blocca, può minacciare il motore ed effettivamente bloccarlo e causare danni. Le stored procedure recintate vengono eseguite al di fuori della memoria del motore DB2. Sono quindi più lente, ma se vanno in crash non minacciano il motore DB2 perché vengono eseguite nella loro area di memoria protetta. Un esempio di come questo viene usato da DB2: se eseguite l’utilità di esportazione db2 dalla stored procedure ADMIN_CMD, DB2 cambierà l’utente su di voi di chi effettivamente esegue l’esportazione. Questo perché state facendo I/O su file e DB2 vuole eseguire questa procedura in modo recintato per proteggere il motore. Quindi, anche se stai eseguendo questa chiamata di stored procedure come proprietario dell’istanza, DB2 cambierà l’ID nell’ID recintato (senza possibilità di alterare questo comportamento). Se guardate i permessi di chi possiede il file di esportazione, noterete che è l’ID protetto, piuttosto che l’ID dell’istanza (o altro ID che avete usato per lanciare la stored procedure). Naturalmente se il tuo ID di istanza è il tuo ID recintato, allora ti sembrerà la stessa cosa.
(Grande respiro).
OK. Ho detto tutto questo per presentarvi DB2 in poche parole. Ora arriviamo a ciò di cui probabilmente vi state preoccupando — chi possiede cosa? L’ID che crea il database è il proprietario del database. Ci sono “gruppi” che DB2 accetta che generalmente hanno l’autorità DBADM (cioè l’amministratore del database) per creare database. Quindi se hai creato un database usando il tuo ID proprietario dell’istanza, allora sarebbe il proprietario del database e di qualsiasi oggetto che crea all’interno del database. Se un ID diverso si connette al database (finché ha i permessi corretti) può creare oggetti e possederli.
Ecco la cosa interessante dei gruppi e degli ID in DB2. Non sono veramente oggetti da quello che posso vedere. Quindi non potete eliminarli. Non puoi nemmeno crearli (almeno da quello che posso vedere). Quando concedi o revochi un permesso a un ID, DB2 poi memorizza la menzione di quel gruppo o ID. Ma DB2 non li “crea” veramente. Il più delle volte ho visto DB2 puntare al sistema operativo o a un LDAP o a entrambi per autenticare gli ID. Se gli ID vengono rimossi, è necessario rimuovere manualmente i permessi dagli ID e/o trasferire la proprietà degli oggetti. Non c’è niente di magico in questo caso. Ho fatto una domanda simile avendo a che fare con il fare un backup/ripristino su un sistema diverso e come questo influisce sui permessi.
E infine per il tuo commento sugli schemi, generalmente ogni ID corrisponde al proprio schema. Che lo schema esista o meno (creato dall’ID DBADM esplicitamente o dall’utente finale attraverso il permesso IMPLICIT_SCHEMA) è un’altra questione. Generalmente qualsiasi ID si connette a un database, DB2 assume che lo schema sia lo stesso dell’id utente e devi cambiare schema (SET SCHEMA MYSCHEMA) o menzionare esplicitamente i tuoi oggetti (SELECT * FROM MY_OTHER_SCHEMA.MY_TABLE) per lavorare con loro.
Spero che questo aiuti.