Skip to main content
Enterprise applications
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Verifica dell'allineamento di WAFL per i database Oracle

Collaboratori

Il corretto allineamento dell'WAFL è fondamentale per garantire buone prestazioni. Sebbene ONTAP gestisca blocchi in 4KB unità, questo fatto non significa che ONTAP esegua tutte le operazioni in 4KB unità. Infatti, ONTAP supporta operazioni a blocchi di diverse dimensioni, ma la contabilità sottostante è gestita da WAFL in 4KB unità.

Il termine "allineamento" si riferisce al modo in cui l'i/o Oracle corrisponde a queste unità 4KB. Per ottenere prestazioni ottimali è necessario che un blocco Oracle 8KB risieda su due blocchi fisici da 4KB WAFL su un'unità. Se un blocco è sfalsato di 2KB, questo blocco risiede su metà di un blocco 4KB, un blocco 4KB completo separato e quindi sulla metà di un terzo blocco 4KB. Questa disposizione causa un peggioramento delle prestazioni.

L'allineamento non è un problema con i file system NAS. I file di dati Oracle sono allineati all'inizio del file in base alle dimensioni del blocco Oracle. Pertanto, le dimensioni dei blocchi di 8KB, 16KB e 32KB sono sempre allineate. Tutte le operazioni di blocco sono sfalsate dall'inizio del file in unità di 4 kilobyte.

I LUN, al contrario, contengono generalmente qualche tipo di intestazione del driver o metadati del file system all'inizio che creano un offset. L'allineamento è raramente un problema nei sistemi operativi moderni, perché questi sistemi operativi sono progettati per unità fisiche che potrebbero utilizzare un settore 4KB nativo, che richiede anche l'allineamento dell'i/o ai confini del 4KB per ottenere prestazioni ottimali.

Ci sono, tuttavia, alcune eccezioni. È possibile che un database sia stato migrato da un sistema operativo meno recente non ottimizzato per i/o 4KB o che un errore utente durante la creazione della partizione abbia causato un offset che non è in unità di 4KB.

I seguenti esempi sono specifici per Linux, ma la procedura può essere adattata per qualsiasi sistema operativo.

Allineato

L'esempio seguente mostra un controllo dell'allineamento su un singolo LUN con una singola partizione.

Innanzitutto, creare la partizione che utilizza tutte le partizioni disponibili sul disco.

[root@host0 iscsi]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb97f94c1.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-10240, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-10240, default 10240):
Using default value 10240
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@host0 iscsi]#

L'allineamento può essere controllato matematicamente con il seguente comando:

[root@host0 iscsi]# fdisk -u -l /dev/sdb
Disk /dev/sdb: 10.7 GB, 10737418240 bytes
64 heads, 32 sectors/track, 10240 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 65536 bytes
Disk identifier: 0xb97f94c1
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              32    20971519    10485744   83  Linux

L'output mostra che le unità sono 512 byte, e l'inizio della partizione è 32 unità. Si tratta di un totale di 32 x 512 = 16.834 byte, ovvero un multiplo intero di 4KB blocchi WAFL. Questa partizione è allineata correttamente.

Per verificare il corretto allineamento, attenersi alla seguente procedura:

  1. Identificare l'UUID (Universal Unique Identifier) del LUN.

    FAS8040SAP::> lun show -v /vol/jfs_luns/lun0
                  Vserver Name: jfs
                      LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd
                        Mapped: mapped`                `
  2. Immettere la shell del nodo sul controller ONTAP.

    FAS8040SAP::> node run -node FAS8040SAP-02
    Type 'exit' or 'Ctrl-D' to return to the CLI
    FAS8040SAP-02> set advanced
    set not found.  Type '?' for a list of commands
    FAS8040SAP-02> priv set advanced
    Warning: These advanced commands are potentially dangerous; use
             them only when directed to do so by NetApp
             personnel.
  3. Avviare le raccolte statistiche sull'UUID di destinazione identificato nel primo passaggio.

    FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd
    Stats identifier name is 'Ind0xffffff08b9536188'
    FAS8040SAP-02*>
  4. Eseguire alcuni i/O. È importante utilizzare iflag Argomento per assicurarsi che i/o sia sincrono e non bufferizzato.

    Nota Prestare molta attenzione con questo comando. Inversione del if e. of gli argomenti distruggono i dati.
    [root@host0 iscsi]# dd if=/dev/sdb1 of=/dev/null iflag=dsync count=1000 bs=4096
    1000+0 records in
    1000+0 records out
    4096000 bytes (4.1 MB) copied, 0.0186706 s, 219 MB/s
  5. Arrestare le statistiche e visualizzare l'istogramma di allineamento. Tutti i i/o devono trovarsi in .0 Bucket, che indica i/o allineato al limite di un blocco 4KB.

    FAS8040SAP-02*> stats stop
    StatisticsID: Ind0xffffff08b9536188
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:186%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0%

Disallineato

L'esempio seguente mostra i/o disallineati:

  1. Creare una partizione che non si allinea a un confine 4KB. Questo non è il comportamento predefinito sui sistemi operativi moderni.

    [root@host0 iscsi]# fdisk -u /dev/sdb
    Command (m for help): n
    Command action
       e   extended
       p   primary partition (1-4)
    p
    Partition number (1-4): 1
    First sector (32-20971519, default 32): 33
    Last sector, +sectors or +size{K,M,G} (33-20971519, default 20971519):
    Using default value 20971519
    Command (m for help): w
    The partition table has been altered!
    Calling ioctl() to re-read partition table.
    Syncing disks.
  2. La partizione è stata creata con un offset a 33 settori anziché con il valore predefinito 32. Ripetere la procedura descritta in "Allineato". L'istogramma viene visualizzato come segue:

    FAS8040SAP-02*> stats stop
    StatisticsID: Ind0xffffff0468242e78
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:136%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:4%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0%
    lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_partial_blocks:31%

    Il disallineamento è chiaro. L'i/o rientra principalmente in* *.1 benna, che corrisponde all'offset previsto. Quando la partizione è stata creata, è stata spostata di 512 byte più avanti nel dispositivo rispetto al valore predefinito ottimizzato, il che significa che l'istogramma è spostato di 512 byte.

    Inoltre, il read_partial_blocks Le statistiche sono diverse da zero, il che significa che è stato eseguito l'i/o che non ha riempito l'intero blocco da 4KB KB.

Ripristina la logging

Le procedure qui spiegate sono applicabili ai file di dati. I log di ripristino e gli archivi di Oracle hanno modelli di i/o diversi. Ad esempio, il redo logging è una sovrascrittura circolare di un singolo file. Se si utilizza la dimensione predefinita del blocco da 512 byte, le statistiche di scrittura sono simili a queste:

FAS8040SAP-02*> stats stop
StatisticsID: Ind0xffffff0468242e78
lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.0:12%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.1:8%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.2:4%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.3:10%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.4:13%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.5:6%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.6:8%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.7:10%
lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_partial_blocks:85%

L'i/o viene distribuito in tutti i bucket di istogramma, ma non si tratta di un problema di prestazioni. Velocità di redo-logging estremamente elevate potrebbero, tuttavia, trarre vantaggio dall'utilizzo di dimensioni del blocco di 4KB KB. In questo caso, è consigliabile assicurarsi che i LUN di redo-logging siano allineati correttamente. Tuttavia, questo non è importante per le buone prestazioni come l'allineamento dei file dati.