CellMetric Tool

Hey guys, it’s been a while since my last post as I’ve been quite busy on the last months at a personal project which could be used to collect some current metrics from a Exadata Storage Server. I got a beta version now, so it’s stills under development but I hope you enjoy this tool. It’s a Java App which was built and tested under ESS image version 12.1.2.1.1.150316.2 and Java version 1.7.0_72 . Java 7.0 is deployed under ESS image version 12.1.2.1.1

Well what this app call CellMetric does is quite simple, it executes CellCLI throw SSH – so Node Equivalency to cellmonitor uses needs to be set correctly -, list the current metrics from the cell that you provided using saving this output to a XML file and then print the results on the screen. That easy. The only attention is that the Database I/O Load Metric information is top ordered listing only the hugest 15 databases. The way how you execute it is java CellMetric -top -cell <cellHostName> . Below you can see an image from the execution time:

CellMetric Image

So just download this CellMetric_v1.2.zip place both file on your Exadata Database Machine and then enjoy it. Cya!!

Storage Exadata: Arquitetura

É isso ai rapaziada! Seguindo com mais um post da série sobre Exadata Database Machine, e pegando uma dica do meu amigo David Siqueira, irei abordar a arquitetura do storage desta máquina. Os servidores que possuem os discos que são apresentados para os bancos que estão no Exadata, possuem atualmente (X5-2) dois tipos a serem escolhidos: Alta Capacidade (High Capacity – HC); ou Extreme Flash (EF). Um servidor com discos de alta capacidade possui doze discos SAS de 10K possuindo 4TB cada um, totalizando 48TB de dado raw, se levarmos em consideração que o diskgroup ficará com a redundância normal, o valor cai para algo em torno de 20TB. O ganho na configuração de extreme flash é quando estamos buscando melhor a escrita no banco, pois pelos dados da Oracle, a escrita pode apresentar o dobro da performance se comparado ao disco de alta capacidade, porém a capacidade de armazenamento do EF cai para 25% em relação ao HC.

Os discos físicos presentes nas controladoras de disco de cada cell node são apresentados como luns ao servidor e baseados nestes que podem ser construídos os cell disks para o software do sistema de storage do Exadata. A visão da controladora de disco é que os discos físicos representam o nível mais baixo de abstração de storage, já para a visão do software do Exadata, os cell disks apresentam o maior nível de abstração de storage dos discos físicos, enquanto que as luns apresentam o menor nível. Seguindo no raciocínio, tendo os cell disks montados, um ou mais grid disks podem ser criados a partir deste, para serem apresentados para a instância do ASM onde enfim serão montados ou adicionados aos diskgroups.

zonebit

 

Os grid disks são montados a partir da faixa (offset) mais “quente” do cell disk, por este motivo que em uma configuração padrão os diskgroups são criados seguindo a ordem de: dados; recuperação; e DBFS. A imagem ao lado ilustra um disco físico, onde as faixas cinzas que estão localizadas na área mais longe do centro do disco, são as que apresentam maior velocidade do disco (hot portion), enquanto que as faixas no tom de salmão possuem menor velocidade (cold portion).

 

Somente a Oracle ACS está autorizada a modificar a estrutura dos cell disks após a entrega da máquina (salvo em casos que exista um acompanhamento via SR no suporte da Oracle). Caso a empresa que adquiriu o Exadata Database Machine altere a estrutura, esta poderá perder o suporte do produto pois a autonomia da empresa para modificar a arquitetura dos discos somente compete a nível dos grid disks em diante. Abaixo segue uma imagem detalhando esta arquitetura desde os discos físicos até os grid disks:

Exadata Storage

O que muda no padrão de adição de grid disks de um ambiente convencional é que, deve-se informar os endereços de IPs (Infiniband 01 e 02) do servidor de storage e o nome dos grid disks que serão apresentados para adicionar ou criar estes nos disk groups, já que na configuração máxima de um Exadata poderá ter até 14 nós de células / servidores de storage (não levando em consideração o Expansion Storage Pack que pode chegar a 19 células). Cada grid disk possui o padrão de nomenclatura como <diskgroup_name>_<cell_disk_type>_<cell_disk_number>_<cell_hostname>. Abaixo estão listados os comandos para listar os discos físicos, lunscell disks e grid disks, e também como adicionar os grid disks aos diskgroups.

physical disk

parted lun

lun

griddisk

SYS@SQL> ALTER DISKGROUP <DISKGROUP_NAME> ADD DISK ‘o/<IP_IB01>;<IP_IB02>/<GRIDDISK_NAME>’;
SYS@SQL> ALTER DISKGROUP DATA ADD DISK ‘o/192.168.10.9;192.168.10.10/DATA_CD_00_exa01cell01’;

Como podemos ver acima, os dois grid disks foram montados utilizando um único cell disk e a partir deste grid disk que conseguimos adicionar ou criar os diskgroups no ASM. Bom galera, espero que tenham gostado e até a próxima. Aquele abraaaaaaaaaaa!!!