exadata - o todo é maior que a soma das partes
DESCRIPTION
Apresentação Exadata para o Failsafe Days 2014TRANSCRIPT
EXADATA
“O TODO É MAIOR QUE A SOMA DAS
PARTES”
Luís Marques - @drune http://lcmarques.com
@FailsafeSA
#failsafedays
AGENDA
• O que é o Exadata – “O Ferro”
• Offloading / Smart Scan – “A alma do negócio”
• Storage Indexes
• Hybrid Columnar Compression
• Exadata Smart Flash Cache
• Entender Exadata Performance – “Isto sim!”
• (Des)(Re) Aprendizagem Exadata
Twitter: @failsafeSA #failsafedays
EXADATA – O QUE É?
• Bottleneck: Mover quantidades massivas de dados da Storage
para o Database Server
• 2 partes: “Storage layer” e “Database layer”
Twitter: @failsafeSA #failsafedays
EXADATA – O QUE É?
• Database layer
• Vários servidores (Sun Intel x86-64) a correr Oracle 11gR2
• Configurados em um ou mais RAC clusters
• RAC não é obrigatório
• ASM é obrigatório com o objectivo do mapping do “storage layer”.
• Storage layer
• Vários servidores (Sun Intel x86-64)
• Corre Oracle software server software – cellsrv
• A comunicação é feita entre layers via iDB – protocolo de rede sobre InfiniBand
• Não há comunicação directa entre storage cells
Twitter: @failsafeSA #failsafedays
EXADATA – DB LAYER
• Database Layer/Server Software
• Arquitectura Intel x86-64 a correr OEL 5/6
• Oracle 11gR2 instalado – Nada específico em relação ao
Exadata
• ASM (Oracle Automatic Storage Management) – DB
servers sem acesso directo ao storage
• iostat torna-se inútil – Sem OS calls para abrir/fechar
ficheiros.
• ASM é totalmente responsável pela redundância:
Normal/High – Não há RAID por hardware/software
• ASM – Mirroring entre as storage cells
• RAC é aconselhado quando necessário!
Twitter: @failsafeSA #failsafedays
EXADATA – STORAGE LAYER
• Storage Layer/Server Software
• Arquitectura Intel x86-64 a correr OEL 5/6
• Cell Services (cellsrv)• Multi-threaded
• Processa pedidoPode enviar dados já processados ou blocosde volta para o database server
• s I/O vindos dos Database Layer.
• Implementa o IORM (I/O Resource Manager)
• Management Server (MS)• Interface entre o cellsrv e o cellcli (Cell Command Line
Interface)
• Restart Server (RS)• Monitorização de processos
• OSWatcher• Colecta informação acerca do SO: vmstat e netstat
Twitter: @failsafeSA #failsafedays
EXADATA – IDB
• IDB – Intelligent Database protocol
• Comunicação entre os 2 layers
• Function shipping architecture – Informação sobre o SQL executado para as storage cells e reenvio de dados processados
• Limita os dados enviados para o Database server –apenas as rows e colunas que satisfazem a query
• Podem enviar blocos quando o offload não é possível;
• IDB usa RDS (Reliable Datagram Sockets) “over” Infiniband:
• Baixa latência
• Baixo overhead
• Uso mínimo de CPU
Twitter: @failsafeSA #failsafedays
EXADATA – DBS + SC + IDB
Twitter: @failsafeSA #failsafedays
EXADATA – É BONITO POR FORA?
Twitter: @failsafeSA #failsafedays
OFFLOAD/SMART SCAN
• Offload / Smart Scan – A cura para todos (quase) os males.
• Processamento feito nos storage servers em vez dos
database servers = OFFLOAD
• Smart Scan é uma “run time decision”
• Objectivos:
• Reduzir o volume de dados transferidos entre a storage e
o database servers
• Reduzir o consumo de CPU nos database servers
• Reduzir o tempo de acesso aos discos
Twitter: @failsafeSA #failsafedays
SMART SCAN - EXEMPLO
• Imaginemos que….
• 1 tabela com 1 coluna
• 50 registos por bloco
• Apenas 1 bloco de 8k
• Query:
select * from t1 where rowid = ‘AAAAB0AABAAAAOhAAA’
• Pelo menos o bloco todo tem que ser lido (8k) significando
uma transferência extra e inutil de 49 registos.
• Multipliquem isto por biliões = Demasiados dados
irrelevantes passados ao database server = bottleneck
Twitter: @failsafeSA #failsafedays
SMART SCAN - REQUISITOS
• Para obter um smart scan:
• Full Scan
• Full Table Scan (Table Access Storage Full)
• Index Fast Full Scan
• Direct Path Read
• Presente no 11gR2
• Os dados são lidos directamente para o PGA, fazendo
bypass da buffer cache (SGA)
• Parallel e Serial (SMALL_TABLE_THRESHOLD)
• Exadata Storage
• Objectos que usem uma mistura de Exadata Storage e
“não” Exadata storage não são eligiveis
Twitter: @failsafeSA #failsafedays
SMART SCAN – COLUMN
PROJECTION
• Column Projection
• Metadata enviada para as storage cells (via iDB)
• Resultado enviado via iDB
• Exemplo: 4 colunas de uma tabela de 100 colunas
possíveis : select a, b, c, d, e, f from table t where a=7;
• IO_CELL_OFFLOAD_ELIGIBLE_BYTES (volume de
dados evitados pelo uso da column projection)
• IO_INTERCONNECT_BYTES (volume de dados que
foram efectivamente retornados ao DB server)
Twitter: @failsafeSA #failsafedays
SMART SCAN –
PREDICATE FILTERING
• Predicate Filtering
• O iDB contem informação sobre os predicados
• As clausulas WHERE (filtering) é feito nas storage cells
em vez do database server.
• Exemplo:
• select a, b, c, d, e, f from table t where a=7;
• Redução do volume de dados enviado para o database
server
• Redução do uso do CPU
Twitter: @failsafeSA
“NON” SMART SCAN
• Smart File Creation
• Inicialização de blocos (formatação) quando alocados pelo
Database server
• Criação e extensão de datafiles (tablespaces)
• RMAN Incremental Backups
• BCT (Block Change Tracking) passa a ser individual ao
bloco em vez de grupo de blocos
• Menos blocos a serem backup, menos tempo de backup
• RMAN Restores
• “File initialization” durante o Restore
Twitter: @failsafeSA
SMART SCAN – “DISABLERS”
• Se algum dos requisitos não for cumprido
• No caso de:
• Clustered Tables
• Index Organized Tables (IOTs)
• Partial Smart Scan (block shipping mode)
• Chained rows – Smart Scan pausa, single block read
database server
• Read Consistency Issues – Se existir um bloco “mais
novo” que o lido pela query, single block read no database
server
Twitter: @failsafeSA
SMART SCAN – STORAGE
INDEXES
• Não são indices regulares (Btree, bitmap, etc)
• Indentificam a localização onde o registo não está
• Guardam o valor máximo e mínimo cada coluna e uma
flag para NULL em cada unidade de storage de 1MB.
• Não são passiveis de tuning nem alteração
• São recriados a cada storage cell reboot
Twitter: @failsafeSA
STORAGE INDEXES - IMAGEM
• Select a,b,c,d,e,f where col1=1001
Twitter: @failsafeSA
STORAGE INDEXES - REQUISITOS
• Requisitos
• Smart Scan / Offload
• Pelo menos um predicato (WHERE)
• Comparação: =, <, >, BETWEEN, >=, <=, IN, IS NULL, IS NOT NULL
• Suporta
• Multi predicados (WHERE…AND…AND)
• Joins entre várias tabelas
• Parallel Querys
• HCC
• Bind Variables
• Partitions
• Sub-querys
• Não Suportado
• CLOB
• Predicados com % (LIKE ‘%’)
Twitter: @failsafeSA
STORAGE INDEXES -
PERFORMANCE
• Podem resultar em aumentos dramáticos de performance
• A forma como os dados são ordenados) é
determinante (clustering factor*)
• Flag para valores NULL permite, ao contrário dos Btree
uma acrescimo de performance
Twitter: @failsafeSA
HCC – HYBRID COLUMNAR
COMPRESSION
• Tipos de Compressão disponíveis:
• BASIC• Compressão apenas com operação de direct path insert
• Unidade de compressão: bloco (8k/16k…)
• Datawarehousing oriented
• OLTP• Compressão para todos os tipos de operação
• Symbol table para valores repetidos
• Compressão não imediata: Quando o bloco fica cheio, a compressão ocorre
• Fallback do HCC
• HCC• Compressão apenas com operação de direct path insert:
• APPEND/ Parallel Insert/ SQL*Loader/CTAS…
• Outro tipo de operações = OLTP
Twitter: @failsafeSA
HCC – MECÂNICA
• Dados guardados em formato não convencional – ordenados e em forma de coluna
• Disponível apenas na Exadata storage
• Blocos combinados em estruturas: Compression Units (CU) com 32k/64k
• Formato intermédio entre row e column oriented storage:
• Permite ler um registo inteiro numa única CU
• Dados enviados para o Database server são comprimidos
• Decompressão = Database server
Twitter: @failsafeSA
EXADATA SMART FLASH CACHE
• Marketing: “The World’s First Database Machine for OLTP”
• Hardware
• Cell cache nos storage servers
• Cada storage server = 4 cartas Sun Flash PCIe
Accelerator F20 no total de 3.2TB (X4)
• “Oracle is using flash PCIe cards in Exadata – not
flash disks”
• 1.33 GB/s throughput em cada PCIe flash disk
• 1,960,000 8K write I/Os per second
• Full RAC = 56 PCI Flash Cards – 44.8 TB
• Energy Storage Module (ESM) – Flush de dados voláteis
para storage não volátil.
Twitter: @failsafeSA
ESFC – É BONITO POR FORA?
Twitter: @failsafeSA
EXADATA SMART FLASH CACHE
• Cache para os Storage disks
• Não sujeito a Smart Scans!
• Use Cases
• Cache (ESFC) – [CellCLI> create flashcache all]
• Discos ASM (SSD) [CellCLI> create flashcache all size=200g]
• Ambos
• Performance
• Usa PCIe cards em vez de discos SSDs para evitarbottleneck das controladoras (disk interface)
• Smart Caching
• Data cache inteligente – Dados “hot” na Flash Cache
• Dados ou objectos “non hot” são ignorados
• Optimização de políticas de caching por parte do DBA (alter table foo.bar storage (cell_flash_cache keep);
• Exadata Flash Cache compression (~80T X4 full rack): Hardware capable
Twitter: @failsafeSA
ESFC – COMO FUNCIONA?
Twitter: @failsafeSA
EXADATA SMART FLASH LOG
• Redo no discos Flash Cache/SSD? NÃO!
• A não ser que…
• Over budget – Demasiado dinheiro para comprar discos
normais
• Tenham um Exadata:
• Parallel write redo discos e flash: “Faster wins”
• LGWR notificado assim que o primeiro termina
• Bottleneck mitigado: 1 dos I/O subsystem sobrecarregado
Twitter: @failsafeSA
EXADATA – (RE)APRENDER
• OLTP• ESFC
• Percentagem alta para physical I/O (avg wait 0.5ms)
• Escalabilidade: Upgrade half/full rack = 2x CPUs, 2x ESFC
• ESFL
• Write-Intensive workload = LGWR performance
• Datawarehousing
• Smart Scans/Offload
• FTS/IFFS – Direct path: “Run-time decision”:
• Explain Plan é inutil
• Chained Rows – “pass-through mode”
• Hints? “No No No”
• Storage Cells demasiado ocupadas:
• Column projection e Predicate filtering não executados
• Block shipping mode
• “Workaround solution” – “cell physical IO bytes pushed back to excessive CPU”
• Partitioning
• Tamanho interessa!
• To Index or Not to Index• Exadata is different – Thing differently ™
Twitter: @failsafeSA
EXADATA – PERGUNTAS
Twitter: @failsafeSA