Métodos de Joins no Oracle Parte I

Depois muito tempo sem freqüentar e atualizar o blog , neste ano pretendo ser mais ativo na comunidade ,tendo tirado o ano passado para novas experiências profissionais infelizmente não tive tempo de aparecer por aqui, porém agora podem esperar novas atualizações.
E volto falando de um assunto que sempre me perguntam que é como o oracle realiza joins com mais de uma tabela.

NESTED LOOPS (Loops aninhados)
Definição
Os registros da primeira tabela são recuperados, e para cada registro recuperado, o acesso é realizado na segunda tabela.
NESTED LOOPS são úteis quando pequenos subconjuntos de dados estão sendo juntados, e se a condição de join é uma forma eficiente de acesso à segunda tabela.
O acesso da segunda tabela é feito através de um acesso baseado em índice (index-based access).

Um hint é usado para recomendar um acesso baseado em índice da tabela Livros no exemplo abaixo:

select /*+ INDEX(Livros) */
Livros.Publisher,
Livros_autor.AuthorName
from Livros, Livros_autor
where Livros.Title = Livros_autor.Title;

A coluna title da tabela Livros é utilizada como parte da condição de join na consulta, o índice de chave primária pode resolver esse join.
Quando a consulta é executada, uma operação de NESTED LOOP pode ser usada para executar esse join.
Para executar um join de NESTED LOOP, o otimizador deve primeiro selecionar uma tabela de condução da junção, que é a tabela que será lida primeiro (geralmente através de uma operação de TABLE ACCES FULL, embora index scans sejam muito utilizados). Para cada registro na tabela de condução, a segunda tabela na junção será consultada. A consulta de exemplo junta as tabelas Livros_autor e Livros, com base nos valores da coluna de title. Durante a execução de NESTED LOOPS, uma operação irá selecionar todos os registros da tabela Livros_autor. O índice de chave primária da tabela Livros será investigado para determinar se ele contém uma entrada para o valor do registro atual da tabela Livros_autor. Se uma correspondência for encontrada, então o valor de Title será retornado da chave primária de Livros. Se outras colunas são necessárias para Livros, a linha será selecionada da tabela Livros através de uma operação de TABLE ACCESS BY INDEX ROWID.

Então podemos resumir que um NESTED LOOP envolve as seguintes etapas:

1_ O otimizador determina a tabela de condução e designa-o como uma tabela externa.
2_ A outra tabela é designada como a tabela interna.
Para cada linha na tabela externa, o Oracle permite acesso a todas as linhas na tabela interna.

O outer loop é para cada linha na tabela externa e o inner loop é para todas as linhas na tabela interna.
O outer loop aparece antes do inner no plano de execução, como segue:

Agora vamos mostrar o plano de execução desta consulta para esclarecer a sua mente.

EXPLAIN PLAN FOR
SELECT e.employee_id, j.job_title, e.salary, d.department_name
FROM employees e, jobs j, departments d
WHERE e.employee_id < 103
AND e.job_id = j.job_id
AND e.department_id = d.department_id;
-----------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 165 | 4 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 3 | 165 | 4 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 3 | 123 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 3 | 48 | 2 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | EMP_EMP_ID_PK | 3 | | 1 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| JOBS | 1 | 25 | 1 (0)| 00:00:01 |
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
|* 6 | INDEX UNIQUE SCAN | JOB_ID_PK | 1 | | 0 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | DEPARTMENTS | 1 | 14 | 1 (0)| 00:00:01 |
|* 8 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | 0 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("E"."EMPLOYEE_ID"<103)
6 - access("E"."JOB_ID"="J"."JOB_ID")
8 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
Neste outro exemplo, o outer loop recupera todas as linhas da tabela de employees.
Para cada linha da tabela employees recuperada pelo outer loop, o inner loop recupera a linha associada na tabela jobs.

Outer loop
Nesse exemplo a consulta abaixo seria equivalente ao que o outer loop executa com uma tabela de conducao.
SELECT e.employee_id, e.salary
FROM employees e
WHERE e.employee_id < 103;

Inner loop
O plano de execução mostra o inner loop sendo iterado para cada linha obtida
a partir do outer loop, como segue:
SELECT j.job_title
FROM jobs j
WHERE e.job_id = j.job_id ;

É muito importante garantir que a tabela interna é conduzida a partir da da tabela externa.
Se o caminho de acesso a tabela interna é independente da tabela externa e em seguida as mesmas linhas são recuperadas para cada iteração de outer loop o desempenho vai cair consideravelmente.
Em tais casos, operaçoes de *hash joins juntam duas fontes independentes com um melhor desempenho.

*Hash join será abordado brevemente

Em operações de acesso a pelo menos duas fontes de dados que estão envolvidos joins com um NESTED LOOPS, vai ocorrer um acesso na tabela de condução(tabela principal) e um acesso normalmente baseado em índice da tabela dirigida .
Os métodos de acesso de dados mais comuns usados são o TABLE ACCESS FULL, TABLE ACCESS BY INDEX ROWID e INDEX-SCAN eles retornam os registros para às operações sucessivas logo que um registro for encontrado, eles não esperam por todo o conjunto de registros selecionados. Porque essas operações podem fornecer o primeiro conjunto de linhas rapidamente para os usuários, Nested Loops são comumente usados para joins que são freqüentemente executados por usuários online.
Ao implementar joins com NESTED LOOPS, você precisa considerar o tamanho da tabela de condução. Se a tabela de condução é grande e é lida através de um FULL TABLE SCAN, então o FULL TABLE SCAN realizado pode afetar negativamente o desempenho da consulta. Se os índices estão disponíveis em ambos os lados do join o Oracle vai selecionar uma tabela de condução para a consulta e o otimizador irá verificar a estatísticas do tamanho das tabelas e a *seletividade dos índices para escolher o caminho com o menor custo global.

* A seletividade é um valor entre 0 e 1 que representa a fração de linhas filtradas por uma operação.
Por exemplo, se uma operação de leitura lê 120 linhas de uma tabela e depois de aplicar um filtro(where) retorna 18 linhas, a seletividade é de 0,15 (18/120). A seletividade também pode ser expressa como um percentual de 0,15 que é expresso como 15 por cento.

Ao juntar três tabelas, o Oracle realiza dois joins distintos: O join de duas tabelas para gerar um conjunto de registros e em seguida um join entre o conjunto de registros e a terceira tabela.
Se NESTED LOOP são utilizados a ordem na qual as tabelas são unidas é crítica.
A saída do primeiro join gera um conjunto de registros e esse conjunto de registros é usado como uma tabela de condução da segunda junção.
O Tamanho do conjunto de registros retornado pelo primeiro join impacta no desempenho do segundo join e assim tem um impacto significativo sobre o desempenho da consulta geral. Você deve tentar unir as tabelas mais seletivas primeiro para que o impacto desses proximos joins sejam insignificantes.
Se tabelas grandes sao unidas no primeir join de uma consulta multijoin, o tamanho das tabelas terá um impacto sucessivos no join e irá impactar negativamente o desempenho global da consulta.
O otimizador deve escolher o caminho adequado para executar o join ,você pode confirmar os custos e o caminho gerado pelo plano de execução.
NESTED LOOPS são úteis quando se criam joins com tabelas de tamanhos diferente assim você pode usar a menor tabela como a tabela de condução e selecione na tabela maior com um acesso baseados em índices.
Quanto mais seletivo o índice, mais rápido a consulta será concluída.

Um join com quatro Tabelas

O plano de execução que se segue é um exemplo de uma árvore típica de profundidade à esquerda, implementado com NESTED LOOP .
Observe como cada tabela é acessada por meio de índices.
O exemplo também mostra como forçar um loop aninhado usando hints ordered e use_nl.
O exemplo especifica o acesso as tabelas na mesma ordem em que aparecem na cláusula FROM.
O último especifica qual método join é usado para juntar as outras tabelas para a primeira tabela .

SELECT /*+ ordered use_nl(t2 t3 t4) */ t1.*, t2.*, t3.*, t4.*
FROM t1, t2, t3, t4
WHERE t1.id = t2.t1_id
AND t2.id = t3.t2_id
AND t3.id = t4.t3_id
AND t1.n = 19;
-------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 238K| 1218 (1)| 00:00:15 |
| 1 | NESTED LOOPS | | 1000 | 238K| 1218 (1)| 00:00:15 |
| 2 | NESTED LOOPS | | 100 | 18000 | 116 (0)| 00:00:02 |
| 3 | NESTED LOOPS | | 10 | 1180 | 12 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| T1 | 1 | 57 | 2 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | T1_N | 1 | | 1 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID| T2 | 10 | 610 | 10 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | T2_T1_ID | 10 | | 0 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | T3 | 10 | 620 | 11 (0)| 00:00:01 |
|* 9 | INDEX RANGE SCAN | T3_T2_ID | 10 | | 1 (0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID | T4 | 10 | 640 | 11 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | T4_T3_ID | 10 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - access("T1"."N"=19)
7 - access("T1"."ID"="T2"."T1_ID")
9 - access("T2"."ID"="T3"."T2_ID")
11 - access("T3"."ID"="T4"."T3_ID")

O Processamento deste tipo de plano de execução pode ser resumido da seguinte forma

1.A primeira linha é obtida , não quando a consulta é analisada ou executada, o processamento começa por obter a primeira linha que atende o filtro t1.n = 19 da tabela t1.
2.Com base nos dados encontrados na tabela t1, a tabela t2 é procurada. Perceba que o Oracle aproveita a condição do join t1.id = t2.t1_id para acessar a tabela t2. Na verdade, nenhuma restrição é aplicada a essa tabela. Apenas a primeira linha que atende a condição do join é restituída à operação principal.
3.Com base nos dados encontrados na tabela t2, a tabela t3 é procurada. Também neste caso, o oracle tira proveito de uma condição de join, t2.id = t3.t2_id, para acessar a tabela T3. Apenas a primeira linha que preenche a condição de join é devolvida para a operação pai.
4.Com base nos dados encontrados na tabela t3, a tabela t4 é procurada. Aqui novamente o Oracle se aproveita de uma condição de join, t3.id = t4.t3_id, para acessar a tabela T4. A primeira linha que cumpre a condição de join é imediatamente devolvida ao cliente.
5.Quando as linhas subseqüentes são buscadas, as mesmas ações são realizadas para as buscar as seguintes.

Obviamente, o processo é reiniciado a partir da posição do ultimo resultado (que poderia ser a segunda linha que corresponde na tabela t4, se houvesse). É essencial destacar que os dados são devolvidos assim que uma linha que atende à solicitação é encontrada. Em outras palavras, não é necessária à plena execução do join antes de retornar a primeira linha.
No próximo post eu vou abordar como os MERGE JOIN são realizados.

Manutenção em Tabelas no MySQL - Parte II

Continuando o post anterior hoje vou falar das ferramentas utilizadas para a manutenção de tabelas do MySQL.

CHECK TABLE

A instrução CHECK TABLE executa uma verificação de integridade de conteúdo e estrutura da tabela. Ele funciona para tabelas MyISAM e InnoDB,ARCHIVE, and CSV. Para tabelas MyISAM, ele também atualiza as estatísticas de índice. Se a tabela é uma view, CHECK TABLE verifica a definição da view. Se a saída de CHECK TABLE indica que uma tabela possui problemas, a tabela deve ser reparada.

mysql> check tables action;

+---------------------+-------+----------+----------+

| Table | Op | Msg_type | Msg_text |

+---------------------+-------+----------+----------+

| qb3_migracao.action | check | status | OK |

+---------------------+-------+----------+----------+

1 row in set (15.93 sec)

Para maiores informações consulte o link :

http://dev.mysql.com/doc/refman/5.5/en/check-table.html

REPAIR TABLE

O REPAIR TABLE corrige problemas em uma tabela que foi corrompida.

Ele só funciona para tabelas MyISAM,ARCHIVE, and CSV.

Para executa-lo é necessário ter privilégios de Select e insert sobre a tabela.

È extremamente importante antes de executar um repair table, que seja feito um backup dos dados.

Se o servidor falhar durante a execução do REPAIR TABLE, é essencial depois de reiniciá-lo de que você execute imediatamente outro REPAIR TABLE na tabela antes de executar quaisquer outras operações sobre ela. Na pior das hipóteses, você pode ter um novo arquivo de índice limpo sem informações sobre o arquivo de dados e, em seguida, a próxima operação de executar poderia substituir o arquivo de dados. Este é um cenário improvável, mas possível que ressalta o valor de fazer um backup primeiro.

Obs: O Comando Repair table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.

Maiores informações acesse :

http://dev.mysql.com/doc/refman/5.5/en/repair-table.html

ANALYZE TABLE

O ANALYZE TABLE atualiza a tabela com as informações sobre a distribuição das chaves da tabela. Essas informações são usadas pelo optmizador para fazer melhores escolhas sobre os planos de execução das consultas SQL.

Para executa-lo é necessário ter privilégios de Select e insert sobre a tabela.

Obs: O Analyze table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.

O MySQL utiliza a distribuição de chaves para decidir a ordem em que as tabelas devem ser unidas quando você executar um join em alguma coisa que não seja uma constante. Além disso, a distribuição das chaves podem ser usadas para decidir quais os índices de uma tabela será utilizado dentro de uma consulta.

mysql> analyze table action;

+---------------------+---------+----------+----------+

| Table | Op | Msg_type | Msg_text |

+---------------------+---------+----------+----------+

| qb3_migracao.action | analyze | status | OK |

+---------------------+---------+----------+----------+

1 row in set (0.00 sec) 

Maiores informações acesse :

http://dev.mysql.com/doc/refman/5.5/en/analyze-table.html

OPTIMIZE TABLE

A instrução optimize table efetua a desfragmentação de uma tabela MyISAM. Ela recupera o espaço não utilizado, causado pela fragmentação das operações delete e update. Optimize table table classifica as paginas e as estatisticas do indices.

Optimize table também funciona em tabelas innodb, porém não efetua a desfragmentação das tabelas, para isso é necessario que se execute um ALTER TABLE nome_da_tabela engine=innodb;

È interessante ressaltar que essa operação é extremamente custosa, bloqueia as tabelas, e se for feita em produção, é necessario que seja realizado em um horário que que não seja o de pico.

Obs: O optimize Table por default escreve no log binario e se for um servidor master de uma replicação, vai replicar a instrução para todos os slaves, então nesse caso é necessario que se rode a opção NO_WRITE_TO_BINLOG.

mysql> OPTIMIZE TABLE action;

+---------------------+----------+----------+----------+

| Table | Op | Msg_type | Msg_text |

+---------------------+----------+----------+----------+

| qb3_migracao.action | optimize | status | OK |

+---------------------+----------+----------+----------+

1 row in set (0.04 sec)

Maiores informações acesse :

http://dev.mysql.com/doc/refman/5.5/en/optimize-table.html

Agora que falei das ferramentas vou mostrar uma procedure para automatizar esses recursos:

A procedure abaixo realiza um optimize em todas as tabelas do banco que você especificar, e dependendo da sua demanda você pode transforma-la em um evento do mysql, ou ainda criar um script para chama-la de tempo em tempo.

DELIMITER &&

CREATE PROCEDURE OPTIMIZE_TABLES()

BEGIN

DECLARE v_nome_table varchar(60);

DECLARE done INT DEFAULT 0;

DECLARE cur1 CURSOR FOR select table_name from information_schema.columns where table_schema='NOME_DO_BANCO' ;

DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;

OPEN cur1;

REPEAT

FETCH cur1 INTO v_nome_table;

IF NOT done THEN

SET @v_comando := concat("OPTIMIZE TABLES nome_do_banco.", v_nome_table, ";");

PREPARE stmt FROM @v_comando;

EXECUTE stmt;

DEALLOCATE PREPARE stmt;

end if;

UNTIL done END REPEAT;

CLOSE cur1;

END

&&

DELIMITER ;

Manutenção em Tabelas no MySQL - Parte I

Hoje eu vou falar sobre operações que fazem parte da vida de um DBA MySQL, que são as manutenções de tabelas, que é um processo extremamente necessário para o desempenho e integridade do seu banco de dados, dividi esse assunto em dois posts no qual vou explicar cada processo de manutenção com suas suas devidas observações e scripts para automatizar esse processo.

Manutenção nas tabelas do mysql são necessarias para identificar e corrigir problemas de integridade, ocasionados por diversos fatores como bugs, problemas no disco e no servidor e também para fornecer mais velocidade ao MySQL, veremos o porquê, a seguir os tipos de manutenção que podemos realizar: 

• A Ferramenta check realiza uma verificação de integridade para se certificar de que a estrutura da tabela e o conteúdo não têm problemas. Esta operação poderá ser realizada em tabelas MyISAM e InnoDB. 

• A Ferramenta repair corrige problemas de integridade para restaurar a tabela para um estado conhecido utilizável. Esse comando só tem suporte para tabelas MyISAM. 

• A Ferramenta analyze, atualiza as estatísticas sobre a distribuição dos valores de índice de chave. Esta é uma informação que o otimizador pode usar para gerar melhores planos de execução para consultas sobre as tabelas .Esse comando pode ser feito tanto em tabelas MyISAM como em tabelas InnoDB. 

• A Ferramenta optimize reorganiza uma tabela para que seu conteúdo pode ser acessado de forma mais eficiente. Esse comando pode ser feito em tabelas MyISAM ,InnoDB e Archive, mas com limitações que variam entre essas storages engines. 

As Ferramentas analyze e optimize são operações que você pode executar periodicamente para manter suas tabelas com sua melhor performance:

• Quando o MySQL analisa uma tabela MyISAM ou InnoDB, ele atualiza as estatísticas de índice. O otimizador usa essas estatísticas ao processar consultas para tomar melhores decisões sobre a melhor forma de procurar registros na tabela e na ordem em que ele precisa ler tabelas em um join.
• Quando o MySQL Otimiza uma tabela MyISAM, ele desfragmenta o datafile para recuperar o espaço não utilizado, classifica os índices e atualiza as estatísticas de índice. Periódicamente a desfragmentação é necessária para acelerar o acesso as tabelas que contêm colunas de comprimento variável como VARCHAR, VARBINARY, BLOB, ou TEXT. Inserções e exclusões podem resultar em muitas lacunas em tais tabelas, particularmente aqueles que são modificados com freqüência. Desfragmentando elimina essas lacunas.

No próximo post vou falar detalhadamente das ferramentas, com exemplos e scripts de automação.

 

Configurando Replicação Semi – Sincronizada no Mysql

    Hoje vou explicar como configurar uma replicação semi sincornizada no mysql, no post Replicação Semi Sincornizada eu expliquei o que era essa nova feature do mysql , e as vantagens dela em relação a replicação normal contida na versão 5.1 e anteriores.
    Na realidade demorei para publicar esse post, porque não podia falar dela sem testa-la, eu precisei configura-la em uma ambiente de produção web, e após 2 meses a replicação se encontra totalmente estavél. Com a segurança de um ambiente de produção de um grande portal, com mais de 300 consultas por segundo, vou explicar agora como configurar a replicação semi sincronizada
utilizando o mysql 5.5.3.

Meu cenário foram de 3 servidores com o mysql 5.5.3 em uma rede Gigabyte, utilizando o CentOS 5.5.

A Primeira coisa a ser realizada é a instalação dos plugins necessários.

Os plugins da replicação semi-síncronizada já estão incluídos com a distribuição MySQL. Atualmente, os plugins só estão disponíveis para Linux. Em outras plataformas são ainda não é suportado.

No master instale o seguinte plugin:

semisync_master.so

mysql >; INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

No Slave instale o seguinte plugin:

semisync_slave.so

mysql >; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

Caso na hora da instalação do plugin , ocorra o erro abaixo :

ERROR 1126 (HY000): Can't open shared library
'/usr/local/mysql/lib/plugin/semisync_master.so' (errno: 22 libimf.so: cannot open
shared object file: No such file or directory)

Será necessário o download da libmf em :
http://dev.mysql.com/downloads/os-linux.html.


Para verficar os plugins instalados você pode dar um show plugins ou ainda efetuar a consulta SELECT * FROM  INFORMATION_SCHEMA.PLUGINS.

Após a instalação os plugin são ativados por default, é importante a instalação dos plugins tanto no master quanto no slave, caso contrario a replicação será assincrona.

Configuração no Master

No banco master é necessário a configuração das seguintes variaveis no arquivo de configuração do Mysql (Quando instalado em distribuições rpm, fica localizado em /etc/my.cnf)

Entre os servidores que compoem o esquema de replicação, cada servidor deve possuir um id único, o id do servidor é estabelecido pelo parâmetro :

--server-id=x ( Onde x é o id do servidor)

Caso ocorra duplicação desse valor entre os servidores, ocorrera problemas na replicação.

Habilite a Replicação Semi-Sincronizada com as variaveis:

rpl_semi_sync_master_enabled=1
Essa variavel determina o tempo de resposta do slave ( Maiores informações leia meu post sobre replicação semi sincronizada)

rpl_semi_sync_master_timeout=10
O Log binário deve estar habilitado no master porque o log binário é a base para o envio de dados das alterações do master para seus escravos. Se o log binário não estiver habilitado, a replicação não será possível.

Exemplo
log-bin     =     /var/lib/mysql/mysql-bin-database-01.log
log-bin-index = /var/lib/mysql/mysql-bin-database-01.log.index

Para uma maior durabilidade e consistência possível em uma configuração de replicação usando InnoDB com transações, configure as seguintes variaveis:

usar innodb_flush_log_at_trx_commit = 1
sync_binlog = 1

Para estabelecer que a replicação ocorra para um unico banco utilize a varivavel a seguir:

binlog-do-db = nome_do_banco

Para estabelecer o numero de dias de vida dos logs binários utilize a seguinte variavel :

expire_logs_days = (número de dias)

Configuração no Slave

Configure o id do servidor com :

--server-id=x ( Onde x é o id do servidor)

Habilite a replicação semi sincronizada
rpl_semi_sync_slave_enabled=1

Configure o Relay Log

O relay log consiste em ler os eventos do log binário do master e escrito pela  thread de I/O do Slave. Eventos no relay log são executadas no slave, como parte da linha SQL.

Exemplo:
relay-log=relay-bin-server2

Obs: Após as alterações no arquivo de configuração my.cnf é necessário o restart do mysql.

Crie um usuário para a Replicação

È necessário que você crie um usuário no servidor master, com permissão de acesso das outros servidores presentes na arquitetura de replicação
Esse usuário precisa de grant de replicação.

Use esse comando para conceder grant ao usuário.

GRANT REPLICATION SLAVE ON *.* TO 'user'@'%';

Verifique a necessidade de segurança do seu banco de dados, para verificar os privilégios adequado a esse usuário.


Ativando a Replicação.

Se você seguiu todos os passos corretamente nesse momento o master já esta registrando gerando as informações no log binário, então agora é o momento de ligar a replicação.
Existe duas formas de ligar a replicação, uma é atraves de variaveis do my.cnf, outra é com o comando change master to, por considerar o comando change master to mais seguro escolhi essa opção:

No master execute o comando:

Show master status;
Você deve ter uma resposta parecida com essa:
mysql> show master status;
+------------------+-----------+--------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.000005 | 153469228 | qb3_migracao |                  |
+------------------+-----------+--------------+------------------+

No slave execute o seguinte comando :

use as informações obtidas no comando show master status;

 CHANGE MASTER TO
         MASTER_HOST='nome_do_servidor_master',
         MASTER_USER='usuario_para_replicacao',
         MASTER_PASSWORD='senha_do_usuario',
         MASTER_LOG_FILE='nome_do_log_binario',
         MASTER_LOG_POS=0;
Agora execute o comando:

mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

Pronto , você acabou de configurar uma replicação semi sincronizada no Mysql.

Para verificar o status execute o comando:

show slave status\G;

Verifique no log do servidor slave as seguintes linhas:

 [Note] Slave I/O thread: Start semi-sync replication to master 'slave-01@qb-database-main-01:3306' in log 'mysql-bin.000005' at position 001

Embora a versão 5.5 do mysql ainda não seja uma versão  Generally Available (GA) ,
hoje tenho servidores em produção com essa versão e tenho obtido ganhos relavantes a versão  5.1, e a feature  replicação semi sincronizada , é uma das que mais tem me agradado, é mais segura , eu acompanho via log qualquer problema que possa ocorrer.

Nos proximos posts , irei abordar sobre as novas features do innodb.

Abraços !

A Luz no fim do túnel ... no Oracle

Perdeu os archives ???
Perdeu o backup ???
Não tem mais jeito ???
Demissão ???

È pessoal pode ser que ainda exista a última esperança.

_allow_resetlogs_corruption = true

Com esse parametro no spfile, pode ser que  o banco abra resetando os logs , ai você recupera os dados e reza, mas raza muito pra ninguém descobrir o que realmente aconteceu.

Bem não preciso nem dizer que esse é um parâmetro não documentado, que a chance de dar errado é grande, e se você ferrou seu ambiente de produção pra testar se ele funciona, boa demissão!!!

Sem brincadeiras, já testei o parâmetro em um ambiente de testes, fiz o backup, deletei todos os archives e exclui alguns datafiles, acrescentei ele no spfile e dei um alter database open resetlogs e ele subiu.

Já presenciei outra situação na qual ele também funcionou, mas espero que nem eu nem vocês nunca tenham que usá-lo pra valer.
Abraços!!

Cache Hit Ratio Oracle

A Buffer Cache é um recurso compartilhado, acessível por todos os usuários.
Quando um usuário emite uma consulta , O Oracle antes de ir nos datafiles buscar os blocos necessários para retornar o resultado, primeiro olha para os blocos de dados na buffer cache.
Se os dados colocados no cache são retornados para o solicitante imediatamente .
Ocorre o famoso Hit Ratio .
Quando os dados não forem encontrados, um cache miss ocorre e o processo do usuário irá lêr os dados do disco para um buffer disponível no cache.
A taxa de acerto do cache é a percentagem total de solicitações de dados que são servidos diretamente a partir da buffer cache.
No Oracle, o buffer cache hit ratio normalmente é calculado utilizando a seguinte fórmula:
Cache Hit Ratio = 100 * (1 - leituras físicas / lógicas leituras)
Nesta fórmula, "leituras físicas", corresponde à falta de cache e 'leituras lógicas "corresponde ao total de solicitações de dados.
Ajustando o buffer cache para optimizar o desempenho normalmente ocorre a adição de buffers no cache até que a taxa de acerto foi maximizada.
O número de buffers no cache é especificado pelo parâmetro de inicialização DB_BLOCK_BUFFERS.
Abraços !!

Tempo de Recuperação e outros parâmetros no Oracle

Fala Pessoal,
A visão V$Instance_Recovery merece destaque nesse assunto, as principais colunas são:
recovery_estumated_ios - > O número de operações de i/o nos datafiles que seriam necessárias para a   recuperação se a instância falhasse.
actual_redo_blocks - > O número de blocos de redo do sistema operacional que se precisariam ser aplicados aos datafiles para a recuperaçõ se a intância falhasse agora.
estimated_mttr - > O número de segundos necessários para abrir o banco de dados caso ele falhasse agora.
writes_mttr -> O número de vezes que o DBWn teve de gravar, além das gravações que ele normalmente faria, para atingir a meta do mttr.
Enfim uma mão na roda......