Transaction Autonomous – O Que, Quando, Onde e Por Que

Do que se trata o artigo:

Neste artigo será apresentada a utilização do pragma autonomous Transaction para escrita de códigos autônomos em rotinas PL/SQL, as quais são executadas e commitadas na base independentemente do resultado da transação master que invocou essa rotina.


Em que situação o tema é útil:

Esta funcionalidade é bastante utilizada para geração de logs de erro de transação, onde a transação master sofre rollback depois de uma falha, mas é possível gerar um log contento os dados da transação que resultaram no erro.

Um subprograma normalmente tem suas operações salvas ou não no banco de dados de acordo com o que acontece com o programa principal onde ele está inserido. Isso quer dizer que, se uma procedure chama uma função e a procedure falha, nem as alterações feitas pela procedure nem as alterações feitas pela função são salvas na base, afinal trata-se da mesma transação, a qual é atômica (indivisível, ou seja, ou ela toda é commitada ou ela toda sofre rollback). No entanto, se a função contiver o pragma autonomous_transaction, ela se comporta como uma segunda transação, que é isolada e independente, e suas alterações na base podem ser salvas ou não independentemente da transação master que a originou.

A diretiva AUTONOMOUS_TRANSACTION altera a forma com que a transação trata a um subprograma. Um pragma na verdade é uma diretiva de compilação e os subprogramas marcados com este pragma são processados em tempo de compilação e não em tempo de execução, e passam informações diretamente ao compilador.

O termo AUTONOMOUS_TRANSACTION se refere à habilidade do PL/SQL temporariamente suspender a transação corrente e iniciar uma nova transação, totalmente independente, que funciona de forma autônoma com relação à transação original.

Imagine a seguinte situação: Para fins de auditoria, criamos uma tabela de log que contém os dados referentes a todas as alterações feitas nos dados de 5 tabelas críticas do banco de dados da empresa, armazenando o IP da máquina que originou a transação, qual tabela sofreu alteração, o que foi feito, etc, e um trigger é responsável por inserir tais dados nessa tabela. Pois bem, vamos supor então que por um motivo ou outro essa transação tenha falhado. Não desejamos que os logs de auditoria também sofram rollback, pois estaremos perdendo dados preciosos de tentativas frustradas de acesso não autorizado.

Neste caso, o trigger deve disparar um subprograma autônomo, cujo sucesso da transação não dependa do resultado da transação principal que o originou.

A utilização em tratativas de logs de auditoria são comuns e não causam nenhum tipo de problema ao banco de dados, uma vez que não está lidando com tabelas de negócio, ou seja, que guardam dados essenciais para o negócio. Por este motivo a transação autônoma é segura, pois a integridade do banco de dados está resguardada.

Digo isso porque já vi muitos códigos resolvendo regras de negócio com transações autônomas, o que pode gerar um problema grande para o banco de dados. Imagine que a alteração de um valor em uma tabela deve causar alterações em outras tabelas. Se a primeira alteração falha, o ideal é que as demais alterações não ocorram… neste caso o procedimento que faria as demais alterações não poderia jamais ser autônomo!

Qualquer subprograma, como procedures, funções ou até mesmo blocos anônimos PL/SQL podem conter este pragma. No entanto, se for utilizado dentro de pacotes, o pragma deve ser declarado para as funções e procedures que fazem parte do pacote, e não para o pacote em si.

Exemplo de Utilização

Como um exemplo de utilização da transação autônoma, vamos assumir que precisamos gravar logs de erro em uma tabela do banco de dados. Precisamos fazer rollback da transação principal porque ela resultaria em um erro, mas não queremos perder o log do que aconteceu nessa transação. A tabela que conterá os logs de erro possui a seguinte estrutura:

CREATE TABLE tb_log_erros(

  codigo integer,

  msg varchar2(2000),

  data date,

  usuario varchar2(50),

  nm_mach varchar2(100),

  prog varchar2(100)

);

O procedimento que deve ser invocado para inserir o log do erro na tabela é:

CREATE OR REPLACE PROCEDURE grava_log_erros(

   log_codigo IN INTEGER,

   log_msg IN VARCHAR2) IS

PRAGMA AUTONOMOUS_TRANSACTION;

CURSOR cur_erro IS

SELECT machine, program

FROM v$session

WHERE audsid = USERENV(‘SESSIONID’);

PT = Parent Transaction;

CT = Child Autonomous Transaction;

rec cur_erro%ROWTYPE;

BEGIN

   —

   OPEN cur_erro;

   FETCH cur_erro INTO rec;

   CLOSE cur_erro;

   —

   INSERT INTO tb_log_erros values (

       log_codigo,

       log_msg,

       SYSDATE,

       USER,

       rec.machine,

       rec.program

   );

   COMMIT;

EXCEPTION

   WHEN OTHERS THEN

       ROLLBAACK;

END;

/

Para testar o código acima, podemos executar o seguinte bloco anônimo PL/SQL:

BEGIN

    INSERT INTO HR.EMPLOYEES (first_name) VALUES (‘Maria’);

    COMMIT;

EXCEPTION

    WHEN OTHERS THEN

         grava_log_erros(SQLCODE,SQLERRM);

    ROLLBACK;

    RAISE;

END;

Ao executar o código acima, basta verificar nas tabelas EMPLOYEES e TB_LOG_ERROS as linhas inseridas, como segue:

SQL> select * from employees where first_name = ‘Maria’;

no rows selected.

SQL> select codigo, msg from tb_log_erros;

CODIGOMSG

——————————————————————————————————–

-1400ORA-01400: cannot insert NULL into (“HR”.”EMPLOYEES”.”EMPLOYEE_ID”)

Referências

BURLESON CONSULTING. PL/SQL Autonomous Transaction Tips. Burleson Consulting, 2015. Disponivel em: http://www.dba-oracle.com/t_autonomous_transaction.htm

ORACLE HELP CENTER. Autonomous_transaction Pragma. Database PL/SQL User’s Guide and Reference, 2017. Disponivel em: https://docs.oracle.com/cd/B19306_01/appdev.102/b14261/autonotransaction_pragma.htm

14 Comandos SQL – Administrando seu Site WordPress

Uma maneira prática de executar comandos SQL é através do phpMyAdmin. Até a hospedagem mais básica dá acesso à ferramenta de banco de dados, então não há dificuldades nisso. Uma vez no sistema, você deve selecionar aba “SQL” e escrever/colar a instrução SQL que deseja executar.

Importante

Os comandos SQL para WordPress a seguir são para o prefixo padrão do WordPress “wp_”. Caso o prefixo de suas tabelas seja diferente (o que é recomendado, por questões de segurança), faça os devidos complementos necessários às queries.

×

Importante

Lembre-se: é sempre bom fazer um backup completo de seu banco de dados antes de executar queries SQL (principalmente se você não souber muito bem o que está fazendo)!

1. Alterar siteurl e homeurl

WordPress armazena o caminho absoluto da URL do site (“siteurl”) e URL da home (“homeurl”) no banco de dados. Portanto, se você transferir o seu site WordPress do localhost para o servidor, por exemplo, o site não vai carregar! Isso ocorre porque o caminho absoluto ainda está apontando para o seu localhost. Você vai precisar executar um comando para resolver isso.

1
2
3
4
UPDATE wp_options
 SET option_value = replace(option_value, 'http://www.enderecoantigo.com', 'http://www.endereconovo.com')
 WHERE option_name = 'home'
 OR option_name = 'siteurl';

2. Alterar GUID

Depois de migrar seu blog a partir de, por exemplo, localhost, para o servidor ou de um outro domínio para um novo domínio, você terá que corrigir as URLs para o campo GUID na tabela wp_posts. Isto é crucial, porque GUID é usado para montar o slug de seu post do caminho absoluto do artigo correto.

1
2
UPDATE wp_posts

3. Alterar URL no conteúdo

O WordPress utiliza caminhos absolutos no URL ao invés de um caminho relativo quando vai armazená-los no banco de dados. Dentro do conteúdo de cada registro de artigo, ele armazena todas as URLs antigas referenciando as fontes antigas. Portanto, você precisará alterar todas essas URLs com o endereço do novo domínio.

1
2
UPDATE wp_posts
SET post_content = REPLACE (post_content, 'http://www.enderecoantigo.com', 'http://www.endereconovo.com');

4. Alterar apenas o caminho das imagens

Caso seja preciso alterar o domínio das imagens inseridas nas páginas e artigos, esta solução vai ajudar você a fazer isso de forma simples.

1
2
UPDATE wp_posts
SET post_content = REPLACE (post_content, 'src="http://www.enderecoantigo.com', 'src="http://www.endereconovo.com');

Também é preciso atualizar o GUID para o tipo “attachment” com a seguinte instrução SQL:

1
2
UPDATE wp_posts
SET guid = REPLACE (guid, 'http://www.enderecoantigo.com', 'http://www.endereconovo.com') WHERE post_type = 'attachment';

5. Atualizar Post Meta

Atualizar Post Meta funciona quase da mesma maneira como atualizar a URL no conteúdo do post. Se você tiver dados extras para cada post, você pode usar a seguinte instrução para alterar todos eles.

1
2
UPDATE wp_postmeta
SET meta_value = REPLACE (meta_value, 'http://www.enderecoantigo.com','http://www.endereconovo.com');

6. Alterar o nome usuário padrão “admin”

Apesar de que na versão 3 do WordPress o usuário “admin” poderá ser alterado no momento da instalação, não custa deixar para a posteridade a dica de como alterar o nome do “admin”.

1
2
3
UPDATE wp_users
SET user_login = 'nomequevocequiser'
WHERE user_login = 'Admin';

7. Resetar password

Já quis resetar sua senha no WordPress mas, por algum motivo, não conseguiu usar a seção para resetar o password? Eis a solução:

1
2
3
UPDATE wp_users
SET user_pass = MD5('senha')
WHERE user_login = 'login';

8. Transferir artigos de um autor para outro

Para transferir os artigos de um autor para outro, você gasta um tempo enorme se fizer isso manualmente. Com o comando SQL a seguir, é possível fazer isso facilmente. Para a dica, é preciso saber o ID dos autores.

1
2
3
UPDATE wp_posts
SET post_author = 'id_novo_autor'
WHERE post_author = 'id_autor_antigo';

9. Apagar revisões

Quando se está editando um artigo no WordPress, é comum cópias de segurança serem feitas para garantir o trabalho feito. São as chamadas “revisões”. Com o tempo, o número de registros de revisões fica grande e isso pode comprometer a performance do banco de dados. Para apagar todas as revisões de artigos, dê o seguinte comando SQL:

1
2
3
4
DELETE a,b,c FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

Lembrando que este é o comando para apagar revisões já feitas. Caro queira desativar o recurso (ou limitar o número de revisões), saiba como neste artigo sobre como limitar e desativar revisões de posts no WordPress.

10. Apagar post meta

Instalar e remover plugins é algo corriqueiro quando se trabalha com WordPress. Alguns plugins precisam de criar alguns post meta para funcionarem corretamente e, para esses casos, não é raro o acontecimento de, mesmo depois de o plugin ser desinstalado, algum “garbage meta” ficar enchendo o BD desnecessariamente. Uma limpeza em algum valor de post meta, às vezes, se faz necessária.

1
2
DELETE FROM wp_postmeta
WHERE meta_key = 'nome-chave-meta';

11. Exportar todos os e-mails de comentários

Quanto mais tempo seu blog/site fica no ar, é provável que mais comentários receba nos artigos publicados. Se, por algum motivo, for preciso uma listagem com e-mail de todas as pessoas que já comentaram até então, basta executar o seguinte comando:

1
2
SELECT DISTINCT comment_author_email
FROM wp_comments;

12. Apagar todos pingbacks

A medida que o site/blog fica no ar – e se você tiver bom conteúdo a oferecer – o número de pingbacks começa a influenciar a qualidade do banco de dados. Para apagar todos pingbacks, proceda da seguinte maneira:

1
DELETE FROM wp_comments WHERE comment_type = 'pingback';

13. Apagar todos comentários de SPAM

Sem maiores explicações, eis a maneira de deletar todos os comentários marcados como SPAM:

1
2
DELETE FROM wp_comments
WHERE comment_approved = 'spam';

14. Identificar tags não usadas

Num banco de dados WordPress, se você executar alguma query SQL para apagar posts, as tags relacionadas não serão apagadas e continuarão aparecendo na nuvem de sugestão de tags e listagem de tags. Para identificar esse tipo de tag, execute a seguinte instrução SQL:

1
2
3
4
5
SELECT * From wp_terms wt
INNER JOIN wp_term_taxonomy wtt
ON wt.term_id=wtt.term_id
WHERE wtt.taxonomy='post_tag'
AND wtt.count=0;

 

Fonte: Este é um artigo traduzido do original “13 Useful WordPress SQL Queries You Wish You Knew Earlier“, do blog Onextrapixel, e sofreu algumas adaptações, tradução por Tárcio Zemel do DPW.

http://pixelproject.com.br/15-fantasticos-comandos-sql-para-wordpress/