Exadata: Descoberta inútil

Olá pessoal, hoje estou trazendo uma descoberta bastante inútil (eu avisei, leia por sua conta e risco), mas como sou curioso talvez tenha pessoas por aí assim como eu….

Recentemente estou focando bastante meus estudos no Exadata Database Machine, principalmente no que se diz respeito à performance do banco de dados Oracle neste tipo de ambiente.

Com estes estudos descobri que você pode mostrar a operação “Table Access Storage Full” no plano de execução no seu ambiente non-Exadata. Não, você não transformará o seu ambiente num Exadata e também não terá vantagem nenhuma em fazer isso. Exatamente por isso que esta descoberta é inútil e só serve a título de curiosidade. 😀

Bom, para este teste você pode inclusive utilizar o Oracle Live SQL, exatamente como usei aqui.

O teste é bastante simples e para que esse comportamento ocorra é só alterar o parâmetro cell_offload_plan_display, o valor default é “auto”, ou seja, ele só é mostrado quando estamos executando num ambiente Exadata, mas nesse teste estou definindo para “always” para que sempre seja apresentado a string “Storage” no plano de execução.

Observe a primeira execução sem alterar nada no ambiente:

Exadata on Live SQL

Veja que a operação no plano de execução se mostra de maneira comum: “Table Access Full”.

Agora observe nesta execução após alterar o parâmetro na minha sessão:

Exadata on Live SQL

Viram? Virou um Exadata… “Table Access Storage Full”. 😐

Era isso. Desculpe-me pela perda de tempo… hahaha

Franky

  • Olá André,

    O que consegui entender por esta frase é que usando este parâmetro como ALWAYS você pode identificar “o que” pode se beneficiar do offload no Exadata e não um tipo de segmento em específico.
    Acho que é mais no sentido do tipo de queries, SQL Funcitons, essas coisas.

    Segundo a documentação, estes são os predicados que não se beneficiam do offload:

    Predicate evaluation is not offloaded to Oracle Exadata Storage Server in the following cases:
    • The CELL_OFFLOAD_PROCESSING parameter is set to FALSE.
    • The table or partition being scanned is small.
    • The optimizer does not use direct path read.
    • A scan is performed on a clustered table.
    • A scan is performed on an index-organized table.
    • A fast full scan is performed on compressed indexes.
    • A fast full scan is performed on reverse key indexes.
    • The table has row dependencies enabled or the rowscn is being fetched.
    • The optimizer wants the scan to return rows in ROWID order.
    • The optimizer does not use direct path read.
    • The command is CREATE INDEX using nosort.
    • A LOB or LONG column is being selected or queried.
    • A SELECT … VERSIONS query is done on a table.
    • A query that has more than 255 columns referenced and heap table is uncompressed, or Basic or OLTP compressed. However such queries on Exadata Hybrid Columnar Compression-compressed tables are offloaded.
    • The tablespace is encrypted, and the CELL_OFFLOAD_DECRYPTION parameter is set to FALSE. In order for Oracle Exadata Storage Server Software to perform decryption, Oracle Database needs to send the decryption key to Oracle Exadata Storage Server. If there are security concerns about keys being shipped across the network to Oracle Exadata Storage Server, then disable the decryption feature.
    • The tablespace is not completely stored on Oracle Exadata Storage Server.
    • The predicate evaluation is on a virtual column.

    Referência: https://docs.oracle.com/cd/E80920_01/SAGUG/exadata-storage-server-monitoring.htm#SAGUG20523

    Abraços,

    Franky

  • Andre Santos

    Franky
    Esse tipo de coisa, aparentemente inútil, também ajuda a despertar a curiosidade! rs
    Fui ver a documentação e consta o seguinte:
    “You can use this setting to see what can be offloaded to Oracle Exadata Storage Server before migrating to Oracle Exadata Storage Server.”
    Mas o que não poderia ser migrado para o Exadata Storage? Acho que qualquer segmento pode, não é?
    Parabéns pelo blog!