Se o seu banco de dados passa por constantes operações de “DELETE” ou “UPDATE” ele provavelmente ficará fragmentado, fazendo com que os índices já não sejam tão eficientes como antes e os datafiles ocupem mais espaço do que o necessário em disco. Seria, algo similar a fragmentação de filesystem.

Através do catalogo do MySQL é possível identificar quanto espaço livre existe no datafile e assim identificar uma margem ou porcentagem de fragmentação por objeto. Até a versão 5.1.21 essa margem era descrita através da coluna “TABLE_COMMENT” da tabela “INFORMATION_SCHEMA.TABLES”, sendo assim bastava executar a seguinte consulta:

SELECT table_schema,
table_name,
table_comment
FROM information_schema.tables
WHERE engine LIKE 'InnoDB'
AND table_comment RLIKE 'InnoDB free: ([0-9]{6,}).*';

Da versão 5.1.28 em diante isso foi corrigido, sendo possível avaliar a …

Com o constante uso do banco de dados, operações como “delete” e “update”  acabam causando a fragmentação dos objetos nos datafiles, e isso muitas vezes prejudica a performance do banco de dados e aloca espaço desnecessariamente. Com isso torna-se necessário implementar uma rotina de manutenção capaz de otimizar o ambiente, evitando o uso de espaço desnecessário e desfragmentando os índices da tabela para uma melhor performance.

Geralmente isso é feito manualmente ou através de shell scripts, mas preferi criar um “PROCEDURE” e implementar uma rotina via “SCHEDULE” próprio MySQL, segue:

#
use mysql;
#
# TABELA DE LOG PARA MONITORAR O PROCESSO
DROP TABLE IF EXISTS mysql.mantained_table_history;
CREATE TABLE mysql.mantained_table_history(
mantained_table_schema  VARCHAR(255),
mantained_table_name VARCHAR(255),
mantained_type  VARCHAR(255),
mantained_status VARCHAR(10),
mantained_date …

É possível analisar o tamanho dos objetos do banco de dados através do catalogo do Innodb, mas para que essas informações sejam precisas, as estatisticas devem estar atualizadas!

Veja como atualizar as estatisticas no post:

http://mathiasbrem.com.br/update-statistics-mysql-innodb/

http://mathiasbrem.com.br/rotina-analyze-automatizada-via-schedule-mysql/

A consulta a seguir ajuda a avaliar o tamanho dos objetos do banco de dados:

select
INNODB_SYS_TABLESTATS.NAME,
INNODB_SYS_TABLESTATS.NUM_ROWS,
concat(round(((INNODB_SYS_TABLESTATS.CLUST_INDEX_SIZE+OTHER_INDEX_SIZE) * round(INNODB_SYS_TABLESPACES.PAGE_SIZE/1024,0)) / 1024 / 1024, 2),'G') AS TOTAL_SIZE, …

¿Qué pasa?

Simples! Atualização de estatistas do MySQL

Os bancos de dados utilizam estatísticas para definir seus planos de acesso aos dados e assim executar o caminho mais eficiente na busca pelos dados solicitados por determinada consulta. Para isso o banco de dados deve manter suas estatísticas sempre atualizadas. Por padrão o InnoDB já realiza essa atualização automaticamente, evitando que haja qualquer tipo de problema de performance por falta de informações de acesso.

Essa atualização forçada ou automatizada é controlada pela variável:

innodb_stats_persistent

Mais informações a respeito dessa configuração estão disponiveis em:

http://dev.mysql.com/doc/refman/5.6/en/innodb-persistent-stats.html

Ok, …

Como verificar a existência de locks no ambiente ?

SELECT
*
FROM
information_schema.processlist
WHERE
state IN ('Waiting for table flush' , 'Locked', 'Table lock')
OR state REGEXP 'Waiting for .* lock'
ORDER BY time DESC

E como identificar as consultas ou sessões que estão realizando o lock?

SELECT
TRX.TRX_MYSQL_THREAD_ID,
TRX.TRX_ISOLATION_LEVEL,
TRX.TRX_STARTED,
TRX.TRX_STATE,
PROCESSLIST.USER,
PROCESSLIST.HOST,
PROCESSLIST.DB,
PROCESSLIST.COMMAND,
PROCESSLIST.TIME,
PROCESSLIST.STATE,
LOCK_WAITS.REQUESTING_TRX_ID,
LOCK_WAITS.BLOCKING_TRX_ID,
LOCK_WAITS.BLOCKING_LOCK_ID
FROM
INFORMATION_SCHEMA.INNODB_LOCKS LOCKS,
INFORMATION_SCHEMA.INNODB_TRX TRX,
INFORMATION_SCHEMA.PROCESSLIST PROCESSLIST,
INFORMATION_SCHEMA.INNODB_LOCK_WAITS LOCK_WAITS
WHERE
LOCKS.LOCK_TRX_ID = TRX.TRX_ID
AND TRX.TRX_MYSQL_THREAD_ID = PROCESSLIST.ID;

Existem 2 motivos pelos quais fariam você ler esse artigo, o primeiro é por simplesmente obter novos conhecimentos caso você ainda não conheça a ferramenta e o segundo por tentar de forma frustrada recuperar tabelas innodb e não obter sucesso! Se o seu caso é a segunda opção, calma! Você vai conseguir recuperar os dados, pode demorar um pouco mas vai! Pelo menos esse método de recuperação nunca falhou comigo!

Agora vamos ao que interessa: ( E calma, faça tudo com calma! Leia, entenda e planeje as coisas com calma! nessas horas não adianta ter pressa, o correto seria ter rotinas de backup apropriadas e ambientes de contingência, se você não tem nada disso não adianta ter pressa agora, repetindo… é hora de ter calma! HAHAHAHA )

O que é o Percona Data Recovery Toolkit e quando devo utilizar?

Uma ferramenta de “Recovery” desenvolvida e mantida pela equipe da Percona de forma “Open …

Uma das mais importantes configurações para quem usa InnoDB é o innodb_buffer_pool_size, ele basicamente armazena dados e índices em memória, quando o MySQL recebe uma query e as paginas que contem o resultado da pesquisa/índice estao armazenadas no buffer, o MySQL não precisar ler essas informações do disco, o que é muito mais rápido (velocidade da memória vs velocidade do disco) .

Como estas informações estão armazenadas na memória, cada vez que o MySQL é re-iniciado, o buffer é apagado, e para “esquentar” o buffer normalmente leva-se algum tempo.

Para agilizar este processo, vamos utilizar 2 variáveis para salvar e restaurar as referencias das paginas que estão armazenadas no buffer, esta é uma nova funcionalidade adicionada no MySQL 5.6 (essa opção já pode ser encontrada em algumas versões anteriores do Percona Server e MariaDB )

Se o seu servidor já está rodando e com o buffer …

Original post: http://anothermysqldba.blogspot.com/2013/05/oscommerce-mysql.html


Tem sido um tempo desde que eu olhei para o oscommerce pacote de software. É uma grande plataforma para a construção de uma loja on-line web.

No entanto, quando eles perguntam se você está acima "MySQL \ V5" ou abaixo dela começa a me deixar nervoso. Aparentemente, eu não estou sozinho com a preocupação de que InnoDB deve ser o mecanismo de armazenamento de escolha.

• …

O MySQL 5.6 está em sua versão RC (release candidate). Isto significa que, ele já foi testado e, teoricamente está em vias de entrar em produção. Em pouco tempo, ele estará nas ruas. Eu tenho acompanhado e testado, exaustivamente, o […] ↓ Read the rest of this entry...

Pode ser que esse post não tenha haver com o fato de este ser um blog focado em MySQL, mas, pelo contrário, tudo que está em torno de tal software de bancos de dados será abordado aqui com foco na utilidade e melhor funcionamento. Levando em conta que alguns serviços em nuvem ainda oferecem serviços [...]