Início / dba / Perguntas / 4494
Accepted
700 Software
Asked: 2011-08-10 05:28:56 +0800 CST

O Oracle DB é imune aos impasses do InnoDB encontrados no MySQL?

  • 772

Parece estranho para mim que o MySQL não lidaria com isso internamente: "Impasse encontrado ao tentar obter o bloqueio; tente reiniciar a transação"

O Oracle DB resolve esse problema? Afinal, a Oracle é dona do InnoDB.

mysql oracle

3 respostas

  1. Best Answer

    Nenhum banco de dados pode contornar erros de deadlock em geral - no Oracle, um deadlock indica um bug no aplicativo, não no banco de dados. O banco de dados Oracle detectará a condição de impasse (isto é, a sessão A tem um bloqueio que a sessão B está esperando e a sessão B tem um bloqueio que a sessão A está esperando) e encerrará uma das instruções bloqueadas para resolver o problema. Em primeiro lugar, seu aplicativo deve evitar a criação de um impasse -- uma opção é sempre gerar bloqueios na mesma ordem em todas as sessões.

    • 12

  2. Detecção de deadlock e problemas de resolução existem desde que os RDBMSs existam. Mesmo que a Oracle possua o InnoDB, não espere que a Oracle conserte o InnoDB. A maioria dos aplicativos é responsável pelos impasses, não tanto o RDBMS. Independentemente do Oracle, MySQL ou qualquer outro RDBMS, um erro de impasse pode mostrar sua cara feia.

    A Oracle adquiriu o InnoDB em 7 de outubro de 2005, quando a parceria entre o InnoBase Oy e o MySQL expirou e o MySQL demorou a renovar. IMHO, a Oracle tentou conter a maré do MySQL fazendo isso. Claro, ela se comprometeu a melhorar o InnoDB e o MySQL. Não tem escolha agora devido a relações públicas e possíveis questões antitruste. Diante disso, não devemos esperar que o InnoDB tenha melhorias que ofusquem ou se tornem comparáveis ​​ao Oracle.

    Afastando-se da política de negócios agora, olhe para o InnoDB por conta própria. Ele possui a variável innodb_lock_wait_time . Essa opção existe para aumentar ou diminuir o período de tempo para permitir que um bloqueio seja bem-sucedido e nada mais.

    Se ocorrerem deadlocks internamente, eu normalmente olharia para o índice clusterizado como a vítima no InnoDB porque índices não clusterizados também arrastam ponteiros de índice clusterizado. Atualizando uma linha no InnoDB onde as colunas indexadas são atualizadas, espero que ocorra um impasse devido ao índice clusterizado. Executar SELECT ... FOR UPDATE ou SELECT ... LOCK IN SHARE MODE pode agravar ainda mais o problema.

    Como o Oracle lida com isso internamente (se eles lidaram com isso) seria uma das longas listas de coisas que lhe dão vantagem sobre o MySQL. Não espero que a Oracle forneça a mesma vantagem para um produto Open Source/Freeware, a menos que seja o Oracle XE.

    • 6

  3. Os impasses são um fato da vida em todos os bancos de dados, e o Oracle não é exceção. Não há mágica que possa ser feita nessa situação - é uma consequência fundamental da simultaneidade (permitir que vários usuários acessem os dados ao mesmo tempo sem prejudicar a integridade):

    create table t(id integer primary key);

--session 1
insert into t(id) values(1);

--session 2:
insert into t(id) values(2);    --completes immediately
insert into t(id) values(1);    --waits for session 1 to commit or rollback

--session 1
insert into t(id) values(2);

--session 1 gets: 
SQL Error: ORA-00060: deadlock detected while waiting for resource

    O que a Oracle tem há muito tempo é uma excelente implementação do MVCC – leia sobre isso no muito útil guia de Conceitos .

    Acrescentarei apenas que é improvável que o InnoDB proprietário da Oracle faça muita diferença em como o InnoDB funciona profundamente no nível de controle de simultaneidade - embora, pelo que entendi, a maneira como ambos implementam o MVCC alcance basicamente a mesma coisa (desde que você esteja não misturar tabelas usando outros mecanismos de armazenamento em suas consultas MySQL - embora você não possa culpar o InnoDB nesse caso)

    • 5

relate perguntas