Storage Exadata: Protocolo iDB

Salve galera do mal! Eis que estou aqui de volta pra falar mais um assunto da série Storage Exadata. Irei abordar hoje o Intelligent Database Protocol, para os íntimos apenas iDB. Este protocolo é único e somente pode ser encontrado em servidores com storage Exadata e isso não é a toa. O protocolo está implementado no kernel do banco de dados Oracle e foi construído sobre o padrão de indústria RDS (Reliable Datagram Sockets versão 3) e executa sobre a Infiniband ZDP (Zero-Loss Zero-Copy Datagram Protocol) que é uma implementação cópia zero (Zero-Copy) do protocolo RDS, com isso é eliminada a desnecessária cópia de blocos, permitindo maior eficiência na rede.

É graças a este protocolo utilizado em comunicação entre os storage servers e os database nodes que é possível identificar o tipo de I/O que é enviado pelo servidor de banco de dados, por exemplo, seria impossível ter o benefício de cell offloading ou Smart Scan sem este protocolo. Dentro do servidor de storage, estão em execução três principais processos: CELLSRV; Management Server; e Restart Server. Em especial sobre o protocolo iDB, o processo CELLSRV é responsável pelas requisições de I/O efetuadas via iDB para poder efetuar as tratativas inteligentes como o cell offloading.

Foi aqui, no meu ponto de vista, que a Oracle acertou na construção de um hardware que entendesse o que o banco de dados está executando, sem isso nós teríamos apenas servidores ODA (Oracle Database Appliance) no mercado. E é por isso que o Exadata Storage Server é o futuro dos Engineered Systems e será muito difícil novos hardwares tomarem o seu lugar. Pois hardware e inteligência em infraestrutura todo mundo consegue copiar ou aprimorar muito rápido, porém software demora um pouco mais. Galera vou ficando por aqui, aquele abraaaaaaaa.

Anúncios

Overload em Pacotes

Salve, salve, pessoal! Hoje passando por aqui para deixar um post que trata do assunto de Overload em subprogramas nos banco de dados Oracle. Esta técnica é mais conhecida pelos desenvolvedores de PL/SQL e serve para viabilizar a interação do usuário com a chamada de uma função ou procedure dentro de um pacote. Sendo assim, um pacote que encontra-se “sobrecarregado” possui a características de permitir o usuário efetuar a chamada sem necessitar estar amarrado a um tipo de dado.

Alguns pacotes nativos do Oracle possuem essa característica e nós nem nos demos conta. Você já parou para perceber que quando você executa a instrução DBMS_OUTPUT.PUT_LINE(VAR_01) , você nunca liga para o tipo de dado que será colocado na variável VAR_01. Se será um número, uma string ou uma data? Imagine que para um mesmo código, você quer dar a possibilidade ao usuário de efetuar a chamada passando um único parâmetro que pode ser numérico, caracter, LOB ou até mesmo um boolean. É para isso que serve o Overload.

O exemplo que irei exibir é bem simples, portanto, no código abaixo será criado o pacote sobrecarga com os procedimentos execucao que escreverá o valor na tela, referente a cada tipo de chamada. Vejamos abaixo:

pack.sobrecarga

packbody.sobrecarga

sobrecarga.execucao

Percebam que as variáveis declaradas em cada um dos procedimentos são diferentes, assim como os códigos que estão dentro destes. Isso foi feito propositalmente, até mesmo para exemplificar melhor para vocês. Quando forem criar códigos como este, entendam também que existem algumas restrições no uso, entre estas:

  • Subprogramas Standalones não podem ser configuradas, porém você pode utilizar de overload em uma rotina declarada dentro de um bloco PL/SQL anônimo;
  • Subprogramas que diferem somente pelo modo, ou seja, você não pode criar um subprograma com um mesmo tipo porém em um é entrada e no outro saída;
  • Subprogramas com subtipos diferentes, ou seja, um subprograma com overload não pode possuir uma chamada com uma variável do tipo integer e outra real;
  • Subprogramas que diferem somente no tipo de retorno;

Se estas premissas forem cumpridas, você terá configurado com êxito o seu código. Esta técnica pode ser utilizada também em blocos agrupados e métodos de tipo. Bom pessoal, por hoje é só! Aquele abraaaaaaaaaa!

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!!!