Il database Oracle 9i Appunti applicativi

Transcript

1 Ing. Fabio Binotto Il database Oracle 9i Appunti applicativi [1] L'istanza, SGA e PGA Un istanza di database si definisce come l'insieme dei processi attivi in background, più la SGA (System Global Area), cioè la memoria che Oracle si riserva allo startup. I processi di background eseguono l' I/O e tengono sotto controllo il funzionamento del database e di tutti gli altri processi. (Per vedere il nome dell'istanza sotto Unix: #echo $ORACLE_SID). La SGA è composta da: Shared Pool (parte di memoria usata per interpretare i comandi SQL e PL/SQL) Library Cache (in particolare carica i comandi, esegue il controllo di sintassi, dei privilegi etc.) Data Dictionary Cache (in particolare contiene le porzioni di dizionario dati che servono per lavorare) Database Buffer Cache (qui vengono caricati i dati di lavoro veri e propri, prelevati dai data files nei dischi rigidi; sono le copie dei blocchi di dati copiati dai data files; l'unità minima di lettura /scrittura dipende dal sistema operativo e generalmente è di 4kB oppure 8kB, ed inferiore a 64kB; questa unità viene definita dal parametro DB_BLOCK_SIZE; i dati vengono gestiti mediante un algoritmo LRU, per cui i dati non acceduti da un certo tempo vengono spostati per fare posto ai nuovi dati. Di fatto è costituita da tre sotto-caches indipendenti, definite mediante i parametri: DB_CACHE_SIZE (dimensione della cache di default), DB_KEEP_CACHE_SIZE (cache che memorizza i dati che si aspetta vengano riutilizzati), DB_RECYCLE_CACHE_SIZE (cache che memorizza i dati che si aspetta non vengano usati se non raramente)). Le informazioni sull'utilizzo sono memorizzate in V$DB_CACHE_ADVICE.

2 Java Pool (utilizzata per le stored procedure in Java, e per alcune librerie; sconsigliata per motivi di performance; meglio stored procedure in PL/SQL) Redo Log Buffer (area di memoria utilizzata per registrare i cambiamenti nei dati, prima che questi vengano consolidati nel database; lo scopo primario è il recovery dei dati, cioè ricostruire le transazioni sul database; contiene tutte le informazioni per ricreare i cambiamenti fatti da: INSERT, UPDATE, DELETE, CREATE, ALTER, DROP; è un buffer circolare, la cui dimensione è definita dal parametro LOG_BUFFER) Nota: all'avvio di Oracle il processo SMON esegue dei controlli di coerenza, e nel caso di problemi può applicare tutta una serie di transazioni o di roll-back fino a portarsi ad una situazione coerente; SMON interviene se, ad esempio, il database è stato chiuso male, e quindi il Control File registra delle incoerenze di sincronizzazione. Large Pool (area di memoria usata per creare una unica area di memoria, condivisa, per molti utenti, come nel caso di un sito web a cui accedono migliaia di utenti). Quando un utente si connette ad un server, attiva un processo server il quale esegue le istruzioni SQL per l'utente. Quando per ogni utente si attiva un processo si usa la modalità chiamata dedicated server connection ; altrimenti si parla di shared server connection. Nel caso di dedicated server connection la memoria allocata da ogni utente si chiama PGA (program global area). Quindi le aree di memoria fondamentalmente usate sono la SGA e la PGA; ogni utente avrà ( dedicated server connection ) la propria PGA. Per vedere l'area di memoria SGA dare: SQL> SHOW SGA A partire dalla versione 9i, la SGA può essere ridimensionata (per quel che riguarda Databases Buffer Cache, Shared Pool e Large Pool) senza chiudere l'istanza, e quindi a caldo. I parametri fondamentali della SGA sono: SGA_MAX_SIZE (massima dimensione della SGA) DB_CACHE_SIZE (cache del database, default 48MB su Unix, 52MB su Nt) LOG_BUFFER (buffer allocati dai redo log, attorno a 500kB) SHARED_POOL_SIZE (area per PL/SQL e dizionario dati, default 16 o 64MB) LARGE_POOL_SIZE (generalmente a 0, a meno che non vi sia PARRALEL_AUTOMATIC_TUNING=TRUE; Può servire per il Restore mediante RMAN, che diventa velocissimo: in questo caso andrà alta, per esempio a 24MB; è chiaro che può essere generalmente lasciata a 0, e messa a 24MB dinamicamente (a caldo) nel momento in cui serve il restore.) JAVA_POOL_SIZE (area per stored procedure Java; default 24MB; meglio mettere a 0,

3 salvo casi particolari, poiché purtroppo alcune stored procedure Oracle sono in Java (anche se ufficialmente sconsigliate)) Come vedere i parametri (esempio) SQL>SHOW PARAMETER LARGE (mostra tutti i parametri che contengono la parola large) SQL>SHOW PARAMETER JAVA (idem ma per la parola java) Esempi di modifica dei parametri a caldo: SQL> ALTER SYSTEM SET SHARED_POOL_SIZE = 64M; SQL> ALTER SYSTEM SET DB_CACHE_SIZE=96M; SQL> ALTER SYSTEM SET LARGE_POOL_SIZE=24M; (tenere presente che la somma delle aree non può eccedere la SGA_MAX_SIZE). La SGA ed i suio componenti Database Buffer Cache, Shared Pool e Large Pool possono crescre o decrescere in modo granulare: i granuli sono di 4MB se SGA<128MB, altrimenti i granuli sono di 16MB. I parametri fondamentali della PGA sono: OPEN_CURSORS (default 50) La memoria viene gestita per default in automatico con Oracle 9i (precedentemente vi erano parametri quali SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE, CREATE_BITMAP_AREA_SIZE) Ecco un esempio di parametri dando il comando SQL> SHOW PARAMETER SQL> show parameter active_instance_count integer aq_tm_processes integer 0 archive_lag_target integer 0 audit_file_dest?/rdbms/audit audit_sys_operations boolean FALSE audit_trail NONE background_core_dump partial background_dump_dest /oracle/admin/ora1/bdump backup_tape_io_slaves boolean FALSE bitmap_merge_area_size integer blank_trimming boolean FALSE buffer_pool_keep buffer_pool_recycle circuits integer 0 cluster_database boolean TRUE cluster_database_instances integer 2 cluster_interconnects commit_point_strength integer 1 compatible control_file_record_keep_time integer 7 control_files /metafora/oradata/ora/controlo

4 RA1.ctl, /engi/oradata/ora/con trolora2.ctl core_dump_dest /oracle/admin/ora1/cdump cpu_count integer 3 create_bitmap_area_size integer cursor_sharing EXACT cursor_space_for_time boolean FALSE db_block_buffers integer 0 db_block_checking boolean FALSE db_block_checksum boolean TRUE db_block_size integer db_cache_advice ON db_cache_size big integer db_create_file_dest db_create_online_log_dest_1 db_create_online_log_dest_2 db_create_online_log_dest_3 db_create_online_log_dest_4 db_create_online_log_dest_5 db_domain db_file_multiblock_read_count integer 16 db_file_name_convert db_files integer 100 db_keep_cache_size big integer 0 dblink_encrypt_login boolean FALSE db_name ORA db_recycle_cache_size big integer 0 dbwr_io_slaves integer 0 db_writer_processes integer 1 db_16k_cache_size big integer 0 db_2k_cache_size big integer 0 db_32k_cache_size big integer 0 db_4k_cache_size big integer 0 db_8k_cache_size big integer 0 dg_broker_config_file1?/dbs/dr1@.dat dg_broker_config_file2?/dbs/dr2@.dat dg_broker_start boolean FALSE disk_asynch_io boolean TRUE dispatchers distributed_lock_timeout integer 60 dml_locks integer 2440 drs_start boolean FALSE enqueue_resources integer 1024 event fal_client fal_server fast_start_io_target integer 0 fast_start_mttr_target integer 0 fast_start_parallel_rollback LOW file_mapping boolean FALSE filesystemio_options setall fixed_date gc_files_to_locks global_context_pool_size global_names boolean FALSE hash_area_size integer hash_join_enabled boolean TRUE hi_shared_memory_address integer 0 hs_autoregister boolean TRUE ifile file /oracle/admin/ora1/pfile/confi gora.ora instance_groups instance_name ORA instance_number integer 1 java_max_sessionspace_size integer 0 java_pool_size big integer java_soft_sessionspace_limit integer 0

5 job_queue_processes integer 4 large_pool_size big integer 0 license_max_sessions integer 0 license_max_users integer 0 license_sessions_warning integer 0 local_listener lock_name_space lock_sga boolean FALSE log_archive_dest log_archive_dest_state_1 enable log_archive_dest_state_10 enable log_archive_dest_state_2 enable log_archive_dest_state_3 enable log_archive_dest_state_4 enable log_archive_dest_state_5 enable log_archive_dest_state_6 enable log_archive_dest_state_7 enable log_archive_dest_state_8 enable log_archive_dest_state_9 enable log_archive_dest_1 log_archive_dest_10 log_archive_dest_2 log_archive_dest_3 log_archive_dest_4 log_archive_dest_5 log_archive_dest_6 log_archive_dest_7 log_archive_dest_8 log_archive_dest_9 log_archive_duplex_dest log_archive_format %t_%s.dbf log_archive_max_processes integer 2 log_archive_min_succeed_dest integer 1 log_archive_start boolean FALSE log_archive_trace integer 0 log_buffer integer log_checkpoint_interval integer 0 log_checkpoints_to_alert boolean FALSE log_checkpoint_timeout integer 1800 log_file_name_convert logmnr_max_persistent_sessions integer 1 log_parallelism integer 1 max_commit_propagation_delay integer 99 max_dispatchers integer 5 max_dump_file_size UNLIMITED max_enabled_roles integer 30 max_rollback_segments integer 122 max_shared_servers integer 20 mts_circuits integer 0 mts_dispatchers mts_listener_address mts_max_dispatchers integer 5 mts_max_servers integer 20 mts_multiple_listeners boolean FALSE mts_servers integer 0 mts_service ORA mts_sessions integer 0 nls_calendar nls_comp nls_currency nls_date_format nls_date_language nls_dual_currency nls_iso_currency nls_language AMERICAN nls_length_semantics BYTE

6 nls_nchar_conv_excp FALSE nls_numeric_characters nls_sort nls_territory AMERICA nls_time_format nls_timestamp_format nls_timestamp_tz_format nls_time_tz_format object_cache_max_size_percent integer 10 object_cache_optimal_size integer olap_page_pool_size integer open_cursors integer 300 open_links integer 4 open_links_per_instance integer 4 optimizer_dynamic_sampling integer 1 optimizer_features_enable optimizer_index_caching integer 0 optimizer_index_cost_adj integer 100 optimizer_max_permutations integer 2000 optimizer_mode CHOOSE oracle_trace_collection_name oracle_trace_collection_path?/otrace/admin/cdf oracle_trace_collection_size integer oracle_trace_enable boolean FALSE oracle_trace_facility_name oracled oracle_trace_facility_path?/otrace/admin/fdf os_authent_prefix ops$ os_roles boolean FALSE O7_DICTIONARY_ACCESSIBILITY boolean FALSE parallel_adaptive_multi_user boolean FALSE parallel_automatic_tuning boolean FALSE parallel_execution_message_size integer 2176 parallel_instance_group parallel_max_servers integer 5 parallel_min_percent integer 0 parallel_min_servers integer 0 parallel_server boolean TRUE parallel_server_instances integer 2 parallel_threads_per_cpu integer 2 partition_view_enabled boolean FALSE pga_aggregate_target big integer 0 plsql_compiler_flags INTERPRETED plsql_native_c_compiler plsql_native_library_dir plsql_native_library_subdir_count integer 0 plsql_native_linker plsql_native_make_file_name plsql_native_make_utility plsql_v2_compatibility boolean FALSE pre_page_sga boolean FALSE processes integer 500 query_rewrite_enabled false query_rewrite_integrity enforced rdbms_server_dn read_only_open_delayed boolean FALSE recovery_parallelism integer 0 remote_archive_enable true remote_dependencies_mode TIMESTAMP remote_listener remote_login_passwordfile NONE remote_os_authent boolean FALSE remote_os_roles boolean FALSE replication_dependency_tracking boolean TRUE resource_limit boolean FALSE resource_manager_plan rollback_segments

7 row_locking always serializable boolean FALSE serial_reuse DISABLE service_names ORA, ORA1, ORA2 session_cached_cursors integer 0 session_max_open_files integer 10 sessions integer 555 sga_max_size big integer shadow_core_dump partial shared_memory_address integer 0 shared_pool_reserved_size big integer shared_pool_size big integer shared_servers integer 0 shared_server_sessions integer 0 sort_area_retained_size integer sort_area_size integer spfile sql_trace boolean FALSE sql_version NATIVE sql92_security boolean FALSE standby_archive_dest?/dbs/arch standby_file_management MANUAL star_transformation_enabled FALSE statistics_level TYPICAL tape_asynch_io boolean TRUE thread integer 1 timed_os_statistics integer 0 timed_statistics boolean TRUE trace_enabled boolean TRUE tracefile_identifier transaction_auditing boolean TRUE transactions integer 610 transactions_per_rollback_segment integer 5 undo_management AUTO undo_retention integer 900 undo_suppress_errors boolean TRUE undo_tablespace undotbs1 use_indirect_data_buffers boolean FALSE user_dump_dest /oracle/admin/ora1/udump utl_file_dir * workarea_size_policy MANUAL

8 [2]I files del database I dati vengono memorizzati entro files sui dischi rigidi. I files sono di tre tipi: Data files: contengono i dati del database; Online redo log files: contengono una registrazione di tutti gli ultimi cambiamenti fatti sul database, per permettere anche il recovery del database in caso di failure; Control files: contengono tutte le informazioni per mantenere e verificare l'integrità del database. Gestiscono quindi la sincronizzazione di tutte le informazioni sul database. Senza questi files il database non può partire. Vi sono poi altri files: il file dei parametri (initinstance.ora); il password files (autentica gli utenti privilegiati alla gestione del database); gli Archived redo log files: sono copie offline dei redo log files; applicando tutte queste copie e partendo da un punto di backup, si possono ricostruire tutte le ultime transazioni di un database.

9 [3]I processi di background I processi di background mantengono le relazioni tra le strutture di memorizzazione fisica e quelle di memorizzazione temporanea. I processi obbligatori (per il funzionamento del database) sono: DBWn E' il processo Database Writer; trascrive i blocchi dal database buffer cache ai data files sui dischi; scrive quando: avviene un checkpoint, i dirty buffer raggiungono un valore di soglia, non ci sono buffer liberi, vi sono timeout, quando una tablespace viene posta offline, quando una tablespace viene posta in readonly, quando vi è un drop o truncate di una tabella, quando comincia un backup (SQL>ALTER TABLESPACE PIPPO BEGIN BACKUP), quando vi è una richiesta RAC di ping. PMON Sorveglia i processi server; nel caso di problemi, fa il rollback delle transazioni, rilascia i lock, rilascia altre risorse (nella versione 9, ogni secondi killa i processi server che riconosce come anomali o terminati non correttamente). CKPT IL processo di Checkpoint scrive ogni 3 secondi e memorizza dati nel control file per memorizzare in quale posizione dei redolog on line il recovery debba cominciare, nel caso di crash. Tiene quindi conto di quanto il DBWn abbia già scritto nei data files, e di quando sia stato scritto dai redolog online ai redolog files. LGWR E' il processo di log writer; scrive quando è vera una di queste condizioni: quando c'è un commit, quando è pieno per un terzo (siccome è piccolino, 500kB per esempio, scrive frequentemente), quando vi è 1MB di redo buffer, ogni tre secondi, prima che scriva il DBWn. Il processo LGWR chiede al DBWn di scrivere. LGWR conferma le sue operazioni sono dopo che il redo buffer è stato scritto su disco. SMON Dopo un crash ripristina la situazione (rollback o rollforward). ARCn E' il processo opzionale che automaticamente archivia gli online redo buffer quando è settato il modo ARCHIVELOG; preserva una registrazione di tutti i cambiamenti fatti sul database. E' una modalità cruciale per il recupero dei dati dopo la perdita di un disco. Di solito un database di produzione è configurato con gli ARCHIVELOG attivi. Regole per i processi di background: 1) i processi DBW e LGWR si fermeranno assieme, allo shutdown; 2) LGWR deve stare sempre avanti a DBWR, nella scrittura su disco; 3) LGWR starà avanti quanto definito da alcuni parametri che tengono conto del tempo per eseguire le transazioni.

10 Per memorizzare: il processo LGWR si può paragonare alla lepre, inseguita dal cane San Bernardo, il processo di DBW. Tipicamente LGWR scatta ogni decimo di secondo; il DBW scatta ogni minuti.

11 [4] Struttura logica del database La struttura è la seguente: tablespace (la più piccola entità amministrabile del database) Le tablespace possono essere messe fuori linea, eccetto per la system e per la undo attiva. Di una tablespace si può fare il backup separato. Una tablespace può essere messa in read/write o in read-only. segments (tabelle, indici) extents (insiemi di blocchi allocati dai segmenti) blocchi (la più piccola entità letta o scritta) [5] Gli utenti amministratori del database Gli utenti sys e system sono creati automaticamente durante la creazione del database. Essi hanno i diritti di DBA. Sys è il possessore del dizionario dei dati del database. System è il possessore delle tabelle addizionali e delle viste usate per la gestione del database. Per motivi di sicurezza, le password di sys e system vanno cambiate subito dopo la installazione del database. Modalità di connessione per sys: $sqlplus /nolog sql>connect / as sysdba

12 [6] I files di inizializzazione (dei parametri) Il file dei parametri può essere statico o dinamico (modificabile a caldo). File statico: pfile, file di testo, initsid.ora File dinamico: spfile, file binario, spfilesid.ora I file si trovano in $ORACLE_HOME/dbs Posso creare un file a partire dall'altro: SQL>CREATE SPFILE FROM PFILE SQL>CREATE PFILE FROM SPFILE Cosa userà Oracle? In ordine: $ORACLE_HOME/dbs/spfileSID.ora $ORACLE_HOME/dbs/spfile.ora $ORACLE_HOME/dbs/initSID.ora $ORACLE_HOME/dbs/init.ora Oppure a mano bisogna dare: SQL> startup pfile='xyz'; (non esiste startup spfile). Nota bene: le modifiche a caldo vengono registrate nell'spfile solo se il database è partito con quell'spfile. Le modifiche possibili sono del tipo: SQL>ALTER SYSTEM SET SHARED_POOL_SIZE=4M; SQL>ALTER SYSTEM SET UNDO_TABLESPACE=UNDO2; SQL>ALTER SYSTEM SET UNDO_MANAGEMENT=MANUAL SCOPE=spfile (so che l'ultimo parametro non può essere modificato a caldo, ma registra la modifica nell'spfile per la prossima partenza) Esempio di pfile: ifile = /oracle/admin/ora1/pfile/configora.ora background_dump_dest = /oracle/admin/ora1/bdump user_dump_dest = /oracle/admin/ora1/udump core_dump_dest = /oracle/admin/ora1/cdump instance_number = 1 instance_name = ORA thread = 1 undo_tablespace = undotbs1 job_queue_processes = 4 job_queue_interval = 10 open_links = 4

13 il file configora.ora a cui si fa riferimento ha il seguente contenuto: cluster_database = true control_files = (/metafora/oradata/ora/controlora1.ctl,/engi/o radata/ora/controlora2.ctl) compatible = db_block_size = db_cache_size = 120M db_file_multiblock_read_count = 16 db_files = 100 db_name = ORA enqueue_resources = 1024 java_pool_size = 8M log_buffer = open_cursors = 300 optimizer_mode = CHOOSE processes = 500 service_names = (ORA, ORA1, ORA2) shared_pool_size = 300M sort_area_retained_size = sort_area_size = undo_management = auto # rimuovere quando non ci saranno piu' "SET TRANSACTION" stmts in applicazioni undo_suppress_errors = true utl_file_dir = *

14 [7] Partenza e chiusura del database Gli stati del database sono i seguenti: OPEN MOUNT NOMOUNT SHUTDOWN in salita si possono percorrere tutti i gradini; in discesa si può fare solo shutdown. SQL>STARTUP NOMOUNT (parte solo l'istanza; posso in questo stato creare un database con CREATE DATABASE...; serve inoltre per il backup con RMAN) (si passa al livello successivo con ALTER DATABASE PIPPO MOUNT) SQL>STARTUP MOUNT (vengono aperti e letti i control files; serve per gestire i problemi di recovery) (si passa al livello successivo con ALTER DATABASE PIPPO OPEN oppure, per esempio, ALTER DATABASE PIPPO OPEN READ ONLY) SQL>STARTUP (si aprono tutti i files, eventualmente si fa un recovery se il db non è cosnistente). (oppure SQL>STARTUP RESTRICTED; solo il dba può lavorare; equivalente ad ALTER SYSTEM ENABLE RESTRICTED SESSION, che si può usare quando il db è già partito, avendo cura di far terminare le sessioni già terminate). La chiusura del database si effettua in questi modi: SQL>SHUTDOWN (normal) Oracle aspetta che tutti gli utenti finiscano le transazioni; non permette nuove connessioni, ma si aspetta un tempo lunghissimo. SQL>SHUTDOWN ABORT Oracle chiude il db chiudendo immediatamente tutti i processi; non fa eventuali rollback; non adrebbe mai fatto se non in casi di reale emergenza. SQL>SHUTDOWN IMMEDIATE Oracle chiude in subito in modo corretto; termina i processi attivi e fa il rollback delle transazioni non terminate; salva il db in uno stato consistente. E' la modalità da utilizzare. (sotto Windows vi sono le chiavi di registro: ORA_ORCL_SHUTDOWN='TRUE' ed ORA_ORCL_SHUTDOWNTYPE='I', per garantire questa modalità alla chiusura del servizio) SQL>SHUTDOWN TRANSACTIONAL E' analogo allo shutdown (normal); chiude subito le select, ma aspetta per le transazioni attive.

15 [8] Strumenti diagnostici Per vedere dove vengono mandati i messaggi di log, dare il comando: SQL>SHOW PARAMETER DUMP_DEST (il parametro da vedere è BACKGROUND_DUMP_DEST). Il file principale è: alert SID.log. Tiene la storia di tutto quello che è successo nel database; posso vedere le corruzioni fisiche, gli errori (cercare error oppure ORA- ); se non vi sono problemi si può cancellare tranquillamente. Poi vi sono i files di trace: sono sotto../admin/udump (user)../admin/cdump../admin/bdump (background processes) L'utility tkprof permette di formattare l'output dei files in modo comprensibile. E' possibile mettere sotto trace una sessione: SQL>ALTER SESSION SET SQL_TRACE=TRUE oppure SQL>DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION Si può dare il comando anche a livello di istanza, ma è sconsigliato: SQL_TRACE=TRUE

16 [9] Il dizionario dati Il dizionario dati descrive il database ed i suoi oggetti. Contiene tabelle readonly e viste. Sono memorizzate nella tablespace System, e possedute da Sys. Le viste sono di tre tipi: dba_xxx quello che c'è in tutti gli schemi all_xxx quello a cui un utente può accedere (grazie a dei privilegi) user_xxx quello che esiste nello schema dell'utente Viste interessanti: DICTIONARY, DICT_COLUMNS DBA_TABLES, DBA_INDEXES... DBA_SEGMENTS, DBA_EXTENTS... DBA_TABLESPACES, DBA_DATA_FILES... Oracle gestisce se stesso mediante i comandi DDL (data definition language) che sono essenzialmente: CREATE, ALTER, DROP, TRUNCATE, GRANT/REVOKE, ANALYZE. Tali comandi non hanno bisogno del commit, sono auto-committanti. Quindi non si torna indietro mediante rollback! Il comando analyze merita dei commenti. Il comando analyze serve per creare delle statistiche sull'utilizzo delle tabelle; in pratica si vanno a compilare dei campi (che contengono contatori) già esistenti, e che altrimenti rimarrebbero sempre vuoti. Se Oracle dispone di questi dati può ottimizzare i suoi piani di esecuzione. Esercizio; SQL> SELECT * FROM DBA_TABLES; (vedo le informazioni su tutte le tabelle) SQL> SELECT * FROM DBA_TABLES WHERE TABLE_NAME='ANTO'; (vedo i campi vuoti relativamente alla tabella anto) SQL> ANALYZE TABLE ANTO COMPUTE STATISTICS; (calcolo le statistiche su anto) SQL> ANALYZE TABLE ANTO ESTIMATE STATISTICS; (stimo le statistiche su anto; meglio il comando precedente) SQL> SELECT * FROM DBA_TABLES WHERE TABLE_NAME='ANTO';

17 (ora i campi statistici su anto sono compilati) Le viste di dizionario alcune viste sono le seguenti (ottenibili mediante i seguenti script): SQL> SELECT * FROM USER_TABLES; SQL> SELECT TABLE_NAME FROM USER_TABLES; SQL> SELECT TABLE_NAME FROM DBA_TABLES; (se ho i privilegi di select any dictionary) SQL> SELECT * FROM DBA_TABLES WHERE OWNER='PIPPO'; SQL> SELECT * FROM DBA_SEGMENTS; SQL> SELECT * FROM DBA_EXTENTS WHERE OWNER='PIPPO' AND SEGMENT_TYPE='TABLE'; SQL> SELECT * FROM DICTIONARY; Le V$* sono virtual tables (viste delle tabelle del dizionario), e sono create al runtime perchè riflettono l'attività corrente del database. Sono continuamente aggiornate durante l'attività del database. Sono usate per monitorizzare il database al runtime. Esempi di V$* sono: V$SGASTAT V$SESSION V$CONTROLFILE V$DATAFILE V$INSTANCE V$PARAMETER V$SGA V$TABLESPACE V$VERSION V$THREAD V$DATABASE V$SPPARAMETER

18 [10] Il control file Il control file è un piccolo file binario, che definisce lo stato corrente del database. Server a mantenere l'integrità del database. E' richiesto al mount del database durante lo startup del database; la perdita del control file richiede il recovery del database. Contiene: il nome del database il time stamp della creazione del database i nomi delle tablespaces nomi e localizzazioni dei data files e dei redo log files il numero di sequenza del redo log file corrente informazioni sui checkpoint inizio e fine dei segmenti di undo informazioni sugli archivi di redo log informazioni sui backup Si raccomanda fortemente che i control file siano più di uno e memorizzati su dischi diversi, per evitare problemi dovuti alla corruzione di uno di essi. Il control file va salvato subito dopo una modifica al database. Informazioni sul contro file si trovano in: v$controlfile v$parameter inoltre si può dare il comando SQL>SHOW PARAMETER CONTROL_FILE

19 [11] I redo log files I redo log files hanno le seguenti caratteristiche: registrano tutti i cambiamenti effettuati sui dati forniscono un meccanismo per il recovery dei dati possono essere organizzati in gruppi servono almeno due gruppi Quando un database sta lavorando, tutte le transazioni vengono scritte in modo sincrono anche nei buffers di redo log, i quali vengono poi scaricati nei files di redo log; Questo serve a creare un meccanismo per recuperare le transazioni, in caso del crash del database o di un media (a meno che vi sia una clausola di NOLOGGING abilitata, ad esempio caricando i dati con SqlLoader). Quindi i redo log files sono utilizzati per recuperare dati committati ma che non sono ancora stati scritti sui data files. Gli online redo log files sono usati solo per il recovery. I redo log sono organizzati in gruppi; ogni gruppo contiene files identici (copie ridondanti per sicurezza); i file identici vanno messi su dischi diversi. Il processo di LGWR (log writer) scrive le informazioni in contemporanea su tutte le copie di un gruppo. I gruppi devono essere almeno due. Gli on line redo log files sono usati in modo ciclico; quando un gruppo è pieno, il LGWR muove al prossimo gruppo, con una azione chiamata switch ; in questo caso avviene anche un checkpoint e l'informazione viene scritta sul control file. Si può forzare sia uno switch che un checkpoint: SQL>ALTER SYSTEM SWITCH LOGFILE; SQL>ALTER SYSTEM CHECKPOINT; Si possono aggiungere file ai log file: SQL>ALTER DATABASE PIPPO ADD LOGFILE GROUP 2 ('/usr/oracle/esempio/a.rdo') SIZE 2M; Se un gruppo di redo log non è attivo, si può cancellare: SQL> ALTER DATABASE DROP LOGFILE GROUP 3; Analogamente si può cancellare un file: SQL> ALTER DATABASE DROP LOGFILE MEMBER '/usr/oracle/esempio/a.rdo'; (se è attivo l'archivelog mode, bisogna che il file sia stato archiviato prima che vi sia la possibilità di cancellarlo). Può succedere che un redo log file si corrompa mentre il database stà funzionando; allora si può reinizializzare senza chiudere il database:

20 SQL>ALTER DATABASE CLEAR LOGFILE GROUP 2; Naturalmente in questo caso non si può più eseguire il recover del database dall'ultimo backup. Nota: guardando l'alert log, se il processo di LGWR deve attendere frequentemente un gruppo perchè il checkpoint non è avvenuto o il gruppo non è stato archiviato, allora bisogna aggiungere un gruppo. Dove trovare informazioni sui membri: V$LOG, V$LOGFILE Gli stati corrispondenti sono: UNUSED: mai usato CURRENT: attualmente in uso ACTIVE: attivo, ma non corrente; è necessario per il recovery, nel caso succeda un crash CLEARING: è nella fase di ricreazione CLEARING_CURRENT: nella fase di ricreazione, anomala INACTIVE: non in uso e non necessario per il recovery. Il database può essere attivo in ARCHIVELOG mode o NOARCHIVELOG; conviene attivare il modo ARCHIVELOG, così i redo log files vengono attivati in automatico dai processi di ARC. Per vedere se è attivo il processo di ARC: SQL> select archiver from v$instance; ARCHIVE STOPPED

21 [12] Le tablespace ed i data files I dati sono memorizzati fisicamente nei datafiles e logicamente nelle tablespace. La tablespace principale è quella di SYSTEM, creata assieme al database. Contiene il dizionario dei dati ed il segmento di UNDO di sistema. Altre tablespace possono essere create dall'amministratore. TEMP ed UNDO sono proposte di default all'atto della creazione di un database. SQL>CREATE TABLESPACE userdata DATAFILE '/usr/prova/dati_001.dbf' SIZE 10M; I parametri fondamentali sono: DATAFILE: specifica il file di dati; LOGGING (è il default): significa che i cambiamenti di tabelle, indici e partizioni sono scritti entro i redo log files); OFFLINE: tablespace fuori linea; PERMANENT: la tablespace può essere utilizzata per contenere oggetti permanenti; TEMPORARY: la talblespace può essere usata solo per oggetti temporanei, come ad esempio per contere le tabelle temporanee usate da ORDER BY etc. EXTENT MANAGEMENT LOCAL (default per la 9i): gestione automatica e locale degli extents; è contrario di DICTIONARY MANAGED TABLESPACE; Vantaggio: evita operazioni ricorsive di management, si riduce la contesa sulle tabelle di dizionario dati, si libera automaticamente lo spazio libero adiacente non essendo più necessaria l'azione di Coalesce, non si generano informazioni di UNDO relativamente all'aggiornamento delle tabelle di dizionario; NEXT: prossimo incremento della tab. su disco, se richiesto; MAXSIZE: massimo spazio su disco consentito per estensione automatica di un datafile; Dare sempre un massimo, mai mettere UNLIMITED. Nota: non migrare la System da DICTIONARY A LOCAL: è PERICOLOSO; UNDO TABLESPACE: usate per memorizzare le vecchie informazioni TEMPORARY TABLESPACE: usate per memorizzare risultati di ORDER BY, GROUP BY, DISTINCT, UNION, INTERSECT... E' IMPORTATE CREARE LA DEFAULT TEMPORARY TABLESPACE, ALTRIMENTI IL DATABASE USA LA TABLESPACE SYSTEM PER MEMORIZZARE I DATI TEMPORANEI!!! La tabella temporanea viene svuotata solo allo shutdown; altrimenti bisogna aggiungere una tablespace vuota, metterla come tablespace di default, cancellare la vecchia. Per vedere informazioni sulle tablespace temporanee: SQL> SELECT * FROM DATABASE_PROPERTIES;