- Este tópico contém 45 respostas, 4 vozes e foi atualizado pela última vez 15 anos, 8 meses atrás por
Maths.
-
AutorPosts
-
24 de junho de 2010 às 10:43 pm #94802
fsitja
ParticipanteIsso que você explicou é lógica de aplicação, não de locking no nível de banco de dados.
Locking de banco de dados é feito por motivo de consistência de leitura.
Por exemplo:João quer alterar o preço de todas TVs cujo preço seja menor que 1000 reais para 2000 reais.
Logo, ele dá um select com o for update, que terá no where preço que ele quer como critério de seleção. A linha fica presa até que ele dê o commit.Se a Maria, ao mesmo tempo que João está fazendo a alteração, quiser mudar para 3000 o preço das TVs cujo preço atual seja menor que 1000, o banco de dados bloqueia ela, pois João “chegou antes” e lockou as linhas primeiro. Ela só vai poder fazer a alteração dela depois que o João terminar.
O que você poderia fazer é criar uma coluna de “bloqueio” na sua tabela, e dar um update setando ela para 1 ou ‘V’. A lógica para consultar terá no Where apenas bloqueio = 0 ou bloqueio = ‘F’, por exemplo.
Pode ser necessário de qualquer forma usar “for update” no select que faz o bloqueio, para garantir que duas transações concorrentes ou simultâneas não bloqueiem a mesma linha ao mesmo tempo.
24 de junho de 2010 às 10:54 pm #94804Maths
ParticipanteHmmm, é algo para eu dar uma estudada e me aprofundar mais, porem, esse SLEEP deixa a linha permanentemente parada lá pelo periodo de tempo setado mesmo sem estar conectado ao banco?
24 de junho de 2010 às 11:05 pm #94805Maths
Participante[quote=”fsitja”:2yd3eavk]Isso que você explicou é lógica de aplicação, não de locking no nível de banco de dados.
Locking de banco de dados é feito por motivo de consistência de leitura.
Por exemplo:João quer alterar o preço de todas TVs cujo preço seja menor que 1000 reais para 2000 reais.
Logo, ele dá um select com o for update, que terá no where preço que ele quer como critério de seleção. A linha fica presa até que ele dê o commit.Se a Maria, ao mesmo tempo que João está fazendo a alteração, quiser mudar para 3000 o preço das TVs cujo preço atual seja menor que 1000, o banco de dados bloqueia ela, pois João “chegou antes” e lockou as linhas primeiro. Ela só vai poder fazer a alteração dela depois que o João terminar.
O que você poderia fazer é criar uma coluna de “bloqueio” na sua tabela, e dar um update setando ela para 1 ou ‘V’. A lógica para consultar terá no Where apenas bloqueio = 0 ou bloqueio = ‘F’, por exemplo.
Pode ser necessário de qualquer forma usar “for update” no select que faz o bloqueio, para garantir que duas transações concorrentes ou simultâneas não bloqueiem a mesma linha ao mesmo tempo.[/quote]
Sim, eu entendi perfeitamente sua explicação, muito clara por sinal, 😉
POREM nao adianta hEUUehoEH.. galera, é foda, to numa empresa q utiliza ferramentas de fora do brasil, ou seja, somos os pioneiros a isso aqui no brasil e um dos unicos e poucos, trabalhamos com eHealth, SPECTRUM, CMDB (todas da CA) que fazem gerenciamento de falhas e performance.. porem tb mexemos com SLM (gerenciamento de nivel de serviço) a ferramenta q faz isso se chama Service Flow, ela é da Digital Fuel (israelense) nao existe nada sobre ela no brasil, ou seja ela gerencia os dados, faz fluxos, otimiza dados e tudo mais, eu entrei aqui como 1 emprego, fiz curso de desenvolvedor oracle apenas, mais nada… essa ferramenta utiliza uma operação q se chama adaptador, o adaptador o que ele faz? voce indica o BANCO de DADOS ou 1 Tabela Unica (Flat File) que esse adaptador vai lá e pega os dados daquilo e traz para dentro dele, dentro da aplicação, e com os dados lá voce pode manipulalos, mas nao como ORACLE, ou o com procedures e talz.. vc faz FLUXOS, Flows com os dados.. filtra, agrega, compara, faz tendencias e talz, porem em um fluxo.. o dado entra daquela tabela e após aquilo vc cria um fluxo, exemplo:
Tabela 1 > Filtra > Agrega > Compara > Tendencia > Relatorio
Ou seja, o cliente vai ver só o relatorio do que ele me pediu entendem?? ENTAO, eu preciso bloquear algumas linhas por fora da aplicação, na fonte do dado (tabela ou banco) que quando o adaptador for puxar, ele faz uma copia identica, ou seja, as linhas virao bloqueadas, o motivo nao vou explicar pq vai demorar mtu, precisamos simular tabelas dentro da aplicação, meio complicado HUOHeuoheuoheuEO!! Captaram?? algo que bloqueie a linha q eu indique..
eu fale, voce linha 8, linha 32 e linhas 18 quero q bloquei.. a query vai lá e trava elas, ELAS CONTINUAM LÁ porem nao sao manipuladas, se eu fizer uma select, ele me traz todas as linhas da coluna MENOS as bloqueadas, coisas q isso como voce disse de Y ou V nao é mtu facil pelo service flow fazer entendeu?? os dados ja precisam entrar bloqueados!
24 de junho de 2010 às 11:43 pm #94806vieri
ParticipanteComo nosso amigo falou o Oracle não implementa isso, vai ter que criar,
através de coluna´s , procedure..etc..Neste link tem um exemplo do Sleep usado no flashback
da uma lida e ve se tem algo que possa elucidar seu problema.http://eduardolegatti.blogspot.com/2008 … ery-e.html
Oque vc pode fazer é montar uma procedure que verifique
as linhas que estão bloqueadas, guarde numa tabela temporário,
transfira essa tabela twemporária pra lá… e no destino tenha um procedure
que fique montando select for update destas linhas…Furrupa,bacalhau,tubarão.. mas é uma idéia…
da uma lida no link que enviei e tentar montar uma idéia também,
perguntando pra nós se é viavel..
porque buscar essa solução imbutida no banco acho que será díficil…25 de junho de 2010 às 12:17 am #94807fsitja
ParticipanteSe eu entendi bem, daria para implementar isso através de VPD ou Fine-Grained Acess, por política de segurança ocultando as linhas que você quer filtrar.
Só que para criar a policy e registrá-la você vai ter que ler bastante documentação para entender como funciona e como implementar, fica mais complicado a gente tentar explicar no fórum o conceito.
A ideia básica é o seguinte: a policy é uma function que gera dinamicamente uma cláusula where que é embutida em todas SQLs que rodam na máquina envolvendo determinada tabela. Você poderia criar uma trigger de logon que registra no context do user que conecta no banco (tipo uma “variável global” dizendo: “eu sou user_x”).
Sua function policy vai verificar qual user conectou no banco, tipo IF sys_context(‘meucontext’, ‘usuario’) = ‘USER_X’ THEN return ‘coluna_bloqueio = ”F”’.
Isso é feito dinamicamente pelo banco cada vez que alguém rodar um SQL na sua tabela com dados sensíveis a essa política de segurança.Dá uma boa lida na documentação sobre VPD, Fine-Grained Access e Policy Functions e especificamente sobre a package DBMS_RLS da sua versão do Oracle.
Nos links abaixo seguem as explicações para a versão 11gR2:
http://download.oracle.com/docs/cd/E118 … 74/vpd.htm
http://download.oracle.com/docs/cd/E118 … g_data.htm
http://download.oracle.com/docs/cd/E118 … /d_rls.htmSe você postar algo específico, tipo estruturas de exemplo de tabelas, dados de exemplo e consultas que você quer executar nelas, daria para bolar alguma coisa mais específica, mas não deixe de ler a documentação para entender sobre o assunto e ver se atende à sua necessidade.
25 de junho de 2010 às 12:28 am #94808burga
ParticipanteUma view simples da tabela, com uma coluna de controle de lock e com a cláusula WITH CHECK OPTION não resolve teu problema??
25 de junho de 2010 às 12:48 am #94809fsitja
Participante[quote=”burga”:31ox65kk]Uma view simples da tabela, com uma coluna de controle de lock e com a cláusula WITH CHECK OPTION não resolve teu problema??[/quote]
Não entendi bem também qual a restrição… se é por que não pode modificar as colunas da tabela utilizada? Ou substituí-la por uma view? Tipo, a aplicação não pode ser afetada ou algo assim?
Se puder, uma solução mais simples serve como a da view que você mencionou atenderia mesmo.
25 de junho de 2010 às 2:43 am #94810burga
Participante[quote=”fsitja”:1kn2norf][quote=”burga”:1kn2norf]Uma view simples da tabela, com uma coluna de controle de lock e com a cláusula WITH CHECK OPTION não resolve teu problema??[/quote]
Não entendi bem também qual a restrição… se é por que não pode modificar as colunas da tabela utilizada? Ou substituí-la por uma view? Tipo, a aplicação não pode ser afetada ou algo assim?
Se puder, uma solução mais simples serve como a da view que você mencionou atenderia mesmo.[/quote]
É, pelo que o Maths está falando, eu acredito que uma view simples, com uma coluna pra controlar o lock dos registros e mais a cláusula WITH CHECK OPTION resolve o problema dele…
Sendo que a única condição do select da view seria retornar os registros em que a coluna de lock não estivesse marcada… Assim, pela view, ele pode fazer qualquer operação de DML, mas apenas nos registros em que a view pode retornar, ou seja, aqueles que não estão em “lock”…
25 de junho de 2010 às 4:08 pm #94818Maths
ParticipanteGalera, agradeço a ajuda de todos, de verdade.. mostrei o topico para o meu chefe e ele riu aEUHAeuohaEUO, disse matheus, voce nao explicou direito, tudo isso eu faria se fosse isso que eu precisasse, mas é o seguinte… nós precisamos SIMULAR uma tabela, é uma tabela com 17mil registros e 35 colunas.. meu chefe esta fazendo uma implementação de sistema em uma empresa e quando ele usa o service flow la nessa empresa o adaptador que pega os dados da tabela nao esta pegando os 17mil, esta pegando apenas alguns.. e ele precisa simular aquela tabela, pegar a TABELA ORIGINAL COM 17MIL REGISTROS E CRIAR UMA NOVA IDENTICA A primeira de 17mil registros, SEM coluna adicional sem nada… POREM ele quer TRAVAR UMAS 7 LINHAS, sem coluna, só no comando, exemplo: LOCK_ROWS WHERE ID: 3, 7, 23, 78. Isso foi um exemplo besta, ai essas 4 linhas ficaram travada, e QUANDO ELE FOI FAZER A COPIA E CRIAR UMA nova tabela identica aquela ELE QUER Q OS 4 DADOS q ele travou NAO VENHAM para a nova, e sim 16,996 registros, menos os que ele bloqueou, entenderam?? isso é um teste, se ele descobrir como trava linhas dessa maneira, ele vai conseguir simular uns testes aqui e la na empresa ele vai bloquear algumas linhas pois podem estar com dados corrompidos e assim resolver nosso problema, ou seja… o que ele quer agora, é apenas algum comando que trave essas linhas entenderam +/-?? é simples, algo que eu fale para o oracle, olha oracle, esquece as linhas 3, 7, 23, 78, deixe elas lá, porem nao me traga elas quando eu fizer a copia dessa tabela, nao é nem para um caso de update nada disso, apenas para criar uma nova apartir daquela.
E por incrivel q pareça, ele nao quer WHERE, exemplo, fazer uma copia da tabela talz where as linhas bla bla nao venham.. ele nao quer isso, ele nao quer LOGICA de programação, ele quer REALMENTE BLOQUEAR, travar as linhas, que elas continuem lá, porem como se fosse uma chave… ai quando ele copiasse o oracle iria passar e copiar todos os arquivos da tabela, e quando ele chegasse nos bloqueados ele pulasse aquela linha e nao trazesse entendeu?? mas isso nao por sintaxe, loop nada disso, ele queria travar msm, congelar a linha por tempo indeterminado.
25 de junho de 2010 às 4:38 pm #94820burga
ParticipanteEstranho, desconheço alguma maneira de fazer isto sem o WHERE… Inclusive com VPD, DBMS_ADVANCED_REWRITE e View a consulta também usaria uma condição pré-estabelecida…
.
.
.
.
.
preciso de um café…
25 de junho de 2010 às 4:56 pm #94821fsitja
ParticipanteTudo bem, mas eu continuo sem entender: Qual a restrição que impede de criar uma view?
Na view teria “WHERE ID NOT IN (3, 7, 23, 78 ) with check option”, como o Burga sugeriu. Deixa eu te dar um exemplo em código, pra você ver se atende.
SQL> create table tab_original (id number(10), descricao varchar2(100));Table created
SQL> insert into tab_original values (1, 'A');1 row inserted
SQL> insert into tab_original values (2, 'A');1 row inserted
SQL> insert into tab_original values (3, 'A');1 row inserted
SQL> insert into tab_original values (4, 'A');1 row inserted
SQL> insert into tab_original values (7, 'A');1 row inserted
SQL> insert into tab_original values (23, 'A');1 row inserted
SQL> insert into tab_original values (78, 'A');1 row inserted
SQL> insert into tab_original values (100, 'A');1 row inserted
SQL> select * from tab_original;ID DESCRICAO
1 A 2 A 3 A 4 A 7 A 23 A 78 A 100 A8 rows selected
SQL> create or replace view vw_tab_original as
2 select t.id, t.descricao
3 from tab_original t
4 where t.id not in (3, 7, 23, 78) with check option;View created
SQL> select * from vw_tab_original;ID DESCRICAO
1 A 2 A 4 A 100 AAí você tem duas opções
- ou renomeia a tabela para algum outro nome e cria a view com o nome “tab_original”, no exemplo;
- ou, se for outro usuário quem usa a tabela, remova o grant dela (revoke select, insert, update, delete on tab_original from outro_user) e dê os grants na view, criando um sinônimo privado nesse outro owner com o nome “tab_original”.
De qualquer uma das duas formas acima, o usuário não vai nem perceber que a tabela que ele usava agora foi substituída por uma view. Quando quiser “destravar” elas, é só executar novamente o create or replace view, só removendo o where. O usuário utilizando a view vai apenas perceber que as novas linhas apareceram.
25 de junho de 2010 às 5:00 pm #94822Maths
ParticipanteSim sim, eu realmente admito que é dificil, tb nao imagino como fazer isso, porem a unica coisa que eu fiquei de dar uma lida e nao achei nada na net, foi o que o vieri disse, aquele LOCK_SLEEP(‘segundo’) parece q tem chances de resolver meu problema, se voceis tivessem esse material poderiam me enviar para eu dar uma lida??? Por favor! Obrigado
25 de junho de 2010 às 5:35 pm #94825Maths
Participante[quote=”fsitja”:2wm0gqgb]Tudo bem, mas eu continuo sem entender: Qual a restrição que impede de criar uma view?
Na view teria “WHERE ID NOT IN (3, 7, 23, 78 ) with check option”, como o Burga sugeriu. Deixa eu te dar um exemplo em código, pra você ver se atende.
SQL> create table tab_original (id number(10), descricao varchar2(100));Table created
SQL> insert into tab_original values (1, 'A');1 row inserted
SQL> insert into tab_original values (2, 'A');1 row inserted
SQL> insert into tab_original values (3, 'A');1 row inserted
SQL> insert into tab_original values (4, 'A');1 row inserted
SQL> insert into tab_original values (7, 'A');1 row inserted
SQL> insert into tab_original values (23, 'A');1 row inserted
SQL> insert into tab_original values (78, 'A');1 row inserted
SQL> insert into tab_original values (100, 'A');1 row inserted
SQL> select * from tab_original;ID DESCRICAO
1 A 2 A 3 A 4 A 7 A 23 A 78 A 100 A8 rows selected
SQL> create or replace view vw_tab_original as
2 select t.id, t.descricao
3 from tab_original t
4 where t.id not in (3, 7, 23, 78) with check option;View created
SQL> select * from vw_tab_original;ID DESCRICAO
1 A 2 A 4 A 100 AAí você tem duas opções
- ou renomeia a tabela para algum outro nome e cria a view com o nome “tab_original”, no exemplo;
- ou, se for outro usuário quem usa a tabela, remova o grant dela (revoke select, insert, update, delete on tab_original from outro_user) e dê os grants na view, criando um sinônimo privado nesse outro owner com o nome “tab_original”.
De qualquer uma das duas formas acima, o usuário não vai nem perceber que a tabela que ele usava agora foi substituída por uma view. Quando quiser “destravar” elas, é só executar novamente o create or replace view, só removendo o where. O usuário utilizando a view vai apenas perceber que as novas linhas apareceram.[/quote]
Entendi perfeitamente seu exemplo, otimo tambem, porem galera voceis ainda nao captaram ou eu nao to conseguindo explicar aehaEUHEOU.. Meu chefe deu uma lida aqui no topico novamente e disse matheus, explica desse jeito, assim.. fala para ele, imaginem duas aplicaçoes correntes manipulando um banco, mas essa aplicação quando vai mexer nos dados de uma tabela no banco algumas linhas estao vindo bloqueadas, ele nao me traz algumas linhas pois estao bloqueadas, entao eu preciso SIMULAR o que esta acontecendo para poder entender o motivo que ele esta lockando as linhas, ou seja, precisamos TRAVAR NÓS MESMOS algumas linhas dessa tabela para PODER SIMULAR se ele pega os dados ou nao, POREM a aplicação que vai buscar os dados nao me dá opcao nenhuma de fazer essas manipulaçoes no banco como voceis me dizem, eu tenho q travar algumas linhas e ir na minha aplicação (que se chama Service Flow) ai por ela eu vou e puxo a tabela, ai eu estarei simulando, pois vou puxar uma tabela que eu travei registros para ver se ele me traz os dados bloqueados OU NAO, para poder entender o problema que esta acontecendo nessa empresa que estamos implementando o sistema, entenderam? XD
25 de junho de 2010 às 8:10 pm #94826fsitja
ParticipanteAcho que agora deu para entender… 😆
Mas, de qualquer forma, para conseguir simular o que está acontecendo lá vai depender de como foi implementado isso na aplicação.
Se fosse um locking de linha comum, com um “for update” na consulta de banco de dados, não estaria voltando coisa alguma até que o locking fosse liberado. Não dá para filtrar fora apenas as linhas que estão sendo usadas e trabalhar com as demais enquanto isso.
Não no nível do banco de dados, sem implementar isso por lógica de aplicação, e aí pode ter sido feito de várias maneiras, entre elas aquelas que mencionamos: coluna extra para ocultar, view, etc…
Você tem acesso ao código dessa aplicação e ao owner do schema do BD dela? Porque você não respondeu à pergunta que fiz, mas assumo que você não deve alterar a aplicação, e quer apenas entender como ela faz esse comportamento dos bloqueios e replicar ele e etc. Correto?
Sem você olhar código não vai ter como saber… nem simular o que está acontecendo.
25 de junho de 2010 às 8:25 pm #94827Maths
Participante[quote=”fsitja”:3uvmgwza]Acho que agora deu para entender… 😆
Mas, de qualquer forma, para conseguir simular o que está acontecendo lá vai depender de como foi implementado isso na aplicação.
Se fosse um locking de linha comum, com um “for update” na consulta de banco de dados, não estaria voltando coisa alguma até que o locking fosse liberado. Não dá para filtrar fora apenas as linhas que estão sendo usadas e trabalhar com as demais enquanto isso.
Não no nível do banco de dados, sem implementar isso por lógica de aplicação, e aí pode ter sido feito de várias maneiras, entre elas aquelas que mencionamos: coluna extra para ocultar, view, etc…
Você tem acesso ao código dessa aplicação e ao owner do schema do BD dela? Porque você não respondeu à pergunta que fiz, mas assumo que você não deve alterar a aplicação, e quer apenas entender como ela faz esse comportamento dos bloqueios e replicar ele e etc. Correto?
Sem você olhar código não vai ter como saber… nem simular o que está acontecendo.[/quote]
É isso mesmo, ou seja, nao terei como fazer isso a nao ser que eu olhe o codigo da aplicação, o que ela esta fazendo com aquela tabela ali certo?
-
AutorPosts
- Você deve fazer login para responder a este tópico.