Scansione intelligente - AWS Guida prescrittiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Scansione intelligente

Exadata utilizza il suo sottosistema di archiviazione basato sul database per scaricare il carico di elaborazione dai server di database spostando parte dell'elaborazione SQL sui server delle celle di archiviazione. Exadata Smart Scan è in grado di ridurre il volume di dati che vengono restituiti ai server del database attraverso la filtrazione in offload e la proiezione di colonne. Questa funzionalità risolve due delle principali sfide legate alla gestione di set di dati di grandi dimensioni: il trasferimento di dati enormi e non necessari dal livello di archiviazione ai server di database e il tempo e le risorse impiegate per filtrare i dati richiesti. Smart Scan è un'importante funzionalità di Cell Offload Processing, che include anche l'inizializzazione dei file di dati, la decompressione HCC e altre funzionalità.

Il flusso di dati proveniente da Smart Scan non può essere memorizzato nel buffer pool SGA (System Global Area). Smart Scan richiede una lettura diretta del percorso, che viene memorizzata nel buffer nell'area globale del programma (PGA). Un'istruzione SQL deve soddisfare alcuni requisiti per funzionare con Smart Scan:

  • Il segmento richiesto dall'istruzione SQL deve essere archiviato in un sistema Exadata in cui è impostato l'cell.smart_scan_capableattributo di impostazione del gruppo di dischi ASM su. TRUE

  • È necessario eseguire una scansione completa della tabella o un'operazione di scansione completa rapida dell'indice.

  • Il segmento coinvolto nell'istruzione SQL deve essere sufficientemente grande da essere sottoposto a un'operazione di lettura diretta del percorso.

Per valutare l'efficienza di Smart Scan in un sistema Exadata, è necessario prendere in considerazione le seguenti statistiche chiave del database:

  • physical read total bytes— La quantità totale di byte di I/O per le operazioni di lettura emesse dal database, indipendentemente dal fatto che l'operazione sia stata scaricata sui server di storage. Indica le operazioni di lettura totali, in byte, emesse dai server di database alle celle di archiviazione Exadata. Questo valore riflette la capacità di I/O di lettura che la piattaforma di destinazione su AWS deve soddisfare quando si migra il carico di lavoro su AWS senza ottimizzarlo.

  • cell physical IO bytes eligible for predicate offload— La quantità di operazioni di lettura, in byte, che vengono immesse in Smart Scan e sono idonee per l'offload dei predicati.

  • cell physical IO interconnect bytes— Il numero di byte di I/O scambiati tramite l'interconnessione tra il server di database e le celle di archiviazione. Questo copre tutti i tipi di traffico I/O tra database e nodi di archiviazione, inclusi i byte restituiti da Smart Scan, i byte restituiti da query non idonee per Smart Scan e le operazioni di scrittura.

  • cell physical IO interconnect bytes returned by smart scan— Byte di I/O restituiti dalla cella per le operazioni Smart Scan. Questo è l'output di Smart Scan.

  • cell physical IO bytes eligible for predicate offload— È possibile confrontare questo valore con i byte totali di lettura fisici per capire quante operazioni di lettura totali sono soggette a Smart Scan. Il rapporto tra cell physical IO bytes eligible for predicate offload (input per Smart Scan) e cell physical IO interconnect bytes returned by smart scan (output di Smart Scan) indica l'efficienza di Smart Scan. Per un sistema Exadata che include principalmente operazioni di lettura, il rapporto tra cell physical IO interconnect bytes returned by smart scan to cell physical IO interconnect bytes può indicare la dipendenza da Smart Scan. Tuttavia, potrebbe non essere sempre così, perché include cell physical IO interconnect bytes anche il doppio del numero di operazioni di scrittura (con mirroring ASM) tra i server di elaborazione e di archiviazione.

È possibile ottenere queste statistiche di I/O del database e lemetriche specifiche di Exadata dal report AWR o interrogando direttamente le viste V$ sottostanti come, e. V$SYSSTAT V$ACTIVE_SESSION_HISTORY V$SQL

Nell'esempio seguente, tratto da un rapporto AWR raccolto da un sistema Exadata, il database ha richiesto 5,7 Gbps di velocità di lettura, di cui 5,4 Gbps idonei per Smart Scan. L'output di Smart Scan ha contribuito a 55 MBps su 395 MBps di traffico di interconnessione totale tra database e nodi di calcolo. Queste statistiche indicano un sistema Exadata che dipende in larga misura da Smart Scan.

Dati sulle dipendenze di Smart Scan tratti dal rapporto Oracle AWR

È possibile valutare l'efficienza e le dipendenze di Smart Scan a livello SQL utilizzando le seguenti colonne della vista. V$SQL

  • IO_CELL_OFFLOAD_ELIGIBLE_BYTES— Numero di byte di I/O che possono essere filtrati dal sistema di storage Exadata.

  • IO_INTERCONNECT_BYTES— Numero di byte di I/O scambiati tra il database Oracle e il sistema di storage.

  • PHYSICAL_READ_BYTES— Numero di byte letti dai dischi dall'SQL monitorato.

Il seguente output di query mostra i vantaggi di Smart Scan per una query SQL con ID SQL. xn2fg7abff2d

select ROUND(physical_read_bytes/1048576) phyrd_mb , ROUND(io_cell_offload_eligible_bytes/1048576) elig_mb , ROUND(io_interconnect_bytes/1048576) ret_mb , (1-(io_interconnect_bytes/NULLIF(physical_read_bytes,0)))*100 "SAVING%" from v$sql where sql_id = 'xn2fg7abff2d' and child_number = 1; PHYRD_MB ELIG_MB RET_MB SAVING% ---------- ---------- ---------- ---------- 10815 10815 3328 69.2%

Per verificare l'influenza di Smart Scan sul carico di lavoro, è possibile disabilitare la funzionalità impostando il cell_offload_processing parametro FALSE su a livello di sistema, sessione o query. Ad esempio, per disabilitare l'elaborazione dell'offload delle celle di Exadata Storage Server per un'istruzione SQL, è possibile utilizzare:

select /*+ OPT_PARAM('cell_offload_processing' 'false') */ max(ORDER_DATE) from SALES;

Per disabilitare l'elaborazione dell'offload delle celle di Exadata Storage Server per una sessione di database, è possibile impostare il seguente parametro di inizializzazione del database Oracle:

alter session set CELL_OFFLOAD_PROCESSING=FALSE;

Per disabilitare l'elaborazione dell'offload delle celle di Exadata Storage Server per l'intero database Exadata, è possibile impostare:

alter system set CELL_OFFLOAD_PROCESSING=FALSE;

Migrazione a AWS

Quando si migrano inizialmente i carichi di lavoro su Exadata, vengono implementate diverse modifiche alla progettazione come pratica comune per favorire Smart Scan, tra cui l'eliminazione degli indici dello schema per favorire le scansioni complete delle tabelle. Quando si eseguono la migrazione di tali carichi di lavoro su piattaforme non Exadata, è necessario annullare tali modifiche di progettazione.

Quando esegui la migrazione dei tuoi carichi di lavoro Exadata su AWS, prendi in considerazione queste azioni di ottimizzazione per ottimizzare le prestazioni delle query che utilizzano Smart Scan:

  • Utilizza istanze ottimizzate per la memoria e configura una SGA più grande per aumentare il buffer hit ratio.

  • Identifica le query eseguite con piani di esecuzione non ottimali e ottimizzale per ridurne l'ingombro di I/O.

  • Regola i parametri dell'ottimizzatore, ad esempio optimizer_index_cost_adj per evitare scansioni db_file_multiblock_read_count complete della tabella.

  • Scegliete un'opzione di compressione appropriata.

  • Se necessario, create indici di schema aggiuntivi.