Concetti per gli amministratori del database

I componenti script in questa pagina sono utilizzati solo per scopi di navigazione e non alterano in alcun modo il contenuto.

Questa parte descrive le responsabilità, gli strumenti e le conoscenze essenziali per gli amministratori del database.

Funzioni degli amministratori di database

La responsabilità principale di un amministratore di database (DBA) è quella di rendere i dati aziendali disponibili ai propri utenti.

I DBA devono lavorare a stretto contatto con gli sviluppatori per garantire che le loro applicazioni utilizzino in modo efficiente il database e con gli amministratori di sistema per garantire che le risorse fisiche siano adeguate e utilizzate in modo efficiente.

Gli Oracle DBA sono responsabili della comprensione dell'architettura di Oracle AI Database e del funzionamento del database. I DBA possono prevedere di eseguire i task riportati di seguito:

I tipi di utenti e i relativi ruoli e responsabilità dipendono dall'ambiente del database. Un database di piccole dimensioni può avere un DBA. Un database di grandi dimensioni può dividere i compiti del DBA tra diversi specialisti, ad esempio funzionari della sicurezza, operatori di backup e amministratori delle applicazioni.

Vedere anche:

Strumenti per amministratori di database

Oracle fornisce diversi strumenti da utilizzare per amministrare un database.

Questa sezione descrive alcuni strumenti di uso comune.

Oracle Enterprise Manager

Oracle Enterprise Manager (Enterprise Manager) è uno strumento di gestione di sistemi basato sul Web che fornisce la gestione di database Oracle, database machine Exadata, Fusion Middleware, applicazioni, server, storage e hardware e software Oracle non-Oracle.

Oracle Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control (Cloud Control) è un'interfaccia basata sul Web che fornisce all'amministratore un monitoraggio completo dello stack tecnologico Oracle e dei componenti non Oracle.

A volte un componente della notifica FAN (Fast Application Notification) può diventare non disponibile o si verifica un problema a livello di prestazioni. In questo caso, Cloud Control visualizza l'avviso generato automaticamente in modo che l'amministratore possa eseguire l'azione di recupero appropriata.

Di seguito sono elencati i componenti di Cloud Control.

Vedere anche:

Oracle Enterprise Manager Database Express: 12c

Oracle Enterprise Manager Database Express (EM Express) è un prodotto di gestione Web integrato nel database Oracle. Non richiede alcuna installazione o gestione speciale.

EM Express contiene le pagine di gestione delle prestazioni chiave e amministrazione di base in Cloud Control. Queste pagine includono quanto riportato di seguito.

È possibile accedere a queste funzioni online tramite la console EM Express e offline tramite la tecnologia Active Reports. Dal punto di vista architettonico, EM Express non ha componenti di livello intermedio o middleware, garantendo che il suo sovraccarico sul database server sia trascurabile.

EM Express consente di eseguire task amministrativi quali la gestione della sicurezza degli utenti e la gestione della memoria e dello storage del database. È inoltre possibile visualizzare le informazioni relative alle prestazioni e allo stato del database.

Vedere anche: Introduzione a Oracle AI Database con il tuning delle prestazioni per scoprire come amministrare il database con EM Express

SQL*Plus

SQL*Plus è uno strumento di query interattivo e batch incluso in ogni installazione di Oracle AI Database.

Ha un'interfaccia utente della riga di comando che funge da client durante la connessione al database. SQL*Plus dispone di un ambiente e di comandi propri. Consente di immettere ed eseguire comandi SQL, PL/SQL, SQL*Plus e del sistema operativo per eseguire task quali:

È possibile utilizzare SQL*Plus per generare i report in modo interattivo, generare i report come processi batch ed eseguire l'output dei risultati in file di testo, sullo schermo o in un file HTML per l'esplorazione su Internet. È possibile generare i report in modo dinamico utilizzando la funzione per l'output HTML.

Vedere anche: SQL*Plus User's Guide and Reference per ulteriori informazioni su SQL*Plus

Strumenti per l'installazione e la configurazione del database

Oracle fornisce diversi strumenti per semplificare il task di installazione e configurazione del software Oracle AI Database.

Nella tabella seguente vengono descritti gli strumenti supportati.

Tabella 1 Strumenti per l'installazione e la configurazione del database

Strumento Descrizione Per saperne di più
Oracle Universal Installer (OUI) OUI è una utility GUI che consente di visualizzare, installare e disinstallare il software Oracle AI Database. Guida in linea disponibile per guidare l'utente durante l'installazione. Guida in linea per guidarti attraverso l'installazione
Assistenza all'aggiornamento del database (DBUA) DBUA guida in modo interattivo l'utente attraverso un aggiornamento del database e configura il database per la nuova release. DBUA automatizza l'upgrade eseguendo tutti i task normalmente eseguiti manualmente. DBUA fornisce suggerimenti per le opzioni di configurazione, ad esempio le tablespace e il redo log in linea. Oracle AI Database 2 Day DBA per scoprire come aggiornare un database con DBUA
DBCA (Database Configuration Assistant) DBCA offre un'interfaccia grafica e il workflow guidato per la creazione e la configurazione di un database. Questo strumento consente di creare un database da modelli forniti da Oracle o di creare database e modelli personalizzati. Oracle AI Database Administrator's Guide per informazioni su come creare un database con DBCA

Strumenti di configurazione e amministrazione di Oracle Net

Oracle Net Services fornisce soluzioni per la connettività a livello aziendale in ambienti informatizzati eterogenei e distribuiti. Oracle Net, un componente di Oracle Net Services, consente di effettuare una sessione della rete da un'applicazione client a una base di dati.

È possibile utilizzare gli strumenti indicati di seguito per configurare e amministrare Oracle Net Services.

Vedere anche:

Strumenti per lo spostamento e l'analisi dei dati

Oracle AI Database include diverse utility che forniscono assistenza nello spostamento e nell'analisi dei dati.

Ad esempio, è possibile utilizzare le utility del database per:

Tabella 2 - Spostamento dei dati e task di analisi

Task Per saperne di più
Caricare i dati nelle tabelle di Oracle AI Database dai file del sistema operativo "SQL*Loader"
Spostare dati e metadati da un database a un altro "Esportazione e importazione di Oracle Data Pump"
Eseguire una query sui redo log file tramite un'interfaccia SQL "Oracle LogMiner"
Gestire i dati di Oracle AI Database "ADR Command Interpreter (ADRCI)"

Altri task includono l'esecuzione di controlli di integrità della struttura di dati fisica su un database o un file di dati non in linea con DBVERIFY o la modifica dell'identificativo del database (DBID) o del nome del database per un database operativo utilizzando la utility DBNEWID.

Nota:

Vedere anche:

SQL*Loader:

SQL*Loader carica i dati da file esterni, denominati file di dati (da non confondere con i file di dati di database interni), nelle tabelle di database. Dispone di un potente motore per l'analisi dei dati che pone pochi limiti al formato dei dati nel file.

È possibile utilizzare SQL*Loader per effettuare le operazioni riportate di seguito.

Una sessione SQL*Loader tipica richiede come input un file di controllo SQL*Loader e uno o più file di dati. L'output è un database Oracle, un file di log, un file errato e, potenzialmente, un file eliminato. La figura seguente illustra il flusso di una sessione SQL*Loader tipica.

Figura 1: Sessione SQL*Loader

Descrizione dell'illustrazione cncpt271.gif

È inoltre possibile utilizzare la modalità Express di SQL*Loader, che viene attivata quando si specifica il parametro table nel comando SQL*Loader, come nell'esempio riportato di seguito.

% sqlldr hr table=employees

Non è consentito alcun control file, il che rende SQL*Loader più facile da usare. Anziché analizzare un control file, SQL*Loader utilizza le definizioni delle colonne della tabella per determinare i tipi di dati di input. SQL*Loader effettua diverse ipotesi predefinite, tra cui il set di caratteri, i delimitatori di campo e i nomi dei dati, dei log e dei file errati. È possibile sostituire molte delle impostazioni predefinite con parametri della riga di comando.

Vedere anche:

Esportazione e importazione di Oracle Data Pump

Oracle Data Pump consente lo spostamento ad alta velocità di dati e metadati da un database all'altro.

Questa tecnologia è la base per le seguenti utility di spostamento dei dati di Oracle AI Database:

Oracle Data Pump è composto dalle seguenti parti distinte:

La figura seguente mostra come Oracle Data Pump si integra con SQL*Loader e tabelle esterne. Come mostrato, SQL*Loader è integrato con l'API tabella esterna e l'API Data Pump per caricare i dati in tabelle esterne. I client, ad esempio Oracle Enterprise Manager Cloud Control (Cloud Control) e le tablespace trasportabili, possono utilizzare l'infrastruttura Oracle Data Pump.

Figura 2: Architettura di Oracle Data Pump

Descrizione dell'illustrazione cncpt261.png

Vedere anche:

Oracle LogMiner

Oracle LogMiner consente di eseguire query sui redo log file tramite un'interfaccia SQL.

I potenziali usi dei dati contenuti nei redo log file includono:

LogMiner è accessibile tramite un'interfaccia a riga di comando o tramite la GUI di Oracle LogMiner Viewer, che fa parte di Enterprise Manager.

Vedi anche: Oracle AI Database Utilities per saperne di più su LogMiner

Interprete comando ADR (ADRCI)

ADRCI è una utility della riga di comando che consente di analizzare i problemi, visualizzare i report sul controllo dell'integrità e caricare i dati relativi ai primi errori nel supporto Oracle.

È inoltre possibile utilizzare la utility per visualizzare i nomi dei file di trace in Automatic Diagnostic Repository (ADR) e per visualizzare il log degli avvisi. ADRCI dispone di un ricco set di comandi che è possibile utilizzare in modo interattivo o in script.

Vedere anche:

Argomenti per gli amministratori del database

Questa sezione tratta gli argomenti più essenziali per i DBA e che non sono stati discussi altrove nel manuale.

Backup e recupero

Backup e ripristino è l'insieme di concetti, procedure e strategie coinvolte nella protezione del database dalla perdita di dati causata da errori dei media o degli utenti.

Un backup è una copia di dati. Un backup può includere parti cruciali del database, ad esempio file di dati, file dei parametri del server e control file. Uno scenario di backup e ripristino di esempio è un'unità disco con errori che causa la perdita di un file di dati. Se esiste un backup del file perso, è possibile ripristinarlo e recuperarlo. Le operazioni necessarie per ripristinare i dati allo stato precedente alla perdita sono denominate media recovery.

Questa sezione contiene gli argomenti riportati di seguito.

Vedere anche:

Tecniche di backup e recupero

Puoi utilizzare Recovery Manager o tecniche gestite dall'utente per eseguire il backup, il ripristino e il recupero di un database Oracle.

Le principali differenze tra i due approcci sono le seguenti:

Vedere anche:

Architettura di Recovery Manager

RMAN e Oracle Secure Backup sono accessibili sia dalla riga di comando che da Enterprise Manager Cloud Control (Cloud Control).

Cloud Control fornisce un front-end grafico e una funzionalità di pianificazione per RMAN. Inserire i parametri del processo, quindi specificare una schedulazione del processo. Cloud Control esegue RMAN all'ora specificata o all'intervallo di ripetizione designato per eseguire le operazioni di backup e ripristino. Cloud Control fornisce l'accesso a RMAN tramite un set di procedure guidate. Queste procedure guidate ti guidano attraverso una varietà di procedure di recupero basate su un'analisi del tuo database, dei tuoi backup disponibili e dei tuoi obiettivi di recupero dati.

Utilizzando Cloud Control, puoi eseguire gli scenari di ripristino e ripristino più semplici descritti in questa documentazione. Puoi anche utilizzare tecniche di ripristino e ripristino più sofisticate, come il ripristino point-in-time e le operazioni Oracle Flashback, che consentono una riparazione efficiente dei guasti dei supporti e degli errori degli utenti. L'uso di Cloud Control è spesso più semplice rispetto al client della riga di comando RMAN.

Il grafico seguente mostra un esempio di architettura RMAN. Il client RMAN, accessibile mediante Cloud Control, utilizza sessioni server in un database di destinazione per eseguire il backup dei dati su disco o nastro. RMAN può aggiornare un Recovery Catalog esterno con metadati di backup.

Figura 3: Architettura RMAN

Descrizione dell'illustrazione cncpt318.gif

Indipendentemente dalla tecnica di backup e ripristino utilizzata, Oracle consiglia di configurare un'area di recupero rapido. Questa directory, file system o gruppo di dischi Oracle ASM gestita dal database centralizza i file di backup e ripristino, inclusi i control file attivi, i redo log file in linea e archiviati e i backup. I componenti di ripristino di Oracle AI Database interagiscono con l'area di recupero rapido per garantire la recuperabilità del database.

Vedere anche:

Backup del database

I backup del database possono essere fisici o logici.

I backup fisici, che sono la preoccupazione principale in una strategia di backup e ripristino, sono copie di file di database fisici. È possibile eseguire backup fisici con le utility RMAN o del sistema operativo.

Al contrario, i backup logici contengono tabelle, stored procedure e altri dati logici. È possibile estrarre dati logici con una utility di Oracle AI Database, ad esempio Esportazione Data Pump, e memorizzarli in un file binario. I backup logici possono integrare i backup fisici.

I backup fisici hanno una grande granularità e una trasportabilità limitata, ma sono molto veloci. I backup logici hanno una granularità fine e una trasportabilità completa, ma sono più lenti dei backup fisici.

Backup di database interi e parziali

Un backup completo del database è un backup di ogni file di dati nel database, oltre al control file. I backup dell'intero database sono i tipi di backup più comuni.

Un backup parziale del database include un sottoinsieme del database: singole tablespace o file di dati. Il backup di una tablespace è un backup di tutti i file di dati in una tablespace o in più tablespace. I backup delle tablespace, coerenti o incoerenti, sono validi solo se il database funziona in modalità ARCHIVELOG perché è necessario un redo per rendere la tablespace ripristinata coerente con il resto del database.

Backup coerenti e non coerenti

Un backup dell'intero database è coerente o incoerente.

In un backup coerente, tutti i file di dati di lettura/scrittura e i control file hanno lo stesso SCN checkpoint, garantendo che questi file contengano tutte le modifiche fino a questo SCN. Questo tipo di backup non richiede il ripristino dopo il ripristino.

Un backup coerente del database è possibile solo dopo una chiusura coerente ed è l'unica opzione di backup valida per un database che opera in modalità NOARCHIVELOG. Altre opzioni di backup richiedono il recupero dei supporti per garantire la coerenza, il che non è possibile senza applicare i redo log file archiviati. Nota: se si ripristina un backup coerente dell'intero database senza applicare redo, tutte le transazioni effettuate dopo il backup andranno perdute.

In un backup incoerente, non è garantito che i file di dati di lettura/scrittura e i control file abbiano lo stesso SCN del checkpoint, pertanto è possibile che manchino modifiche. Tutti i backup in linea sono necessariamente incoerenti perché i file di dati possono essere modificati durante l'esecuzione dei backup.

I backup incoerenti offrono una disponibilità superiore perché non è necessario arrestare il database per eseguire backup che proteggono completamente il database. Se il database viene eseguito in modalità ARCHIVELOG e se si esegue il backup dei redo log e dei file di dati archiviati, i backup incoerenti possono essere alla base di una strategia di backup e ripristino efficace.

Vedere anche:

Backup set e copie immagine

Il comando RMAN BACKUP genera copie di immagine o backup set.

I tipi di backup sono diversi come indicato di seguito.

Vedere anche: Oracle AI Database Backup and Recovery User's Guide per ulteriori informazioni sui backup set e le copie di immagini

Riparazione dati

Sebbene diversi problemi possano arrestare il normale funzionamento di un database o influire sulle operazioni di I/O, solo alcuni problemi richiedono l'intervento del DBA e la riparazione dei dati.

La riparazione dei dati è in genere necessaria nei seguenti casi:

In genere, sono disponibili diversi modi per risolvere i problemi precedenti. Questa sezione riassume alcune di queste soluzioni.

Vedere anche:

Tecnologia Oracle Flashback

Oracle AI Database fornisce un gruppo di funzioni note come Oracle Flashback Technology che supportano la visualizzazione degli stati passati dei dati e l'avvolgimento dei dati avanti e indietro nel tempo, senza dover ripristinare i backup.

A seconda delle modifiche al database, le funzionalità di flashback possono spesso invertire le modifiche indesiderate più rapidamente e con meno impatto sulla disponibilità rispetto al recupero dei supporti. Le seguenti funzionalità di flashback sono più rilevanti per il backup e il ripristino:

Vedere anche:

Recupero dei supporti a blocchi

Block media recovery è una tecnica per il ripristino e il recupero di blocchi di dati danneggiati mentre i file di dati sono online.

Un danneggiamento dei blocchi è un blocco di dati non in un formato Oracle riconosciuto o il cui contenuto non è coerente internamente. Se rilevi danneggiamenti dei blocchi e se solo pochi blocchi sono danneggiati, il recupero dei blocchi potrebbe essere preferibile al recupero dei file di dati.

Vedere anche:

Recupero file di dati

Il recupero dei file di dati ripara un file di dati o un file di controllo corrente perso o danneggiato. Può anche recuperare le modifiche perse quando una tablespace è diventata offline senza l'opzione OFFLINE NORMAL.

Il recupero dei supporti è necessario se si ripristina un backup di un file di dati o di controllo o se un file di dati viene messo offline senza l'opzione OFFLINE NORMAL. Il database non può essere aperto se i file di dati online richiedono il recupero dei supporti, né un file di dati che richiede il recupero dei supporti può essere portato online fino al completamento del recupero dei supporti.

Per ripristinare un backup fisico di un file di dati o di controllo, è necessario ricostruirlo e renderlo disponibile per Oracle AI Database. Per recuperare un backup è necessario applicare i redo log file archiviati per ricostruire le modifiche perse. RMAN può anche recuperare i file di dati con backup incrementali, che contengono solo blocchi di dati modificati dopo un backup precedente.

A differenza del ripristino dell'istanza, che applica automaticamente le modifiche ai file in linea, il recupero dei supporti deve essere richiamato da un utente e applica i redo log file archiviati ai backup ripristinati. Il recupero dei supporti dei file di dati può funzionare solo su file di dati o file di dati offline in un database non aperto da alcuna istanza di database.

Il recupero dei supporti dei file di dati varia a seconda che vengano applicate tutte le modifiche:

Vedere anche:

Zero Data Loss Recovery Appliance

Zero Data Loss Recovery Appliance su scala cloud, comunemente noto come Recovery Appliance, è un sistema di engineering che riduce drasticamente la perdita di dati e il sovraccarico di backup per tutti i database Oracle nell'azienda.

Integrato con RMAN, Recovery Appliance implementa una strategia di backup e ripristino centralizzata per un numero elevato di database, utilizzando hardware e storage su scala cloud e con tolleranza agli errori. Recovery Appliance convalida continuamente i backup per la recuperabilità.

Vantaggi di Recovery Appliance

Una Recovery Appliance centralizzata esegue la maggior parte dell'elaborazione di backup e ripristino del database, rendendo più efficiente l'utilizzo dello storage, le prestazioni e la gestibilità dei backup.

I vantaggi principali sono i seguenti:

Ambiente Recovery Appliance

Un database protetto è un database client che esegue il backup dei dati in una Recovery Appliance.

La figura seguente mostra un ambiente di esempio, che include sei database protetti e due Recovery Appliance. Ogni database utilizza il modulo di backup Zero Data Loss Recovery Appliance (Recovery Appliance Backup Module) per i propri backup. Questo modulo è una libreria SBT fornita da Oracle che RMAN utilizza per trasferire i backup sulla rete a Recovery Appliance.

Figura 4: Ambiente Recovery Appliance

Descrizione dell'immagine amagd_vm_025.png

Il database di metadati Recovery Appliance, che risiede su ogni Recovery Appliance, gestisce i metadati memorizzati nel Recovery Catalog. Tutti i database protetti che inviano backup a Recovery Appliance devono utilizzare questo Recovery Catalog. I backup si trovano nella posizione di storage di Recovery Appliance, che è un set di gruppi di dischi Oracle ASM. Nota: i database possono utilizzare Recovery Appliance come Recovery Catalog senza utilizzarlo anche come repository di backup.

Gli amministratori utilizzano Cloud Control per gestire e monitorare l'ambiente. Cloud Control offre una vista "singola panoramica" dell'intero ciclo di vita del backup per ogni database, indipendentemente dal fatto che i backup risiedano su disco, su nastro o su un'altra Recovery Appliance.

Gestione memoria

La gestione della memoria prevede la conservazione delle dimensioni ottimali per la struttura di memoria dell'istanza Oracle al variare delle richieste nel database. Le impostazioni dei parametri di inizializzazione determinano la modalità di gestione della memoria PGA SGA e dell'istanza. La Figura 22-5 mostra una struttura decisionale per le opzioni di gestione della memoria. Le sezioni seguenti illustrano le opzioni in dettaglio.

Figura 5: Metodi di gestione della memoria

Descrizione dell'illustrazione cncpt242.gif

Gestione automatica della memoria

Nella gestione automatica della memoria, Oracle AI Database gestisce la memoria SGA e PGA dell'istanza in modo completamente automatico. Questo metodo è il più semplice ed è fortemente consigliato da Oracle.

Gli unici controlli specificati dall'utente sono il parametro di inizializzazione della dimensione della memoria di destinazione (MEMORY_TARGET) e il parametro opzionale di inizializzazione della dimensione massima della memoria (MEMORY_MAX_TARGET). Oracle AI Database esegue il tuning in base alla dimensione della memoria di destinazione, ridistribuendo la memoria in base alle esigenze tra SGA e PGA dell'istanza.

L'area SGA può contenere l'area di memorizzazione colonne in memoria (area di memorizzazione colonne IM) o il pool di memoria, entrambi facoltativi. Indipendentemente dal metodo di gestione della memoria utilizzato, ridimensionare l'area di memorizzazione delle colonne IM con il parametro di inizializzazione INMEMORY_SIZE e il pool memoptimize con il parametro di inizializzazione MEMOPTIMIZE_POOL_SIZE. Le dimensioni dell'area di memorizzazione delle colonne IM sono pool memoptimize inclusi nella destinazione di memoria, ma non gestiti dall'algoritmo di ridimensionamento automatico. Ad esempio, se si imposta MEMORY_TARGET su 5 GB e INMEMORY_SIZE su 1 GB, la destinazione di memoria complessiva è 5 GB (non 6 GB) e INMEMORY_SIZE è sempre 1 GB.

L'immagine riportata di seguito mostra un database che a volte elabora processi sottomessi da utenti in linea e talvolta processi batch. Utilizzando la gestione automatica della memoria, il database regola automaticamente le dimensioni del pool grande e della buffer cache del database a seconda del tipo di job in esecuzione. Si noti che il grafico non rappresenta l'area di memorizzazione delle colonne IM o l'area memoptimize.

Figura 6: Gestione automatica della memoria

Descrizione dell'illustrazione cncpt256.gif

Se si crea un database con DBCA e si sceglie l'opzione di installazione di base, Oracle AI Database abilita la gestione automatica della memoria per impostazione predefinita.

Vedere anche:

Gestione della memoria condivisa della SGA

È possibile controllare le dimensioni della SGA manualmente, impostando la dimensione SGA con la gestione automatica della memoria condivisa o ottimizzando manualmente i componenti SGA.

Se la gestione automatica della memoria non è abilitata, il sistema deve utilizzare la gestione della memoria condivisa dell'area SGA. La gestione della memoria condivisa è possibile in una delle seguenti forme:

Vedere anche:

Gestione della memoria del PGA dell'istanza

Se la gestione automatica della memoria non è abilitata, Oracle AI Database utilizza la gestione automatica o manuale della memoria PGA.

Per la gestione della memoria PGA sono possibili le seguenti modalità:

Vedere anche: Oracle AI Database Performance Tuning Guide per ulteriori informazioni sulla gestione della memoria PGA

Riepilogo dei metodi di gestione della memoria

La gestione della memoria è automatica o manuale.

Se non si abilita la gestione automatica della memoria, è necessario configurare separatamente un metodo di gestione della memoria per la SGA e uno per la PGA. Nota: quando la gestione automatica della memoria è disabilitata per l'intera istanza di database, Oracle Database abilita la gestione automatica della memoria PGA per impostazione predefinita.

La tabella seguente include il parametro di inizializzazione INMEMORY_SIZE e il parametro di inizializzazione MEMOPTIMIZE_POOL_SIZE. Entrambe le aree di memoria di controllo sono facoltative.

Tabella 3 Metodi di gestione della memoria

Istanza SGA PGA Descrizione Parametri di inizializzazione
Automatico n/d n/d Il database ottimizza le dimensioni dell'istanza in base a una dimensione di destinazione a istanza singola.

L'utente ha impostato:

  • Dimensione totale della destinazione di memoria per l'istanza di database (MEMORY_TARGET)

  • Dimensione massima di memoria facoltativa per l'istanza di database (MEMORY_MAX_TARGET)

  • Dimensione facoltativa per l'area di memorizzazione colonne IM (INMEMORY_SIZE) nell'area di memorizzazione SGA

n/d Automatico Automatico

Il database ottimizza automaticamente l'SGA in base a una destinazione SGA.

Il database ottimizza automaticamente la PGA in base a una destinazione PGA.

L'utente ha impostato:

  • Dimensione di destinazione SGA (SGA_TARGET)

  • Dimensione massima SGA facoltativa (SGA_MAX_SIZE)

  • Dimensione facoltativa per l'area di memorizzazione colonne IM (INMEMORY_SIZE) nell'area di memorizzazione SGA

  • Dimensione facoltativa per il pool memoptimize nell'area SGA (MEMOPTIMIZE_POOL_SIZE)

  • Dimensione destinazione aggregata PGA (PGA_AGGREGATE_TARGET)Piede 1

Il database configura automaticamente il parametro di inizializzazione PGA_AGGREGATE_LIMIT. È possibile impostare questo parametro manualmente.

n/d Automatico Manuale

Il database ottimizza automaticamente l'SGA in base a una destinazione SGA.

È possibile controllare manualmente la PGA, impostando la dimensione massima dell'area di lavoro per ogni tipo di operatore SQL.

L'utente ha impostato:

  • Dimensione di destinazione SGA (SGA_TARGET)

  • Dimensione massima SGA facoltativa (SGA_MAX_SIZE)

  • Dimensione facoltativa per l'area di memorizzazione colonne IM nell'area di memorizzazione SGA (INMEMORY_SIZE)

  • Dimensione facoltativa per il pool di ottimizzazione memoria nell'area SGA (MEMOPTIMIZE_POOL_SIZE)

  • Parametri dell'area di lavoro PGA quali SORT_AREA_SIZE, HASH_AREA_SIZE e BITMAP_MERGE_AREA_SIZE
n/d Manuale Automatico

È possibile controllare la SGA manualmente impostando le dimensioni dei singoli componenti.

Il database ottimizza automaticamente la PGA in base a una destinazione PGA.

L'utente ha impostato:

  • Dimensione dello sharedpool (SHARED_POOL_SIZE)

  • Dimensione della buffer cache (DB_CACHE_SIZE)

  • Dimensione pool grande (LARGE_POOL_SIZE)

  • Dimensione pool Java (JAVA_POOL_SIZE)

  • Dimensione facoltativa per l'area di memorizzazione colonne IM (INMEMORY_SIZE) nell'area di memorizzazione SGA

  • Dimensione facoltativa per il pool di ottimizzazione memoria nell'area SGA (MEMOPTIMIZE_POOL_SIZE)

  • Dimensione target aggregata PGA (PGA_AGGREGATE_TARGET)Foot 2

Il database configura automaticamente il parametro di inizializzazione PGA_AGGREGATE_LIMIT. È possibile impostare questo parametro manualmente.

n/d Manuale Manuale

È necessario configurare manualmente le dimensioni dei componenti SGA.

È possibile controllare manualmente il PGA, impostando la dimensione massima dell'area di lavoro per ogni tipo di operatore SQL.

È necessario configurare manualmente le dimensioni dei componenti SGA. L'utente ha impostato:

  • Dimensione shared pool (SHARED_POOL_SIZE)

  • Dimensione della buffer Cache (DB_CACHE_SIZE)

  • Dimensione grande pool (LARGE_POOL_SIZE)

  • Dimensione pool Java (JAVA_POOL_SIZE)

  • Dimensione facoltativa per l'area di memorizzazione colonne IM (INMEMORY_SIZE) nell'area di memorizzazione SGA

  • Dimensione facoltativa per il pool memoptimize nell'area SGA (MEMOPTIMIZE_POOL_SIZE)

  • Parametri dell'area di lavoro PGA quali SORT_AREA_SIZE, HASH_AREA_SIZE e BITMAP_MERGE_AREA_SIZE

Nota a piè di pagina 1

Il database configura automaticamente il parametro di inizializzazione PGA_AGGREGATE_LIMIT. Si sceglie inoltre di impostare questo parametro manualmente.

Nota a piè di pagina 2

Il database configura automaticamente il parametro di inizializzazione PGA_AGGREGATE_LIMIT. Si sceglie inoltre di impostare questo parametro manualmente.

Vedere anche: Oracle AI Database Administrator's Guide perché la gestione automatica della memoria non è disponibile su tutte le piattaforme

Pianificazione di Resource Management e task

Oracle AI Database fornisce strumenti per assisterti nella gestione delle risorse e nella pianificazione delle attività per ridurre l'impatto sugli utenti.

In un database con molti utenti attivi, la gestione delle risorse è una parte importante dell'amministrazione del database. Le sessioni che consumano risorse eccessive possono impedire ad altre sessioni di svolgere il proprio lavoro. Un problema correlato è come pianificare i task in modo che vengano eseguiti al momento migliore. Oracle AI Database fornisce strumenti che aiutano a risolvere questi problemi.

Gestione risorse di database

Oracle AI Database Resource Manager (Resource Manager) fornisce un controllo granulare delle risorse del database allocate agli account utente, alle applicazioni e ai servizi. Resource Manager agisce principalmente come gatekeeper, rallentando l'esecuzione di alcuni job in modo che altri possano essere eseguiti rapidamente.

Il pacchetto PL/SQL DBMS_RESOURCE_MANAGER risolve molti problemi di allocazione delle risorse che un sistema operativo non gestisce bene, tra cui:

Resource Manager aiuta a superare i problemi precedenti offrendo al database un maggiore controllo sull'allocazione delle risorse hardware e sulla definizione delle priorità del lavoro all'interno del database. È possibile classificare le sessioni in gruppi in base agli attributi delle sessioni, quindi allocare le risorse a questi gruppi per ottimizzare l'utilizzo dell'hardware. È possibile utilizzare Resource Manager per impostare i limiti per il consumo di memoria del PDB.

Le risorse vengono allocate agli utenti in base a un piano risorse specificato dall'amministratore del database. Il piano specifica la modalità di distribuzione delle risorse tra i gruppi di consumer di risorse, ovvero le sessioni utente raggruppate in base ai requisiti delle risorse. Una direttiva del piano risorse associa un gruppo di consumer di risorse a un piano e specifica la modalità di allocazione delle risorse al gruppo. La Figura 22-7 mostra un semplice piano delle risorse per un'organizzazione che esegue applicazioni OLTP e applicazioni di reporting contemporaneamente durante il giorno. Il piano attualmente attivo, DAYTIME, alloca le risorse CPU tra tre gruppi di consumer di risorse. In particolare, a OLTP viene assegnato il 75% del tempo CPU, a REPORTS viene assegnato il 15% e a OTHER_GROUPS viene assegnato il restante 10%.

Figura 7: Piano risorse semplice

Descrizione dell'illustrazione admin078.gif

Un problema che Resource Manager può risolvere sono le query eseguibili, che possono essere monitorate utilizzando SQL Monitor. Resource Manager consente di specificare le soglie per identificare e rispondere alle istruzioni SQL eseguibili. Ad esempio, è possibile specificare le soglie per il tempo CPU, il tempo trascorso, gli I/O fisici o logici e l'uso PGA in base a ciascun processo in primo piano in un gruppo di consumer. In risposta, Resource Manager può passare a un gruppo di consumer con priorità inferiore, terminare l'istruzione SQL o registrare la violazione della soglia.

Vedere anche:

Gestione CPU

A partire da Oracle AI Database 26ai, Oracle offre un metodo alternativo per la gestione delle risorse CPU, che opera in tutte le istanze di database sul server.

Nelle release precedenti, Oracle offriva un metodo di gestione delle risorse della CPU, che operava all'interno di un'istanza di database. A partire da Oracle AI Database 26ai, è possibile impostare RESOURCE_MANAGER_CPU_SCOPE per controllare l'ambito della gestione delle risorse CPU. Questo parametro consente di scegliere tra i due metodi di controllo.

L'impostazione di RESOURCE_MANAGER_CPU_SCOPE su SERVER_WIDE consente di gestire le risorse CPU tra istanze a livello di server. Introdotto in Oracle AI Database 26ai, questo metodo può essere utilizzato quando più istanze di database condividono un server Linux. Consente la gestione delle risorse CPU in tutte le istanze di database sul server. Con questo metodo, Oracle configura automaticamente i gruppi di controllo (cgroup) Linux con i limiti di condivisione della CPU e di utilizzo della CPU desiderati, quindi inserisce le sessioni di database nei cgroup appropriati.

RESOURCE_MANAGER_CPU_SCOPE è impostato su INSTANCE_ONLY per impostazione predefinita.

Vedere anche:

Oracle Scheduler

Oracle Scheduler (lo scheduler) consente agli amministratori del database e agli sviluppatori di applicazioni di controllare quando e dove vengono eseguiti vari task nell'ambiente di database.

Scheduler fornisce funzionalità di pianificazione aziendale complesse che è possibile utilizzare per:

Gli oggetti programma (programmi) contengono metadati sul comando che verrà eseguito dallo scheduler, inclusi i valori predefiniti per qualsiasi argomento. Gli oggetti di pianificazione (schedulazioni) contengono informazioni sulla data e l'ora di esecuzione e sui pattern di ricorrenza. Gli oggetti job associano un programma a una pianificazione. Per definire cosa viene eseguito e quando, si assegnano relazioni tra programmi, schedulazioni e job.

Lo scheduler viene implementato come un insieme di funzioni e procedure nel package PL/SQL DBMS_SCHEDULER. È possibile creare e modificare gli oggetti Scheduler con questo package o con Enterprise Manager. Poiché gli oggetti Scheduler sono oggetti di database standard, è possibile controllarne l'accesso con privilegi di sistema e di oggetto. La Figura 22-8 mostra l'architettura di base dello scheduler. La tabella dei job è un contenitore per tutti i job, con una tabella per database. Il processo in background del coordinatore job viene avviato e interrotto automaticamente in base alle esigenze. I processi figlio del job vengono risvegliati dal coordinatore quando è necessario eseguire un job. I processi figlio raccolgono i metadati dalla tabella dei job ed eseguono il job.

Figura 8: Componenti dello scheduler

Descrizione dell'illustrazione admin062.gif

Vedere anche:

Prestazioni e tuning

L'amministratore del database Oracle è responsabile delle prestazioni del database. In genere, i problemi di prestazioni derivano da un tempo di risposta inaccettabile, ovvero il tempo necessario per completare un carico di lavoro o un throughput specificato, ovvero la quantità di lavoro che è possibile completare in un periodo di tempo specificato.

I problemi tipici includono:

L'obiettivo generale dell'ottimizzazione è di solito quello di migliorare i tempi di risposta, aumentare il throughput o entrambi. Un obiettivo specifico e misurabile potrebbe essere "Ridurre il tempo di risposta dell'istruzione SELECT specificata a meno di 5 secondi". Il fatto che questo obiettivo sia raggiungibile dipende da fattori che possono o meno essere sotto il controllo del DBA. In generale, il tuning è lo sforzo per raggiungere obiettivi di tuning specifici, misurabili e raggiungibili utilizzando le risorse del database nel modo più efficiente possibile.

Il metodo delle prestazioni di Oracle si basa sull'identificazione ed eliminazione dei colli di bottiglia nel database e sullo sviluppo di istruzioni SQL efficienti. L'applicazione del metodo delle prestazioni Oracle prevede quanto riportato di seguito.

Questa sezione descrive gli aspetti essenziali dell'ottimizzazione delle prestazioni di Oracle AI Database, incluso l'uso di consulenti. I consulenti di Oracle AI Database forniscono suggerimenti specifici per gestire i problemi chiave relativi a numerosi aspetti della gestione del database, quali ad esempio, lo spazio, le prestazioni e gli undo.

Monitoraggio automatico del database

L'auto-monitoraggio avviene quando il database esegue il suo normale funzionamento, assicurando che il database sia a conoscenza dei problemi man mano che si presentano. Oracle AI Database può inviare un avviso generato dal server per avvisarti di un problema imminente.

Gli avvisi vengono generati automaticamente quando si verifica un problema o quando i dati non corrispondono ai valori previsti per metriche quali letture fisiche al secondo o tempo di risposta SQL. Una metrica rappresenta la percentuale di modifica in una statistica cumulativa. Gli avvisi generati dal server possono essere basati su livelli di soglia specificati dall'utente o perché si è verificato un evento.

Gli avvisi generati dal server non solo identificano il problema, ma a volte consigliano come il problema segnalato può essere risolto. Un esempio è un avviso che l'area di recupero rapido sta esaurendo lo spazio con il suggerimento che i backup obsoleti dovrebbero essere eliminati o lo spazio su disco aggiuntivo aggiunto.

Vedi anche: Oracle AI Database Administrator's Guide

AWR (Automatic Workload Repository)

Automatic Workload Repository (AWR) è un repository di dati cronologici sulle prestazioni che include statistiche cumulative per il sistema, le sessioni, le singole istruzioni SQL, i segmenti e i servizi.

Le statistiche AWR sono alla base dell'ottimizzazione delle prestazioni. Automatizzando la raccolta delle statistiche del database per il rilevamento e l'ottimizzazione dei problemi, AWR funge da base per l'autogestione del database.

Come mostrato nel grafico seguente, il database memorizza le statistiche AWR recenti nell'area SGA. Per impostazione predefinita, il processo MMON raccoglie le statistiche ogni ora e crea uno snapshot AWR. Per istantanea AWR si intende un set di statistiche delle prestazioni acquisite in un momento specifico. Il database scrive gli snapshot nella tablespace SYSAUX. AWR gestisce lo spazio degli snapshot, rimuovendo gli snapshot meno recenti in base a un criterio di conservazione degli snapshot configurabile.

Figura 9: AWR (Automatic Workload Repository)

Descrizione dell'illustrazione cncpt279.gif

Una base AWR è una raccolta di tassi di statistica utilizzati in genere in un periodo in cui il sistema si sta comportando bene al massimo carico. È possibile specificare una coppia o un intervallo di snapshot AWR come baseline. Utilizzando un report AWR per confrontare le statistiche acquisite durante un periodo di prestazioni errate con una baseline, è possibile diagnosticare i problemi.

Un'infrastruttura di manutenzione automatica nota come AutoTask illustra in che modo Oracle Database utilizza AWR per l'autogestione. Analizzando i dati AWR, AutoTask può determinare la necessità di task di manutenzione e pianificarne l'esecuzione nelle finestre di manutenzione di Oracle Scheduler. Esempi di task includono la raccolta delle statistiche per l'ottimizzatore e l'esecuzione di Automatic Segment Advisor.

Vedere anche:

ADDM (Automatic Database Monitor)

Utilizzando le statistiche acquisite in AWR (Automatic Workload Repository), ADDM diagnostica in modo automatico e proattivo le prestazioni del database e determina la modalità di risoluzione dei problemi identificati. È possibile eseguire ADDM anche manualmente. ADDM (Automatic Database Diagnostic Monitor) è un motore autodiagnostico integrato in Oracle Database.

ADDM adotta un approccio olistico alle prestazioni del sistema, utilizzando il tempo come valuta comune tra i componenti. ADDM identifica le aree di Oracle Database che richiedono più tempo. Ad esempio, il database potrebbe trascorrere una quantità eccessiva di tempo in attesa di buffer di database gratuiti. ADDM esegue il drill-down per identificare la causa principale dei problemi, anziché solo i sintomi, e segnala l'effetto del problema su Oracle Database in generale. Durante il processo si verifica un sovraccarico minimo.

In molti casi, ADDM consiglia soluzioni e quantifica i benefici attesi delle prestazioni. Ad esempio, ADDM può consigliare modifiche a hardware, configurazione del database, schema di database o applicazioni. Se viene fornito un suggerimento, ADDM segnala il benefit temporale. L'uso del tempo come misura consente confronti di problemi o raccomandazioni.

Oltre a segnalare potenziali problemi di prestazioni, ADDM documenta le aree del database che non rappresentano problemi. Subcomponenti come I/O e memoria che non hanno un impatto significativo sulle prestazioni del database vengono eliminati dalla struttura di classificazione in una fase iniziale. ADDM elenca questi sottocomponenti in modo da poter vedere rapidamente che l'esecuzione di azioni in tali aree presenta pochi vantaggi.

Vedi anche: Oracle AI Database Introduzione al tuning delle prestazioni e Oracle AI Database Performance Tuning Guide

ASH (Active Session History)

Active Session History (ASH) analizza le sessioni di database attive ogni secondo, scrivendo i dati in memoria e storage persistente. ASH è parte integrante della struttura d'autogestione del database ed è molto utile per diagnosticare problemi di prestazioni.

A differenza delle statistiche a livello di istanza raccolte da Automatic Workload Repository (AWR), il database raccoglie le statistiche ASH a livello di sessione. Una sessione attiva è una sessione che utilizza la CPU e non è in attesa di un evento nella classe di attesa inattiva.

È possibile utilizzare gli script Enterprise Manager o SQL per generare report ASH che raccolgono le statistiche delle sessioni raccolte per una durata specificata. È possibile utilizzare i rapporti ASH per:

Ad esempio, un utente notifica che il database è stato lento tra le 10:00 e le 10:02. Tuttavia, il degrado delle prestazioni di 2 minuti rappresenta una piccola parte dell'intervallo snapshot AWR dalle 10:00 p.m. e dalle 11:00 p.m. e non viene visualizzato nei risultati ADDM. I report ASH possono aiutare a identificare l'origine del problema transitorio.

Vedi anche: Oracle AI Database Introduzione al tuning delle prestazioni e Oracle AI Database Performance Tuning Guide

Tuning delle applicazioni e delle istruzioni SQL

Oracle Database automatizza completamente il processo di SQL tuning.

ADDM identifica le istruzioni SQL che utilizzano risorse di sistema insolitamente elevate e pertanto causano problemi di prestazioni. Inoltre, AWR acquisisce automaticamente le prime istruzioni SQL in termini di consumo di CPU e memoria condivisa. L'identificazione delle istruzioni SQL ad alto carico avviene automaticamente e non richiede alcun intervento.

Istruzione EXPLAIN PLAN

Strumenti come l'istruzione EXPLAIN PLAN consentono di visualizzare i piani di esecuzione scelti dall'ottimizzatore.

EXPLAIN PLAN mostra il piano di query per la query SQL specificata se è stata eseguita ora nella sessione corrente. Altri strumenti sono Oracle Enterprise Manager e il comando SQL*Plus AUTOTRACE.

Vedi anche: Oracle AI Database SQL Language Reference per informazioni su EXPLAIN PLAN

Advisor statistiche dell'optimizer

Optimizer Statistics Advisor è un software diagnostico che analizza la modalità di raccolta delle statistiche, l'efficacia dei processi di raccolta delle statistiche esistenti e la qualità delle statistiche raccolte. Optimizer Statistics Advisor utilizza lo stesso framework Advisor di Automatic Database Diagnostic Monitor (ADDM), SQL Performance Analyzer e altri consulenti.

Optimizer Statistics Advisor offre i seguenti vantaggi rispetto all'approccio tradizionale, che si basa sulle best practice:

Optimizer Statistics Advisor gestisce le regole, ovvero gli standard forniti da Oracle in base ai quali l'advisor esegue i controlli. Le regole incorporano le procedure ottimali Oracle in base al set di funzioni corrente. Se le procedure ottimali cambiano da release a release, cambiano anche le regole di Optimizer Statistics Advisor. In questo modo, il consulente fornisce sempre le raccomandazioni più aggiornate.

Optimizer Statistics Advisor ispeziona il processo di raccolta delle statistiche e quindi genera un report dei risultati, ovvero violazioni delle regole. Se l'advisor formula suggerimenti e propone azioni basate su questi suggerimenti, è possibile implementare automaticamente le azioni o generare uno script PL/SQL modificabile ed eseguibile.

Il task Advisor viene eseguito automaticamente nella finestra di manutenzione, ma è anche possibile eseguirlo su richiesta.

Vedere anche:

SQL Tuning Advisor

L'interfaccia per il tuning SQL automatico è SQL Tuning Advisor, che viene eseguito automaticamente durante le finestre di manutenzione del sistema come task di manutenzione.

Durante ogni esecuzione automatica, l'advisor seleziona query SQL ad alto carico nel database e genera suggerimenti per il tuning di queste query.

I suggerimenti di SQL tuning advisor rientrano nelle seguenti categorie:

Un profilo SQL contiene statistiche aggiuntive specifiche di un'istruzione SQL e consente all'ottimizzatore di generare un piano di esecuzione migliore. In sostanza, un profilo SQL è un metodo per analizzare una query. Sia l'analisi del percorso di accesso che quella della struttura SQL sono utili per il tuning di un'applicazione in fase di sviluppo o di produzione interna.

Un vantaggio principale di SQL Tuning Advisor è che le soluzioni provengono dall'ottimizzatore anziché da strumenti esterni. Pertanto, il tuning viene eseguito dal componente di database responsabile dei piani di esecuzione e delle prestazioni SQL. Il processo di tuning può considerare le statistiche di esecuzione passate di un'istruzione SQL e personalizzare le impostazioni dell'ottimizzatore per questa istruzione.

Vedere anche:

SQL Access Advisor

Utilizzare SQL Access Advisor per facilitare l'analisi delle query SQL e determinare i modi per ottimizzare gli oggetti dello schema o le query di tuning.

SQL Access Advisor fornisce suggerimenti su come ottimizzare i percorsi di accesso ai dati. In particolare, è consigliabile migliorare le prestazioni del database mediante il partizionamento, le viste materializzate, gli indici e i log delle viste materializzate.

Gli oggetti dello schema, come partizioni e indici, sono essenziali per ottimizzare query complesse e a uso intensivo di dati. Tuttavia, la creazione e la gestione di questi oggetti possono richiedere molto tempo e i requisiti di spazio possono essere significativi. SQL Access Advisor consente di raggiungere gli obiettivi prestazioni consigliando le strutture di dati per un carico di lavoro specificato.

È possibile eseguire SQL Access Advisor da Enterprise Manager utilizzando una procedura guidata o utilizzando il package DBMS_ADVISOR. DBMS_ADVISOR è costituito da una raccolta di funzioni e procedure di analisi e consulenza richiamabili da qualsiasi programma PL/SQL.

Vedi anche: Oracle AI Database Introduzione al tuning delle prestazioni e Oracle AI Database SQL Tuning Guide

Gestione del piano SQL

Gestisci i piani di esecuzione SQL utilizzando la gestione dei piani SQL per eseguire solo piani testati e verificati.

Per impostazione predefinita, SQL Plan Management (SPM) Evolve Advisor viene eseguito quotidianamente nella finestra di manutenzione pianificata, classifica tutti i piani non accettati ed esegue esecuzioni di test del maggior numero possibile di piani. SPM Evolve Advisor seleziona il piano accettato a costo più basso nella baseline del piano SQL da confrontare con ogni piano non accettato. Se il piano non accettato funziona sufficientemente meglio del piano accettato esistente, il consulente lo accetta.

Se abilitata, SPM ad alta frequenza eseguirà SPM Evolve Advisor in un task periodico in background al di fuori della finestra di manutenzione per consentire miglioramenti delle prestazioni più tempestivi. Il task ad alta frequenza identificherà le istruzioni SQL utilizzando risorse di sistema significative e verificherà se un piano di esecuzione SQL utilizzato in precedenza funziona meglio. In questo caso, verrà creata una nuova baseline del piano SQL per applicare il piano di esecuzione SQL precedente e correggere la regressione delle prestazioni SQL.

A partire da Oracle Database 26ai, se abilitato, l'SPM in tempo reale avvierà immediatamente l'analisi delle prestazioni se un'istruzione SQL utilizza un nuovo piano di esecuzione SQL. Se un piano di esecuzione SQL visualizzato in precedenza funziona meglio, verrà creata immediatamente una nuova baseline del piano SQL senza fare affidamento su un task in background per eseguire questa operazione.

Vedere anche: