inacreditÁvel

Olá,

Eu so nao consegui entender ainda o porque dos lock e qual o motivo teria pra fazer uma tabela auxiliar, iria dar o mesmo problema.
Exemplo:

Eu estou incluindo um novo registro no banco. Até que eu commit essa minha insercao este registro nao existe para os demais, nesse caso o Oracle nao da lock de nada.
Se eu vou fazer update em um registro, os outros 1 milhao de usuarios irao ver uma foto deste registro antes de eu comecar a alteracao, e apos eu dar commit todos comecarao e ver o que foi alterado.
Em nenhum desses casos o Oracle trava consulta aos registros, agora se o problema é que dois usuarios nao conseguem alterar o mesmo registro ao mesmo tempo, obvio que nao vai dar e obvio que com tabela auxiliar irá ocorrer a mesma coisa.

Estou falando isso com o Oracle funcionando de maneira normal, a nao ser que alguem mudou as configuracoes das transacoes (o que é possivel), mas nesse caso voces deveriam descobrir quem fez isso e dar um premio pra pessoa.

]['s

Claudio, Mister_m,

Ainda não consegui usar as sequences para me trazer uma sequencia do segundo campo, vejam porque:

10, 1
10, 2
10, 4
11,1
11,2
11,5
12,2
12,3

Eu não consigo reiniciar a sequence, veja que a cada sequencia aumentada no campo 1, o campo 2 reinicia as sequências, é isso que ta me matando.

Sequence não vai dar certo neste caso, certo?

Lembrando, sem trigger, procedures, com isso daria pra fazer.

Fábio,

A idéia da tabela auxiliar, era que locariamos somente ela, tu tacerto, vai correr o mesmo problema, mas é melhor locar uma tabela apenas sem relacionamentos, do que a minha tabela princiapl onde exitem n relacionamentos, o sistema ia parar total, enquanto na auxiliar o problema seria somente gerenciar essa fila de locks

[quote=skill_ufmt]Ainda não consegui usar as sequences para me trazer uma sequencia do segundo campo, vejam porque:

10, 1
10, 2
10, 4
11,1
11,2
11,5
12,2
12,3

Eu não consigo reiniciar a sequence, veja que a cada sequencia aumentada no campo 1, o campo 2 reinicia as sequências, é isso que ta me matando.[/quote]

As sequences são totalmente controladas por você, skill, e se elas estão sendo reiniciadas é porque seu código faz isso. Como você está usando as sequences neste caso?

Então mister, o gerenciamento era feito por uma SELECT MAX, mas como disse isso me ferro agora geral, preciso de uma solução para gerenciar isso, essas reinicialização de sequencias.

Nas outras tabelas como são uma chave só funciona blz o sequence do oracle.
A propósito, fiz os teste e realmente posso ter duas sequences, na mesma tabela, mas ela semrpe me retornam o mesmo valor nas duas fazendo daquele jeito:

select sequence1, sequence2 from dual

O que não ta me servindo.

Se que o problema é a peça aqui que não manja de DBA ehehe mas deve ter sim como fazer.

Me permite chegar ao nível de pedir que coloque um exemplo da sua sequence onde você precisa fazer isso?
como é que eu faço minha sequence1 retornar o primeiro campo, e o sequence2 retornar somente para o segundo campo, isso lembrando que a cada nextval no campo1, preciso reiniciar a sequence no campo 2?

Peraí, você disse antes nessa thread que não precisava reiniciar o segundo campo, que ele somente precisava aumentar a cada select. Mudou isso agora?

[quote=mister__m]

Peraí, você disse antes nessa thread que não precisava reiniciar o segundo campo, que ele somente precisava aumentar a cada select. Mudou isso agora?[/quote]

Se eu disse, me perdoe, mas o meu problema é justamente ter que reiniciar o segundo campo :smiley:

Diga um caso de negócio que justifique isso :slight_smile:

Cara hehe, nem me fale nada kkk, to p demais com os ana…

Meu problema todo gira em torno disso:

Vamso supor que eu tenha um processo criminal em que o cara vai ser julgado por homicidio, furto, estupro, esse processo é inserido nessa chave composta assim por exemplo: 10 , 2 onde esse primeiro campo seria o número do processo, e o segundo, uma sequencia deste processo.

Acontece que esse processo pode ser repartido na justiça para se julgar os casos em separado, ou seja, vou ter 3 novos processos um para cada caso, onde oque será incrementado é apenas a sequenciado segundo campo, ficando assim:

10,2 normal
10,3 estupro
10,4 furto
10,5 homicio

isso acontece repetidas vezes e para vários processos dai surgem o problema de ter que reinicializar esta sequencia, na verdade eu preciso sempre de um numero maior ao que já está lá no processo normal.

10,2 normal
10,3 estupro
10,4 furto
10,5 homicio
11,3 normal
11,4 duplo-homicido
11,5 latrocinio
13,5 normal
13,6 roubo
13,7 estelionato

Definiram isso na versão 1, e por incrinvel qeu pareça, foi bugar somente agora no meu último dia kkk
Sou sortudo pacas :slight_smile:

Tava vendo o seguinte código:

insert into s_dept([color=red]id[/color],name,region_id)
values ([color=red]s_dept_id.NEXTVAL[/color],‘FINANCE’,2);

há como usar o sequence para o segundo ID: ex.

insert into s_dept(id,name,[color=red]region_id[/color])
values (2,‘FINANCE’,[color=red]s_dept_id.NEXTVAL[/color]);

ou ainda?

insert into s_dept([color=red]id[/color],name,[color=red]region_id[/color])
values ([color=red]s_dept_id.NEXTVAL[/color],‘FINANCE’,[color=red]s_dept_id.NEXTVAL[/color]);

Os DBAs e analistas dai são fraquinhos em… Hoje em dia não usar surrogate key é dose. Pelo que eu entendi eles estão usando uma natural key como primary key, isso é burrada das grandes.

O correto seria manter uma coluna só com a surrogate key, criar 1 FK para a atual primeira coluna da PK e criar uma chave natural com esse sequênciamento de processos. Simples como executar o seguinte sql…

update t set t.seq = (select isnull(max(*), 0)+1 from t as tt where t.fk = tt.fk and t.pk > tt.pk)

Você não pode simplesmente criar um método que faça essa distribuição de processo?
Por exemplo um método que receba a sequência do processo e a quantidade em quantos será dividido, e retorne a sequência pra vc inserir?

Fala skill_ufmt.

Cara, em alguns momentos (Emergência) é necessário fazer algumas gambiarras.
Não posso ajudar muito quanto a java, pois ainda não tenho conhecimento muito elevado, mas trabalhamos com oracle aqui.

Quando eu falo de gambiarra eu falo em criar uma procedure ou function e ir direto no banco fazer o que vc precisa.
Usando procedures e functions vc pode utilizar tudo que o oracle pode te oferecer.

numa procedure ou function vc pode utilizar, por exemplo, o AUTONOMOUS_TRANSACTION, e assim já se preocupar um pouco menos com locks e etc.

[quote=louds]

update t set t.seq = (select isnull(max(*), 0)+1 from t as tt where t.fk = tt.fk and t.pk > tt.pk) [/quote]

Pois é, louds, grande CO, isso veio do começo das aplicações java aqui, se não me engano este foi o primeiro sistema desenvolvido aqui e o pessoal tava migrande de outras linguagens ou iniciando, tem cada merda no código que nem te conto heheh
Mais é inviável refazer a coisa toda, e o cliente também não adimite isso :frowning:
Naquela éopoca, acredito que nem DBA tinha como tbm não tem, como você está vendo, eu que to correndo pra ver se arrumo uam solução, hoje sou dba, analista, desenvolvedor e etc hehe

[quote=Rafael Nunes]Você não pode simplesmente criar um método que faça essa distribuição de processo?
Por exemplo um método que receba a sequência do processo e a quantidade em quantos será dividido, e retorne a sequência pra vc inserir?[/quote]

Rafael, meu problema não é bem esse, isso faz tranquilo, o negócio é que quem tem que gerenciar essa chaves para mim é o banco, se eu deixar minha aplicação gerenciar as chaves, vai dar bug, que é o que está correndo agora.

Pode ocorrer de dois usuários pegar chaves iguais, e ai o bicho pega meu amigo hehe

Tudo bom Salgado?

O cliente proibe uso de trigger e procedures, acredito que seja isso que você esteja falando, certo?

Há restrições nos projetos desse cliente quanto ao uso disso, pelo que foi me passado isso é bem pesado para o banco fazer, e imagina 10000 ao mesmo tempo, 30000, 100000 …
Não sei te falar certamente o motivo, só sei que existe essa restrição.

Cara, acho que o Oracle aguenta.
Mas quem manda é o cliente.

Se eu tiver alguma ideia volto a postar.

Abraço e boa sorte

[quote=skill_ufmt]Acontece que esse processo pode ser repartido na justiça para se julgar os casos em separado, ou seja, vou ter 3 novos processos um para cada caso, onde oque será incrementado é apenas a sequenciado segundo campo

Isso acontece repetidas vezes e para vários processos dai surgem o problema de ter que reinicializar esta sequencia, na verdade eu preciso sempre de um numero maior ao que já está lá no processo normal.
[/quote]

Eu entendi sua explicação, mas daí ao segundo número ter que ser zerado com base no primeiro, não faz sentido ainda.

[quote=mister__m]
Eu entendi sua explicação, mas daí ao segundo número ter que ser zerado com base no primeiro, não faz sentido ainda.[/quote]

ser zerado a cada campo 1 novo?

Tu ta dizendo o seguinte, que eu poderia mudar o campo1, mas continuar a sequencia do campo dois, certo? dai eu teria:

10,2
10,3
10,4
11,5
11,6
11,7

Caras, como já cai neste buraco mesmo, como vocês costumam fazer esse tipo coisa, nunca usando chave compostas? usam uma chave pk e a composta como natural, como alguém citou aqui? enfim, qual a melhor maneira de se não usar algo assim, quando se tme um caso desse?

[quote=skill_ufmt]Tu ta dizendo o seguinte, que eu poderia mudar o campo1, mas continuar a sequencia do campo dois, certo? dai eu teria:

10,2
10,3
10,4
11,5
11,6
11,7
[/quote]

Exato. Serve?

[quote=skill_ufmt]Caras, como já cai neste buraco mesmo, como vocês costumam fazer esse tipo coisa, nunca usando chave compostas? usam uma chave pk e a composta como natural, como alguém citou aqui? enfim, qual a melhor maneira de se não usar algo assim, quando se tme um caso desse?
[/quote]

Tem que usar uma chave surrogate. Jamais use uma chave natural como chave primária.

Se tu relamente precisa reiniciar o segundo campo não poderia fazer primeiro um insert com o campo zerado e depois um update do select max, na mesma transação?

Dependendo da configuração do banco e da aplicação até poderia dar duplicate key no primeiro insert, a não ser que o insert de um lock de tabela…

Acho que uma solução parecida já tinha sido mencionada no início da thread…