Olá Chiappa, Tem um trecho que você diz : "Como NÃO EXISTEM locks a nível de COLUNA" , mas já vi caso que o Oracle dá Lock se a coluna estiver sendo alterada. Para ser mais especifico se estivermos inserindo um registro FILHO o CAMPO da de Referencia da Tabela pai de "Lockada"
Segue o campo para reprodução: ---------------------------------------- SESSÃO 1 ---------------------------------------- Conectado. SQL> create table teste_pai(pk_number number(3) primary key, campo_desc varchar2(25) ); Tabela criada. SQL> create table teste_filho(pk_number number(3) primary key, fk_pai number(3), campo_desc varchar2(25), FOREIGN KEY (fk_pai) REFERENCES teste_pai(pk_number)); Tabela criada. SQL> insert into teste_pai(pk_number, campo_desc) values (1, 'Valor qualquer'); 1 linha criada. SQL> commit; Commit concluÝdo. ---------------------------------------- SESSÃO 2 ---------------------------------------- C:\>sqlplus /nolog Conectado. SQL> insert into teste_filho (pk_number, fk_pai,campo_desc) values (1,1,'Teste Qualquer'); 1 linha criada. ---------------------------------------- SESSÃO 1 ---------------------------------------- SQL> update teste_pai set campo_desc = 'OUTRO VALOR' where pk_number = 1; 1 linha atualizada. SQL> update teste_pai set pk_number = 2 where pk_number = 1; ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Veja que posso alterar qualquer campo do Registro PAI enquanto o Registro Filho Criado esta em Transação, ..:: MAS ::.. não o campo CHAVE do Pai. Alessandro Lúcio Cordeiro da Silva Analista de Sistema þ http://alecordeirosilva.blogspot.com/ O tic-tac do relógio me lembra de algo muito importante que esta acontecendo: estamos vivos. "Joana de Souza Schmitz Croxato" ________________________________ De: J. Laurindo Chiappa <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 29 de Agosto de 2013 14:58 Assunto: [oracle_br] Re: Row-X (SX) - Problema? Tudo jóia ? Então, na verdade vc está vendo aí o comportamento absolutamente NORMAL do RDBMS Oracle - os Conceitos para vc poder entender o que está ocorrendo estão melhor detalhados nos manuais Oracle (**principalmente ** o "Oracle® Database Concepts 11g Release 2" no cap. 9 - Data Concurrency and Consistency), nas notas metalink relacionadas (como a clássica "Master Note: Locks, Enqueues and Deadlocks (ORA-00060)" (Doc ID 1392319.1) , e em bons livros que detalham a arquitetura do RDBMS (como por exemplo os do Tom Kyte), mas a versão resumida da historinha é (sempre falando de locks relacionados a DML, os causados por DDLs são outra coisa) : - conceito 1 : no RDBMS Oracle, no instante mesmo em que o DML é processado de cara já é feito um lock em ** TODOS ** os registros envolvidos, não se 'espera' haver um acesso , nem nada, e é Autiomático (o programador/usuário não tem que fazer/programar NADA para isso) e inescapável : no caso, isso não traz problemas de acesso multi-usuário porque no RDBMS Oracle o SELECT, a leitura, ** NUNCA ** é afetada/bloqueada/impedida por lock de nenhum tipo, e vice-versa : LOCKERS nunca intererferem em/são interferidos por readers E readers nunca interferem em/são interferidos por LOCKERS, e isso não implica em leitura "suja" (ie, uma outra sessão ler dados alterados mas não comitados) porque os dados antes da alteração são "copiados" para uma estrutura chamada UNDO, e são esses dados que são lidos/retornados. - conceito 2 : existem 2 tipos básicos de locks automáticos relacionados a DML : locks row-level, que protegem/evitam alterações em uma só linha da tabela (normalmente chamados de TX Locks, ou transaction locks), e locks a nível de tabela (TM Locks, ou locks table management) , que protegem a tabela TODA, evitando DDLs na tabela lockada, okdoc ? ==> Esse conceito é Crítico : como ambos os locks se relacionam a linhas, vc VAI ver a palavra "ROW" nas descrições de ambos, mas Não Confunda-os - ambos são relacionados a linhas (daí o ROW na descrição) mas o escopo entre eles é Totalmente diferente, um locka uma só linha, outro locka TODAs as linhas (na prática "fechando"/protegendo a tabela toda), mas apenas para DDLs... DMLs (que se referem á linhas específicas de dados) não são que se refiram a linhas Aqui está, penso eu, a fonte de sua dúvida : a V$LOCKED_OBJECT mostra o locked_mode , a 'funcionalidade' dos locks , que para DMLs normalmente vai ser 3, que é relacionado com linhas (rows), mas ** NÃO MOSTRA ** o TIPO do lock, se é TX ou TM, então só pela V$LOCKED_OBJECT vc não tem como saber o TIPO dos locks presentes, se ele está protegendo uma linha só ou não, se protege o conunto de linhas (a tabela toda).... Isso vc só vai achar na V$LOCK, coluna TYPE... Sim ??? É um pouco de nomenclatura deslocada, concordo, mas é o que é..... TIPICAMENTE, com INSERTs feitos em tabelas sem constraints (já que aí nada impediria vc de inserir o mesmo valor) vc só vai encontrar o comum lock TM (a nível de tabela), : é ele que impede outra sessão de alterar a estrutura DML na tabela (o que daria conflito lógico, já que os registros estão sendo inseridos/deletados/modificados numa dada estruturajá existente , assim enquanto esse DML não for resolvido, quaisquer alterações via DDL que POTENCIALMENTE poderia mudar a estrutura do registro vão ser impedidas).... ==> IMPORTANTE : Como NÃO EXISTEM locks a nível de COLUNA, aí então mesmo nas situações em que o objetivo é evitar a alteração de uma ou mais colunas apenas, o RDBMS vai empregar LOCKs row-level e table-level, cfrme necessário - conceito 3 : quando há Relacionamentos/Constraints/Índices,etc, esses caras são baseados em COLUNAS-CHAVE (existentes TANTO nas tabelas-pai quanto nas tabelas-filha), então (já que não é possível se ter um lock apenas para as colunas-chave a preservar de DDLs, como dito acima) Logicamente todas as tabelas envolvidas vão obter um lock do tipo TM, para EVITAR que algum DDL altera colunas-chaves, altere relacionamentos, yep ???? Aí vc pode dizer "ah, não seria melhor, ao invés de via lock de tabela o RDBMS proibir qualquer DDL, ele ao invés ANALISAR cada DDL enviado, pesquisando o dicionário de dados, para ver se o DDL vai ou não alterar colunas-chaves ???? Poder podia, mas A dificuldade de se implementar isso seria a LÓGICA COMPLEXA envolvida, que poderia levar a falsos positivos E a problemas de performance na fase de interpretação dos comandos que o RDBMS recebe, então aí optou-se por esse comportamento de simplesmente barrar DDLs.... Tendo em vista esses conceitos aí acima, imho então o que vc está vendo é algo TOTALMENTE NORMAL : muito certamente os locks que vc está vendo nas tabelas que não estão sendo alteradas mas são relacionadas com a tabela em alteração são locks TM, que protegem contra DDLs mas Não Impedem DMLs, DMLs concorrentes (entre sessões diferentes) só são impedidos nas linhas protegidas por locks do tipo TX, em princípio.... Há muitos OUTROS detalhes aí a serem passíveis de entendimento, mas com isto ACHO que já explica o que vc está vendo : Consulte a V$LOCK e vc vai ver o que vc vai ver.... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Luciana Camargo <lcamargo@...> escreveu > > Pessoal > boa noite! > > Preciso uma ajuda de vocês para entender se é uma situação normal ou > posso ter algum problema. > > Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit > > > > Eu fiz um teste simulando o que temos no banco aqui > > > > CREATE TABLE TAB_TYPE_1 > > (ID NUMBER(10) PRIMARY KEY, > > CODE VARCHAR2(10) NOT NULL); > > > > CREATE TABLE TAB_TYPE_2 > > (ID NUMBER(10) PRIMARY KEY, > > CODE VARCHAR2(10) NOT NULL); > > > > -- Tabela principal que depende das 2 tabelas acima de configuração: > > CREATE TABLE TAB_A > > (ID NUMBER(10) PRIMARY KEY, > > CODE VARCHAR2(10) NOT NULL, > > TYPE_1_ID NUMBER(10), > > TYPE_2_ID NUMBER(10)); > > > > ALTER TABLE tab_a ADD CONSTRAINT fk_tab_a_type_1 FOREIGN KEY (type_1_id) > > REFERENCES tab_type_1 (id); > > > > ALTER TABLE tab_a ADD CONSTRAINT fk_tab_a_type_2 FOREIGN KEY (type_2_id) > > REFERENCES tab_type_2 (id); > > > > CREATE INDEX idx_tab_a_type_1 ON tab_a (type_1_id) TABLESPACE indx; > > CREATE INDEX idx_tab_a_type_2 ON tab_a (type_2_id) TABLESPACE indx; > > > > -- Quando faço a inserção na tabela principal, mesmo SEM valor nos > > atributos de tipos verifico que existe a seguinte indicação em * > > v$locked_object*: > > > > INSERT INTO tab_a (id, code) VALUES (1,1); > > > > OBJECT_NAME LOCKED_MODE > > ------------------ --------------- > > TAB_A Row-X (SX) > > TAB_TYPE_1 Row-X (SX) > > TAB_TYPE_2 Row-X (SX) > > > > Eu entendo que os valores de v$locked_object.locked_mode são: > > 0, 'None', > > 1, 'Null (NULL)', > > 2, 'Row-S (SS)', > > 3, 'Row-X (SX)', > > 4, 'Share (S)', > > 5, 'S/Row-X (SSX)', > > 6, 'Exclusive (X)', > > > > SID Lock Type Mode Held Blocking? > > ----- --------------- --------------- --------------- > > 579 DML Row-X (SX) Not Blocking > > 579 DML Row-X (SX) Not Blocking > > 579 DML Row-X (SX) Not Blocking > > 579 Transaction Exclusive Not Blocking > > 579 AE Share Not Blocking > > > > Apesar de aparecer conforme acima, NÃO está impedindo nenhuma > > alteração/remoção em relação a dados para as tabelas de tipos, apenas > > segurando alterações de estrutura. > > > > Isso impacta em algo em relação a contenção ou é um comportamento normal? > > Por que o indicativo "Row" se não há nenhuma contenção de linha? > > > > > > Obrigada > > > Luciana > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]
