Storage tiering é uma funcionalidade que permite que um bloco muito acessado seja movido de uma camada mais lenta para uma mais rápida. Uma camada lenta pode ser um conjunto de discos SATA ou NL SAS, e a camada rápida geralmente é um conjunto de discos SSD.
O Easy Tier é a solução da IBM de storage tiering. Ela foi originada no modelo DS8000 e implementada também no Storwize V7000.
Ele pode trabalhar nos modo manual e automático e, para que possamos utilizá-lo, é necessário que existam pelo menos um MDisk SSD e um não-SSD num mesmo pool. Um Managed Disk (MDisk) pode ser um arranjo de discos do storage ou uma LUN de um storage virtualizado.
Pensando somente no Oracle, se o banco estiver em modo archive é aconselhável colocar o volume dos archives em um pool rápido e sem Easy Tier (SAS 15K ou SSD), pois um bloco novo sempre é alocado inicialmente na camada mais lenta.
No caso dos redos e controlfiles, podemos usar a mesma estratégia adotada para os archives, ou criar volumes pequenos e desabilitar o modo automático, fixando-os no MDisk SSD.
Para os dadafiles, eu observei que mesmo num banco transacional (OLTP) não precisamos usar SAS 15K como camada mais lenta. Isso é possível porque existem muitos blocos que deixam de ser acessados depois de um tempo e, se forem criados bons arranjos (MDisk) NL SAS, não será notada uma perda muito grande de performance se eles passarem a ser acessados novamente.
No entanto, a criação de MDisks e pools vão depender dos sistemas que estão acessando o storage, mesmo porque ele pode estar sendo acessado também por outros sistemas, como VMware, File Server, Exchange, etc.
Falarei mais dessa funcionalidade em outros posts, mostrando inclusive como mover extents (conjunto de blocos) de um MDisk para outro via linha de comando.
Umas das coisas que mais me gerou expectativa na versão 11g foi o Adaptive Cursor Sharing, pois ele resolveria aquele problema relacionado ao Bind Peeking e planos de execução ruins nas versões anteriores.
Eu até fiz um post sobre o Oracle 11g, destacando esse recurso como uma das coisas mais bacanas nessa versão.
Ele funciona bem, mas algumas situações podem desabilitá-lo, como mostra o note ID 740052.1 do MOS.
If any of the following checks fail ECS will be disabled :- – Extended cursor sharing is disabled – The query has no binds – Parallel query is used – Certain parameters like (“bind peeking”=false) are set – You are using a /*+ NO_BIND_AWARE */ hint – Outlines are being used – It is a recursive query – The number of binds in a given sql statement are greater than 14.
O último item é, na maioria dos casos, o que mais desabilita esse recurso.
Se o banco está como parâmetro CURSOR_SHARING=FORCE todos os literais, inclusive o aqueles no SELECT, serão transformados em bind. Portanto, esse limite de 14 binds pode ser ultrapassado facilmente se não tomarmos cuidado.
Outra coisa que desabilita o ECS é a utilização de funções para comparar com os valores dos campos indexados.
Vou tenta explicar isso com dois exemplos bem simples.
Temos duas tabelas com dois campos apenas. Numa tabela o campo DATA é tipo VARCHAR2, e na outra é tipo DATE. Em ambas as tabelas esse campo está indexado.
ORCL>desc teste_acs
Name Null? Type
ID NUMBER
DATA VARCHAR2(8)
ORCL>desc teste_acs_1
Name Null? Type
ID NUMBER
DATA DATE
Executando a query na primeira tabela, sem usar qualquer função de conversão, eu observo que o ECS habilitado ( IS_BIND_SENSITIVE=Y na V$SQL).
ORCL>select /* teste_acs1 */ count(1)
2 from teste_acs
3 where data='20120101';
COUNT(1)
600100
ORCL>select EXECUTIONS, SQL_ID, ADDRESS, CHILD_NUMBER, IS_BIND_SENSITIVE, IS_BIND_AWARE, IS_SHAREABLE
2 from v$sql where sql_text like '%teste_acs1%';
EXECUTIONS SQL_ID ADDRESS CHILD_NUMBER I I I
1 ftuk07cb07890 0700000032799800 0 Y N Y
Agora vou executar a query na outra tabela, mas usando a função TO_DATE para converter uma string.
ORCL>select /* teste_acs1 */ count(1)
2 from teste_acs_1
3 where data=to_date('20120101','YYYYMMDD');
COUNT(1)
600100
EXECUTIONS SQL_ID ADDRESS CHILD_NUMBER I I I
1 01xm3t100jhcu 0700000024493140 0 N N Y
1 ftuk07cb07890 0700000032799800 0 Y N Y
Observem que o campo IS_BIND_SENSITIVE está com o valor N para essa segunda query.
O ECS é desabilitado porque a função faz um sql recursivo. Ele vai precisar fazer algo antes de executar a quey, que nesse caso é uma conversão.
Portanto, podemos concluir que o ACS é bem útil, mas para que ele funcione bem os desenvolvedores precisarão estar cientes de todas essas condições. Uma reunião ou um bate-papo informal com eles evitará ações reativas e reclamações por parte dos usuários.
Para quem não conhece, a package DBMS_ALERT é utilizada basicamente para enviar e receber alertas (mensagens) de forma bem simples.
Seus alertas são baseados em transação, isto é, as sessões em espera só receberão a mensagem depois que a transação do alerta for confirmada (commit).
Apesar dessa package ser bem antiga (introduzida na versão 7), eu resolvi dar uma olhada nela para ver se eu poderia aproveitar em alguma aplicação real.
Para entender o seu funcionamento, vamos abrir duas sessões, uma que enviará a mensagem e outra que receberá a mensagem.
Para receber uma mensagem, usamos a procedure WAITONE (ou WAITANY para diferentes alertas). No entanto, é necessário informar o alerta que voce está esperando através da procedure REGISTER.
ORCL>DECLARE
2
3 mensagem varchar2(4000);
4 status number:=0;
5 ativo boolean := TRUE;
6
7 BEGIN
8
9 DBMS_ALERT.REGISTER('teste_alert_event');
10 DBMS_ALERT.WAITONE('teste_alert_event', mensagem, status);
11 IF status = 0 THEN
12 DBMS_OUTPUT.PUT_LINE(mensagem);
13 END IF;
14
15 END;
16 /
Ao executar o bloco acima, a sessão fica em espera até receber a mensagem.
Na outra sessão, vou enviar a mensagem usando a package SIGNAL, seguida de commit.
O bloco da sessão em espera termina assim que recebe a mensagem (status=0).
ORCL>DECLARE
2
3 mensagem varchar2(4000);
4 status number:=0;
5 ativo boolean := TRUE;
6
7 BEGIN
8
9 DBMS_ALERT.REGISTER('teste_alert_event');
10 DBMS_ALERT.WAITONE('teste_alert_event', mensagem, status);
11 IF status = 0 THEN
12 DBMS_OUTPUT.PUT_LINE(mensagem);
13 END IF;
14
15 END;
16 /
mensagem teste
PL/SQL procedure successfully completed.
No entanto, essa package possui algumas limitações. Se vários alertas forem enviados com uma frequência muita alta, os antigos serão subscritos, mesmo que o commit ocorra logo após o envio do alerta.
Eu consegui contornar esse problema usando a procedure SLEEP da package DBMS_LOCK. Ela provoca um “delay” entre um alerta e outro. No meu caso, um segundo foi o suficiente, mesmo para múltiplos consumidores e publicadores.
BEGIN
FOR i in 1..50 LOOP
DBMS_ALERT.SIGNAL('teste_alert_event', 'mensagem '||i);
COMMIT;
DBMS_LOCK.SLEEP (1);
END LOOP;
END;
Agora vocês devem estar se questionando onde isso poderia ser utilizado.
Bem, a documentação da Oracle mostra um exemplo usando trigger, para enviar um alerta sempre que ocorrer algum evento DML.
Nesse caso, uma aplicação que mostra estatísticas em tempo real poderia ficar sempre a espera de alertas em caso de atualizações em determinadas tabelas.
Eu também fiquei pensando e acho que até um chat poderia ser desenvolvido usando essa package. É bem verdade que existem varias implementações boas no Google, mas vai ser divertido desenvolver um usando ela.
No final de Janeiro, a Oracle migrou a versão HTML do MOS para uma nova desenvolvida com o Oracle ADF. O endereço é http://supporthtml.oracle.com.
Essa versão está mais parecida com a versão em Flash do que a anterior. Mesmo não agradando a todos no começo, temos que admitir que a versão em Flash trouxe muitas funcionalidades ao portal.
Eu já estou usando e até abri um chamado usando essa versão, que por sinal ficou mais simples e rápida (somente três passos em vez de seis).
No geral, acho que a Oracle fez um belo trabalho e em breve a versão em Flash também será substituída por essa.
Este procedimento não é nenhuma novidade, mas resolvi colocar no blog para mostrar que tanto as instalações do Oracle Server e do patchset são possíveis sem a necessidade da interface gráfica.
Se o SO for AIX, o comando para a instalação do patchseet tem que ficar todo numa mesma linha (sem a barra “\”), pois ele vai perguntar se perguntar se o /usr/sbin/slibclean foi executado pelo root. Para os demais SO, pode usar a barra tranquilamente.
Vale lembrar que o sucesso da instalação dessa forma depende da execução de todos os passos que a antecedem, por exemplo, se algum grupo do SO não for criado, a instalação terminará com erro.
Após a criação/upgrade de um banco de dados, um dos procedimentos mais importantes é a alteração das senhas dos usuários padrões do Oracle (CTXSYS, OUTLN, MDSYS, etc).
Na versão 11g, a view DBA_USERS_WITH_DEFPWD facilita o nosso trabalho mostrando quais estão com a senha padrão.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select * from dba_users_with_defpwd;
USERNAME
------------------------------
APPQOSSYS
XS$NULL
XDB
OLAPSYS
MDSYS
EXFSYS
SI_INFORMTN_SCHEMA
SPATIAL_WFS_ADMIN_USR
SPATIAL_CSW_ADMIN_USR
DIP
ORACLE_OCM
WMSYS
ORDSYS
SCOTT
IX
ORDDATA
CTXSYS
ORDPLUGINS
MDDATA
OWBSYS
BI
OUTLN
PM
No começo do mês de julho recebemos um novo servidor IBM Power 7. Decidimos que usaríamos o Power VM em vez de partições físicas devido ao alto custo do HMC.
Para aproveitar todos os recursos dessa nova linha de processadores, decidimos também usar o AIX 7.1. Algumas pessoas diriam que é uma decisão arriscada, pois nenhum chamado tinha sido aberto até o momento na IBM referente a essa nova versão.
Além disso, a única versão homologada para essa versão do AIX é a 11.2.0.2. Logo me lembrei da época em que fiz isso na versão anterior (AIX 6.1 + Oracle 11.1.0.6). Foram necessários muitos patches para estabilizar o sistema, mas valeu à pena.
Após a instalação do VIOS e configuração das partições, a máquina já estava disponível para alguns testes. Como estava ansioso para testar o novo “brinquedo”, já fui botando a mão na massa e iniciando a fase de testes.
O primeiro que fiz foi pegar um backup gerado pelo RMAN de um banco 11.1.0.7, restaurar no novo servidor e fazer o upgrade. Não há novidade nesse procedimento. É possível encontrar milhares de blogs e sites explicando como fazer isso, mas resolvi montar um também devido a alguns detalhes que achei interessante.
Tirando os ajustes requisitados no Installation Guide, o AIX 7.1 está quase que 100% otimizado. A maioria dos parâmetros de tuning são restritos e, assim como os hidden parameters do Oracle, só devem ser alterados se o suporte recomendar.
Antes mesmo de iniciar a instalação apareceu o erro ([INS-13001] Environment does not meet minimum requirements). Como as configurações do SO estavam de acordo com a documentação, fui ao Metalink e achei um note com a solução. Basta chamar o runInstaller usando a flag “-ignorePrereq”, pois o erro ocorre quando o produto é instalado no AIX 7.1.
Como eu disse anteriormente, o restante do teste não tem segredo. Em poucos passos restaurei o banco e fiz o upgrade. Vamos à receita de bolo…
Depois de fazer o FTP dos backup pieces para a nova maquina:
1- Criar um init.ora e iniciar a instancia em modo nomount.
> restore controlfile from '/ora01/app/oracle/fast_recovery_area/OLTP/autobackup/2011_07_29/o1_mf_s_757785772_7360z2ow_.bkp';
3- Alterar o banco para mount.
> alter database mount;
4- Como os diretórios no servidor destino são diferentes da origem, é necessário catalogar os backup pieces. Ex:
> catalog start with '/ora01/app/oracle/fast_recovery_area/OLTP' noprompt;
5- Verificar o ultimo archive gerado que está no rman e restaurar o banco.
run {
set until sequence=210;
set newname for datafile 1 to '/ora01/app/oracle/oradata/OLTP/system01.dbf' ;
set newname for datafile 2 to '/ora01/app/oracle/oradata/OLTP/sysaux01.dbf' ;
set newname for datafile 3 to '/ora01/app/oracle/oradata/OLTP/undotbs01.dbf';
set newname for datafile 4 to '/ora01/app/oracle/oradata/OLTP/users01.dbf' ;
set newname for datafile 5 to '/ora01/app/oracle/oradata/OLTP/users201.dbf' ;
restore database;
switch datafile all;
recover database;
}
6- Antes de abrir o banco, alterar o caminho dos redos. Ex:
>alter database rename file '/u02/oradata/OLTP/redo02.log' to '/ora01/app/oracle/oradata/OLTP/redo02.log';
>alter database rename file '/u02/oradata/OLTP/redo01.log' to '/ora01/app/oracle/oradata/OLTP/redo01.log';
>alter database rename file '/u02/oradata/OLTP/redo03.log' to '/ora01/app/oracle/oradata/OLTP/redo03.log';
7- Abrir o banco usando a clásula “upgrade”.
>alter database open resetlogs upgrade;
8- Antes de iniciar o upgrade, é necessário recriar a tablespace temporária. Ex:
Se uma sessão que estiver executando um create/rebuild online de um índice terminar de forma anormal ou for eliminada, pode ser que o estado desse índice no dicionário de dados permaneça como “rebuild” e na tentativa de recriá-lo novamente, aparecerá o erro ORA-08104.
OLTP>; drop index SCOTT.ix_big_table_02;
drop index SCOTT.ix_big_table_02
*
ERROR at line 1:
ORA-08104: this index object 1008554 is being online built or rebuilt
A solução para esse problema é a função DBMS_REPAIR.ONLINE_INDEX_CLEAN, pois o SMON pode levar um bom tempo até que “limpe” tudo.
DECLARE
RET BOOLEAN;
BEGIN
RET:=DBMS_REPAIR.ONLINE_INDEX_CLEAN (1008554);
END;
Depois disso já é possível recriar ou fazer o rebuild desse indice novamente.
WARNING: Oracle executable binary mismatch detected.
Binary of new process does not match binary which started instance
issue alter system set “_disable_image_check” = true to disable these messages
Nesse dia eu pequei pelo excesso de confiança e esqueci de parar uma instance. A sorte é que ela não é muito importante, mas mesmo assim tive algumas reclamações de ORA-03113.
Entre uma visita e outra em blogs de conhecidos e de gurus do Oracle, achei uma coisa que me chamou a atenção no blog do Tim Hall; o novo Patch Set 11.2.0.2.
Pelo que andei lendo, o patch set chegou a ser removido do MOS, mas acho que resolveram disponibilizar novamente, pelo menos a versão pra Linux.
Além de algumas melhorias, eles resolveram mudar o processo de upgrade, que ficou mais simples e seguro. À partir desta versão teremos agora duas formas para aplicar um patch set:
1- Instalando a versão Full num outro ORACLE_HOME (recomendada). O patch set 11.2.0.2 é um pacote de instalação full e, por isso, não é necessário instalar um base release antes de aplicá-lo.
2- Aplicando sobre uma instalação existente (caso não tenha espaço livre para uma nova). No entanto, a forma como ele é aplicado é diferente das anteriores e, por isso, é necessário ler a documentação antes de fazer o upgrade.
A idéia de instalar todo o produto é bem interessante, pois evita que ocorram erros durante o processo de substituição de arquivos e, dessa forma, facilite o processo de rollback, já que bastaria “apontar” o banco para o antigo OH em caso de falha.
Outra vantagem é poder fazer o upgrade nas bases que compartilham o mesmo OH com mais calma, uma de cada vez. Se você aplica o patch set direto no OH, você acaba tendo que fazer o upgrade em todas as bases de uma só vez.
Caso queiram entender melhor as mudanças, inclusive o que os motivou a fazer isso, acesse o documento 1189783.1 no Metalink.
