Kosmous beyond the clouds: Sviluppo, Formazione e Consulenza Informatica

Oracle DBA 9i - Cap. 3

Prima di analizzare i comandi che permettono di avviare e chiudere il database, diamo uno sguardo al sistema di autenticazione.
Nel database esistono alcune tabelle che contengono informazioni sugli utenti, come la login, la password, i privilegi e così via. Ma se il database non è ancora attivo, il sistema non è in grado di accedere a tali tabelle e verificare se le credenziali fornite per l’accesso sono valide.
Questo problema è evidente per le utenze “amministrative”, ad esempio per l’utente in grado di avviare o chiudere il database: se il database è chiuso, come si fa ad autenticare l’utente che deve avviarlo?
Il problema viene risolto utilizzando un metodo di autenticazione esterno al database, basato ad esempio su file o su sistema operativo.

Durante la creazione del database vengono creati, per default due utenti:

  • SYS (default password: CHANGE_ON_INSTALL)
  • SYSTEM (default password: MANAGER)

SYS è il proprietario di tutte le tabelle di sistema, mentre SYSTEM è un amministratore meno “potente” di SYS, ma sufficiente per svolgere la maggior parte dei compiti tipici dell’amministratore del database.


3.1 Autenticazione

In Oracle sono definiti due “ruoli” (Oracle li definisce privilegi, ma ritengo che sia più corretto chiamarli ruoli anche se non possono essere modificati): SYSOPER e SYSDBA.
Vediamo i privilegi rispettivamente assegnati:

SYSOPER
  • STARTUP e SHUTDOWN
  • ALTER DATABASE [ OPEN / MOUNT ]
  • ALTER DATABASE BACKUP
  • ALTER DATABASE ARCHIVELOG
  • RECOVER DATABASE
  • CREATE SPFILE
  • RESTRICTED SESSION
SYSDBA
  • Tutti i privilegi inclusi in SYSOPER con ADMIN OPTION
  • CREATE DATABASE
  • ALTER DATABASE [ BEGIN / END ] BACKUP
  • RECOVER DATABASE UNTIL (Time-based Recovery)


3.2 Autenticazione tramite SO

Durante l’installazione del software vengono creati sul sistema operativo due gruppi, generalmente indicati come OSOPER ed OSDBA cui vengono associati rispettivamente i due “ruoli” appena visti: SYSOPER e SYSDBA.
Generalmente su windows ho ORA_OPER ed ORA_DBA, mentre su UNIX i gruppi vengono chiamati DBA ed OPER.
Attenzione: in molte installazioni viene definito solo il gruppo OSDBA. Inoltre, anche se non si vuol utilizzare l’autenticazione tramite OS, è molto importante la presenza del gruppo OSDBA, in quanto molte operazioni amministrative prevedono la creazioni di oggetti sul file system, e quindi è necessario avere i permessi necessari a livello di SO.

A questo punto, qualunque utente appartenente al gruppo può connettersi al sistema senza fornire login/password: semplicemente verranno fornite al sistema le credenziali con cui ci si è precedentemente connessi al SO.
Quindi se il SO ha autenticato l’utente, Oracle non effettuerà più alcun controllo.
Questo è il motivo per cui questa modalità di autenticazione deve essere abilitata solo se la rete in cui si opera è sicura, altrimenti “chiunque” potrebbe accedere come amministratore del database con conseguenze facilmente immaginabili.
Affinché sia possibile l’autenticazione tramite SO, il parametro di inizializzazione (presente nel PFILE) deve essere impostato a NONE:
REMOTE_LOGIN_PASSWORDFILE = NONE
La connessione avviene scrivendo in SQLPLUS :
SQL> CONNECT / AS SYSDBA  (o SYSOPER)

3.3 Autenticazione tramite PASSWORD FILE

Gli utenti possono connettersi, indipendentemente dall’account utilizzato sul SO, specificando login/password.
Per utilizzare questo metodo di autenticazione devo prima aver creato il password file.
Vediamo nel dettaglio i passi da eseguire:

- Creare il password file mediante l’utility ORAPWD.
- Impostare REMOTE_LOGIN_PASSWORDFILE
- Inserire nel file gli utenti cui permettere l’accesso amministrativo.

Il comando per la creazione del pwd file è:
orapwd file= password= entries=
Dove:
    FILE indica il nome (completo della path) del file da creare.
    PASSWORD è la password dell’utente SYS
    ENTRIES (opzionale)è numero utenti max cui posso dare SYSOPER o SYSDBA.

Esempio:
C:oraclebinorapwd.exe file=c:oracledatabasePWDORCL.ora 
password=change_on_install entries=4
Attenzione ad impostare correttamente il valore di entries, in quanto se supero limite impostato devo ricreare il file. Tuttavia è bene fare una precisazione. Se io fisso il valore 4, significa che Oracle creerà il file di una certa dimensione, garantendo che al suo interno ci sarà lo spazio necessario ad inserire almeno 4 utenze. Nella realtà potrei memorizzare anche più di 4 utenti, in quanto Oracle gestisce la dimensione in dei file allocando un certo numero di blocchi, e permettendo di superare il valore inserito (4 nell’esempio) finchè c’è spazio all’interno dei blocchi usati dal file.
Il numero effettivo dipenderà pertanto dal Sistema Operativo.

REMOTE_LOGIN_PASSWORDFILE può valere:
    NONE non viene usato il password file, quindi è possibile solo l’autenticazione tramite SO.
    EXCLUSIVE Il password file viene usato e posso aggiungere ad esso altri utenti oltre SYS.
    SHARED Il password file viene usato e viene condiviso per più database: utile se ho un amministratore che deve gestire più database. Tuttavia in questo caso è possibile inserire nel file solo l’utente SYS.
Attenzione: Quando ci si connette utilizzando SYSDBA o SYSOPER, il database non ci vede come l’utente effettivo con il quale ci stiamo loggando, ma ci si aggancia ad uno schema di default. In particolare:
    SYSDBA, viene associato allo schema dell’utente SYS.
    SYSOPER viene associato allo schema PUBLIC.
La connessione avviene utilizzando il comando:
SQL> CONNECT SYS/change_on_install AS SYSDBA 
Oppure:
SQL> CONNECT fabio/oracle AS SYSOPER
Per inserire gli utenti nel password file posso utilizzare il seguente comando:
SQL> GRANT SYSDBA TO fabio;
Mentre per eliminare gli utenti utilizzo:
SQL> REVOKE SYSDBA FROM fabio;
Per sapere quali utenti hanno il ruolo SYSDBA o SYSOPER, posso fare una query sulla vista V$PWFILE_USERS:
SQL> SELECT * FROM V$PWFILE_USERS;
Ovviamente, per eseguire tali comandi devo avere gli opportuni privilegi.


3.4 STARTUP

Prima di analizzare la sintassi dei comandi per avviare il database, rivediamo brevemente cosa succede quando si avvia un database.

1) Lo stato iniziale viene definito CLOSED

2) Viene letto il PFILE (o SPFILE), ed in base ai parametri in esso specificati viene attivata l’istanza. A questo punto il sistema si trova nello stato definito NOMOUNT.
Nel PFILE esiste il parametro control_files che indica la path completa del CF (Es: control_files=c:oracleoradataORCLcontrol01.ctl )

3) Viene letto il CF ed il sistema raggiunge lo stato di MOUNT.
Il CF contiene le path complete di tutti gli altri file che costituiscono il database. Il sistema a questo punto conosce quali file devono essere aperti, e dove si trovano.

4) Vengono aperti e controllati tutti gli altri file e viene consentito l’accesso agli utenti normali. Questo stato viene definito OPEN.


Comandi:

STARTUP [ OPEN ]
Serve per aprire il database, passando dallo stato di CLOSED allo stato OPEN.

STARTUP NOMOUNT
Serve per passare dallo stato di CLOSED allo stato NOMOUNT.

STARTUP MOUNT
Serve per passare dallo stato di CLOSED allo stato NOMOUNT.
Es:
SQL> STARTUP MOUNT;
Se sono nello stato di NOMOUNT e voglio andare nello stato MOUNT, uso il comando:
SQL> ALTER DATABASE MOUNT;
Per andare allo stato OPEN, sia che mi trovo in MOUNT che in NOMOUNT uso:
SQL> ALTER DATABASE OPEN;

STARTUP PFILE=
In questo caso si sta forzando il sistema ad utilizzare il PFILE indicato invece del PFILE standard. Questa operazione risulta particolarmente utile quando si vuol far lavorare il database, per un periodo limitato, con opzioni o parametri diversi. In questo caso si fa una copia del PFILE originale, si modificano i parametri in esso contenuti (della copia), e si avvia il database.
Per ritornare allo stato normale,rileggendo il PFILE originale, si lancerà il semplice STARTUP.
ES:
SQL> STARTUP MOUNT PFILE=c:mio_pfile.txt

STARTUP RESTRICT
Serve per aprire il database in modalità “restricted”. In questo stato solo gli utenti che hanno il privilegio RESTRICTED SESSION potranno connettersi al database.

Se il Database è già aperto, o se volessi modificarne lo stato senza chiudere e riaprire, posso usare:
SQL> ALTER SYSTEM [ ENABLE / DISABLE ] RESTRICTED SESSION;
Se invece volessi aprire il Database in modalità READ ONLY , impedendo quindi la modifica dei dati (attenzione, in questa modalità possono comunque essere fatte alcune modifiche), posso usare:
SQL> ALTER DATABASE OPEN READ ONLY;
mentre per tornare allo stato di prima:
SQL> ALTER DATABASE OPEN READ WRITE;

STARTUP FORCE
Lo vedremo nel paragrafo seguente, quando tratteremo lo SHUTDOWN.


Operazioni tipiche eseguite nei vari stadi:
    NOMOUNT: creazione del database e creazione del nuovo Control File.
    MOUNT: Operazioni di recovery, spostamento e rename dei files, passaggio da ARCHIVELOG a NOARCHIVELOG e viceversa.
    OPEN: normale operatività del database.




3.5 SHUTDOWN

L’operazione di Shutdown permette di portare un database dallo stato in cui si trova allo stato di CLOSED.
I passaggi eseguiti sono brevemente:

1) Chiusura delle eventuali sessioni aperte
2) Salvataggio su file di tutte le modifiche presenti in memoria.
3) Sincronizzazione di tutti i files del database (Timestamp ed SCN).
4) Rilascio dei Locks sui files e di tutte le altre risorse allocate (memoria, etc.)


SHUTDOWN [ NORMAL ]
Il sistema impedisce nuove connessioni e attende che tutti gli utenti si disconnettano. Quindi effettua la chiusura del Database. Se anche un solo utente continua a lavorare, il database attenderà la conclusione della sua sessione prima di chiudere il database.


SHUTDOWN IMMEDIATE
Il sistema disconnette tutti gli utenti, ed effettua la chiusura del Database. Se gli utenti hanno delle transazioni in corso, esse vengono annullate (rollback).

SHUTDOWN TRANSACTIONAL
E’ una via di mezzo tra l’IMMEDIATE ed il NORMAL: il sistema impedisce nuove connessioni e attende che tutti gli utenti terminino la transazione in corso, cioè aspetta il COMMIT o ROLLBACK prima di terminare la loro sessione. Quindi effettua la chiusura del Database. In questo modo gli utenti non perdono il lavoro in corso.

SHUTDOWN ABORT
Se il Server ha qualche problema, i comandi di shutdown precedenti possono non funzionare: il sistema prima di chiudere il d atabase deve sincronizzare correttamente tutti i files. Se uno di essi si danneggia o non è più raggiungibile (ad esempio si è rotto il disco che lo contiene), o se c’è un altro tipo di problema, lo shutdown non funziona, ed il sistema si blocca.
In questi casi si può forzare la chiusura utilizzando lo SHUTDOWN ABORT, che ha un effetto paragonabile al togliere la corrente al pc: la memoria non viene scaricata, i file non vengono aggiornati e sincronizzati, ma vengono rilasciate tutte le risorse. Quindi, al successivo riavvio il database andrà in RECOVERY MODE, ed a secondo del tipo di problema verificatosi potrei perdere l’intero database se non ho delle copie di backup.

In questi casi, prima di utilizzare il comando SHUTDOWN ABORT, conviene provare lo STARTUP FORCE:

STARTUP FORCE
Questo comando, prova dapprima a chiudere il database, e poi ad avviarlo in modalità STARTUP RESTRICT.
Non è detto che riesca a risolvere la situazione, in quanto dipende dal tipo di problema che si è verificato, ma sicuramente è meno drastico dello SHUTDOWN ABORT, in quanto, in caso di problemi su un solo file, riesce a sincronizzare tutti gli altri, riducendo così le operazioni di eventuale Recovery.
Per questo motivo tale comando è stato inserito nella sezione dedicata allo Shutdown invece che nella sezione dello STARTUP.


3.6 PFILE ed SPFILE

I parametri di inizializzazione possono essere ulteriormente catalogati in statici e dinamici:
Quelli statici sono così definiti perché, affinché la modifica abbia effetto, è necessario riavviare il database, mentre quelli dinamici possono essere modificati senza essere costretti a riavviare il database.
Per modificare il valore di un parametro, si utilizza il comando:
ALTER SYSTEM SET nome_parametro=nuovo_valore;
Se ho un database avviato con PFILE e modifico un parametro dinamicamente con ALTER SYSTEM, devo anche ricordarmi di modificare il valore corrispondente nel PFILE, altrimenti al successivo riavvio del database, il sistema leggerà il PFILE, impostando il parametro al valore in esso indicato.

L’SPFILE non è altro che un file avente lo stesso contenuto del PFILE (ma in formato binario e quindi non più editabile direttamente), ma aggiornato direttamente dal database.

Si può creare (devo avere il privilegio SYSOPER o SYSDBA) utilizzando il comando
SQL> CREATE SPFILE='C:ora_cledatabaseSPFILEORCL.ORA’
     FROM PFILE='C:oracleadminORCLpfileinit.ora';
Oppure con:
SQL> CREATE SPFILE FROM PFILE='C:oracleadminORCLpfileinit.ora';
A questo punto, tutte le modifiche apportate con il comando:
ALTER SYSTEM SET nome_parametro=nuovo_valore;
verranno salvate in automatico nell’SPFILE, e non andranno perdute in caso di riavvio del database.

Il comando ha un’ulteriore clausola SCOPE che può assumere tre valori:

    SPFILE:
    le modifiche apportate da ALTER SYSTEM verranno salvate solo nell'SPFILE. Pertanto affinchè diventino attive occorre eseguire uno shutdown e startup. Questo è l'unico mezzo per modificare i parametri statici.

    MEMORY:
    le modifiche all'istanza verranno subito attivate, ma non verranno salvate sul file. Pertanto dopo lo startup e shutdown queste modifiche verranno perse. Ovviamente non posso usare questa clausola con i parametri statici.

    BOTH:
    questo è il valore di default della clausola SCOPE se sto utilizzando un SPFILE: le modifiche apportate da ALTER SYSTEM verranno subito applicate all'instanza e saranno anche salvate nello SPFILE. Ovviamente non posso usare questa clausola per i parametri statici.
Esempio:
SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=8 SCOPE=MEMORY;
Se volessi sapere qual'è l'SPFILE utilizzato dall'instanza attiva, uso il comando:
SQL> SHOW PARAMETERS SPFILE;
Per avere informazioni sul valore dei vari parametri di inizializzazione, posso usare le viste:

V$PARAMETER
questa vista era presente anche nelle vecchie versioni del database, e visualizza il valore corrente dei parametri;
V$PARAMETER2
restituisce le stesse informazioni della V$PARAMETER, ma è più leggibile;
V$SPPARAMETER
visualizza il valore dei parametri come sono memorizzati nel SPFILE; Se non si sta usando un SPFILE restituisce NULL;


3.7 Sessioni e KILL

Se volessi sapere quali sono le sessioni attive, posso eseguire una query sulla vista: V$SESSION
SQL> SELECT SID, SERIAL#, USERNAME, STATUS, OSUSER, MACHINE,
PROGRAM, TYPE FROM V$SESSION;
Con questa semplice query posso vedere chi è connesso al database, da quale macchina, con quale programma etc.

Se volessi chiudere una sessione tra quelle indicate, devo ricavare dalla vista precedente il SID e SERIAL#, e quindi lanciare il comando:
SQL> ALTER SYSTEM KILL SESSION ‘SID, SERIAL#’;
Es:
SQL> ALTER SYSTEM KILL SESSION ‘8, 13’;
La sessione dell’utente viene quindi terminata, e l’eventuale comando in esecuzione viene anch’esso terminato e viene eseguito il rollback.

Se la sessione terminata si trovava nello stato INACTIVE (colonna STATUS di V$SESSION), lo stato passa in KILLED, e l’utente si accorgerà di essere stato soppresso solo quando lancerà un altro comando SQL. Subito dopo verranno eliminati i suoi riferimenti presenti in V$SESSION.

Se invece la sessione terminata si trovava nello stato ACTIVE, il messaggio di errore viene subito mostrato all’utente.

Per permettere ad utente di terminare la transazione corrente posso invece utilizzare:
SQL> ALTER SYSTEM DISCONNECT SESSION ‘SID, 
SERIAL#’ POST_TRANSACTION;
In questo modo l’utente continuerà a lavorare fino a quando non lancerà un COMMIT o ROLLBACK. Se invece volessi buttarlo fuori immediatamente, potrei usare IMMEDIATE al posto di POST_TRANSACTION:

SQL> ALTER SYSTEM DISCONNECT SESSION ‘SID, 
SERIAL#’ IMMEDIATE;
SQL> ALTER SYSTEM DISCONNECT SESSION ‘8,26’ IMMEDIATE;



Vi invitiamo ad inviarci commenti, eventuali segnalazioni di errore e quant'altro.



Questo documento non è un documento ufficiale della Oracle Corporation. Oracle detiene tutti i diritti sulla propria documentazione. Alcuni termini usati sono trademarks registrati. In caso di dubbi o incertezze consultate la documentazione ufficiale di Oracle o contattate il Customer Support di Oracle.
<< Capitolo 2 Capitolo 4 >>
Commenti (8)2005-02-21

14/09/2017 - for scrive:
Hello! cialis for sale , cialis , cialis , buy viagra online , cialis for sale ,
03/09/2017 - advance scrive:
Hello! loans for bad credit , loans for bad credit , payday advance loan , payday express ,
28/08/2017 - payday scrive:
Hello! payday express , buy cheap cialis , viagra soft tabs , payday express , payday express ,
24/08/2017 - viagra_online scrive:
Hello! generic cialis , viagra online , cialis , buy viagra online ,
09/08/2017 - buy_cialis scrive:
Hello! buy cialis , cialis online , payday loans online ,
01/08/2017 - cialis scrive:
Hello! personal loans , generic cialis online , generic viagra online , generic viagra online , generic cialis online ,
23/06/2017 - viagra scrive:
Hello! viagra , viagra india ,
10/01/2012 - luigi scrive:
molto chiaro, come tutte le vostre pagine. Grazie.