Smart Flash Cache

La funzione Exadata Smart Flash Cache memorizza nella cache gli oggetti del database nella memoria flash per aumentare la velocità di accesso agli oggetti del database. Smart Flash Cache può determinare quali tipi di segmenti di dati e operazioni devono essere memorizzati nella cache. Riconosce diversi tipi di richieste di I/O in modo che l'accesso non ripetibile ai dati (come l'I/O di RMAN backup) non elimini i blocchi di database dalla cache. È possibile spostare hot table e indici in Smart Flash Cache con i comandi. ALTER Quando si utilizza la funzione Write Back Flash Cache, Smart Flash può anche memorizzare nella cache le operazioni di scrittura dei blocchi del database.

Il software del server di archiviazione Exadata fornisce anche Smart Flash Logging per velocizzare le operazioni di scrittura dei redo log e ridurre i tempi di servizio per l'evento di sincronizzazione dei file di registro. Questa funzionalità esegue le operazioni di redo write contemporaneamente sia sulla memoria flash che sulla cache del controller del disco e completa l'operazione di scrittura quando viene completata la prima delle due.

Le due statistiche seguenti forniscono informazioni rapide sulle prestazioni di Exadata Smart Flash Cache. Queste sono disponibili in visualizzazioni dinamiche delle prestazioni come V$SYSSTAT e nella sezione Global Activity Statistics o Instance Activity Statistics del AWR rapporto.

• Cell Flash Cache read hits— Registra il numero di richieste di lettura che hanno trovato una corrispondenza nella Smart Flash Cache.

• Physical read requests optimized— registra il numero di richieste di lettura che sono state ottimizzate da Smart Flash Cache o tramite indici di archiviazione.

Le metriche Exadata raccolte dalle celle di archiviazione sono utili anche per comprendere in che modo un carico di lavoro utilizza Smart Flash Cache. Il seguente CLI comando Cell elenca diverse metriche disponibili per il monitoraggio dell'utilizzo di Smart Flash Cache.

CellCLI> LIST METRICDEFINITION ATTRIBUTES NAME,DESCRIPTION WHERE OBJECTTYPE = FLASHCACHE
FC_BYKEEP_DIRTY                         "Number of megabytes unflushed for keep objects on FlashCache"
FC_BYKEEP_OLTP                          "Number of megabytes for OLTP keep objects in flash cache"
FC_BYKEEP_OVERWR                     "Number of megabytes pushed out of the FlashCache because of space limit
for keep objects"
FC_BYKEEP_OVERWR_SEC              "Number of megabytes per second pushed out of the FlashCache because of
space limit for keep objects"
...

Migrazione a AWS

Smart Flash Cache non esiste su. AWS Esistono poche opzioni per mitigare questa sfida ed evitare il degrado delle prestazioni durante la migrazione dei carichi di lavoro Exadata verso AWS, tra cui queste, discusse nelle sezioni seguenti:

• Utilizzo di istanze di memoria estesa

• Utilizzo di istanze con archivi di istanze NVMe basati

• Utilizzo AWS di opzioni di archiviazione per una bassa latenza e un throughput elevato

Tuttavia, queste opzioni non sono in grado di riprodurre il comportamento di Smart Flash Cache, quindi è necessario valutare le prestazioni del carico di lavoro per assicurarsi che continui a soddisfare le prestazioni. SLAs

Istanze di memoria estesa

Amazon EC2 offre molte istanze con memoria elevata, incluse istanze con 12 TiB e 24 TiB di memoria. Queste istanze supportano Oracle di dimensioni estremamente grandi SGAs che possono ridurre l'impatto della Smart Flash Cache mancante aumentando il rapporto di successo del buffer.

Istanze con archivi di istanze basati NVMe

Un instance store fornisce uno storage temporaneo a livello di blocco per l'istanza. L'archiviazione è collocata all'interno dei dischi fisicamente collegati al computer host. Gli instance store consentono ai carichi di lavoro di raggiungere una bassa latenza e un throughput più elevato archiviando i dati su dischi basati. NVMe I dati in un instance store persistono solo durante la vita di un'istanza, quindi gli instance store sono ideali per tablespace e cache temporanee. Gli instance store possono supportare milioni IOPS e più di 10 Gbps di throughput con una latenza di microsecondi, a seconda del tipo di istanze e delle dimensioni di I/O. Per ulteriori informazioni sul supporto di lettura/scrittura IOPS e throughput dell'instance store per diverse classi di istanze, consulta le istanze per uso generale, ottimizzate per il calcolo, ottimizzate per la memoria e ottimizzate per lo storage nella documentazione di Amazon. EC2

In Exadata, la Database Flash Cache consente agli utenti di definire un secondo livello di buffer cache sui volumi di archiviazione delle istanze con una latenza I/O media di 100 microsecondi per migliorare le prestazioni dei carichi di lavoro di lettura. È possibile attivare questa cache impostando due parametri di inizializzazione del database:

• db_flash_cache_file = /<device_name>

• db_flash_cache_size = <size>G

Puoi anche progettare architetture ad alte prestazioni per i database Oracle ospitati su Amazon EC2 inserendo i file di database negli archivi di istanze e utilizzando la ridondanza fornita da Oracle Automatic Storage Management (ASM) e Data Guard per la protezione e il ripristino dei dati in caso di perdita dei dati negli store delle istanze. Questi modelli di architettura sono ideali per le applicazioni che richiedono un throughput di I/O estremo a bassa latenza e possono permettersi un ripristino del sistema superiore in determinati scenari RTO di errore. Le sezioni seguenti illustrano brevemente due architetture che includono file di database ospitati su archivi di istanze basati. NVMe

Architettura 1. Il database è ospitato negli archivi di istanze sia sulle istanze primarie che su quelle di standby con Data Guard per la protezione dei dati

In questa architettura, il database è ospitato su un gruppo di ASM dischi Oracle per distribuire l'I/O su più volumi di archiviazione di istanze per un I/O ad alta velocità effettiva e bassa latenza. Uno standby di Data Guard viene collocato nella stessa zona di disponibilità o in un'altra per la protezione dalla perdita di dati negli archivi di istanze. La configurazione del gruppo di dischi dipende dalla latenza e la conferma. RPO Se l'Instance Store viene perso per qualsiasi motivo sull'istanza principale, il database può passare allo standby con una perdita di dati minima o pari a zero. È possibile configurare il processo di osservazione di Data Guard per automatizzare il failover. Sia le operazioni di lettura che quelle di scrittura traggono vantaggio dall'elevato throughput e dalla bassa latenza offerte dagli instance store.

Architettura 2. Il database è ospitato su un gruppo di ASM dischi con due gruppi di errore che combinano EBS volumi e archivi di istanze

In questa architettura, tutte le operazioni di lettura vengono eseguite dagli archivi di istanze locali utilizzando il ASM_PREFERRED_READ_FAILURE_GROUP parametro. Le operazioni di scrittura si applicano sia ai volumi di instance store che ai volumi Amazon Elastic Block Store (AmazonEBS). Tuttavia, la EBS larghezza di banda di Amazon è dedicata alle operazioni di scrittura, poiché le operazioni di lettura vengono trasferite sui volumi di archiviazione delle istanze. In caso di perdita di dati negli archivi di istanze, puoi recuperare i dati dal gruppo di ASM errore in base ai EBS volumi o dal database di standby. Per ulteriori informazioni, consultare il white paper di Oracle Mirroring and Failure Groups with ASM. È possibile implementare Data Guard standby in una zona di disponibilità diversa per una protezione aggiuntiva.

Amazon RDS for Oracle supporta Database Smart Flash Cache e tablespace temporanee negli archivi di istanze. I carichi di lavoro del database Oracle possono utilizzare questa funzionalità per ottenere una latenza inferiore per le operazioni di lettura, un throughput più elevato e un utilizzo efficiente della larghezza di banda di EBS Amazon per altre operazioni di I/O del database. Questa funzionalità è attualmente supportata nelle classi di istanze db.m5d, db.r5d, db.x2idn e db.x2iedn. Per le informazioni più recenti, consulta Classi di istanze supportate RDS per l'instance store for Oracle nella RDS documentazione di Amazon.

AWSopzioni di storage per carichi di lavoro che richiedono bassa latenza e throughput elevato

I tipi di EBS volume attualmente supportati da Amazon RDS for Oracle, gp2, gp3 e io1, sono basati su unità a stato solido (). SSDs Quando distribuisci questi tipi di volume con le classi di istanze EBS ottimizzate per Amazon appropriate, in genere possono soddisfare i tuoi requisiti di tempo di servizio e throughput. IOPs

Per le implementazioni di database Oracle autogestite su Amazon, i EBSvolumi EC2 Amazon EBS io2 e io2 Block Express offrono scelte aggiuntive per i carichi di lavoro che richiedono una latenza inferiore e un throughput più elevato.

I carichi di lavoro che richiedono un throughput più elevato o latenze di microsecondi possono utilizzare volumi di storage che non sono basati su Amazon EBS quando vengono distribuiti come database Oracle autogestiti su Amazon. EC2 Ad esempio, Amazon FSx for Open ZFS può fornire più di 1 milione IOPS con un throughput di 20 Gbsp o superiore con una latenza di poche centinaia di microsecondi. Amazon FSx for NetApp ONTAP è in grado di fornire centinaia di migliaia di applicazioni IOPS con una latenza inferiore a un millisecondo.