[firebase-br] Otimização de Transação

Eduardo Jedliczka jedyfb em gmail.com
Sex Dez 4 00:58:37 -03 2009


Sei que vou pegar pesado, e desvirtual completamente o tópico.... mas...

tenho um cliente que trabalha com SAP R/3 integrado ao SQL Server, e por
uma questão de limitações na parte de compra, ele resolveu fazer uma
"customização" caseira acessando diretamente ao banco de dados.

resultado: o SAP detectava a alteração e invalidava  QUALQUER registro
inserido. Em alguns casos, quando eram alterados poucos campos, o SAP
conseguia "desfazer" a alteração no registro...

Para resolver o problema, este cliente contratou um consultor de SAP e
resolveu escrever o aplicativo em DOT.NET usando as Foundations Class do
SAP... ou seja, o SAP "enchergava" 100% das alterações.

Mas, e como funcionava a mágica...

o SAP possui algumas tabelas de auditoria que não podem ser lidas de
forma direta (a quantidade de registros inseridos nesta tabela não
corresponde à quantidade de registros nas outras tabelas... pode ter 100
registros na tabela de auditoria e ter entre 30 e 400 na tabela de
dados). Além disto todo registro possui um código verificador. (CRC)

Com isto, dá para saber se algum registro foi excluído ou modificado por
fora do sistema, mas... e como gerar esta tabela de auditoria de uma
maneira que o DBA não consiga descobrir o que precisa ser alterado ????

Será que uma tabela com uma estrutura fictícia (com registros de 1kb
distribuídos em vários campos) poderia ser usado para armazenar um
n-partes de um arquivo ZIP com todas as operações SQL inseridas por cada
terminal/usuário ou transação e ainda guardar um CRC por
registro/arquivo ? (VEJA BEM, ISTO NÃO PODE SER TRATADO VIA TRIGGER POIS
UM DBA PODERÁ DESCOBRIR A MÁGICA)

Na minha opinião, muitas coisas na vida são frágeis... e isto não impede
que tenhamos total confiança nelas... quer um exemplo ? quantos
caixa-eletrônicos existem espalhados em shoppings e postos de gasolina ?
quantos deles são propícios para assaltos e/ou sequestros ? e quantas
vezes nós utilizamos eles à noite sem nenhuma "otoridade" por perto ?

Outro exemplo ? já realizou pagamento de qualquer coisa por internet ?
se for pensar bem, isto é loucura... dá para usar um key logger e
descobrir a senha na origem, dá para "CLONAR" o site do banco, e
capturar os dados remotamente, dá para invadir o banco (ok é mais
difícil, mas tem doido que vende até lista de saldo bancário)... dá para
"grampear" algum provedor e tentar quebrar a proteçao por força bruta...
etc...

Banco de dados ou "Qualquer Servidor"   é a mesma coisa... se o
"criminoso" tem acesso ao banco.... abraço! Se tem acesso físico ao
computador (para espetar um pen-drive)...abraço! Se o backup fica
exposto na rede....abraço!

ou impede todo mundo de entrar na sala, de copiar o banco, de acessar ao
banco por fora do sistema, ou.... abraço! Mas, nem todos os clientes
concordam com esta regra, neste caso.... abraço!

Sem mais,

Eduardo Jedliczka

Em Qui, 2009-12-03 às 17:34 -0200, Kleber Caneva escreveu:
> Acho que essa discussão está partindo pra um beco sem saida.
> 
> Digamos que vc poderia colocoar uma TG para não permitir exclusão. Alguem 
> vem e diz que se tiver acesso ao banco pode inativar a TG, apagar e ativar 
> novamente.
> 
> Eu digo que mesmo que você consiga impedir a exclusão e manter o codigo 
> sequencial, ainda assim um DBA pode não excluir o registro, mas alterá-lo 
> invalidando as informações. Ai vem alguem e diz que vamos criar um CRC do 
> registro pra garantir a idoneidade das informações.
> 
> []´s
> 
> Kléber Caneva.
> 
> 
> 
> ----- Original Message ----- 
> From: "Luis" <luisfirevb em gmail.com>
> To: "'FireBase'" <lista em firebase.com.br>
> Sent: Thursday, December 03, 2009 1:51 PM
> Subject: [firebase-br] RES: RES: RES: Otimização de Transação
> 
> 
> O problema não é via aplicativo, mas sim acesso direto pelo DB.
> Quem pode garantir ou impedir que alguém com acesso ao DB exclua um registro
> ou apague qualquer rastro da exclusão desse registro? Sem ter uma numeração
> sequencial, acredito que seja impossível.
> 
> Mesmo que o próprio DB fosse capaz de gerar os tais logs, quem tem o acesso
> ao DB para exclusão (Admin) por exemplo, poderia igualmente excluir os logs
> e daria no mesmo.
> 
> Luis
> 
> -----Mensagem original-----
> De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
> nome de Alessandro Morais
> Enviada em: quinta-feira, 3 de dezembro de 2009 13:46
> Para: FireBase
> Cc: FireBase
> Assunto: Re: [firebase-br] RES: RES: Otimização de Transação
> 
> Mas acredito que a solução seriam os logs e não permissão de
> exclusão dos registros e sim inativacao dos mesmos.
> Abraços
> 
> Enviado de meu iPhone
> 
> Em 03/12/2009, às 13:20, Luis <luisfirevb em gmail.com> escreveu:
> 
> > Quem disse que é "Auditoria de Sistema = informática"?
> > Leia melhor antes de responder colega, disse ..." Trabalho com
> > auditoria de
> > normas técnicas" isso é PBQP-H, ISSO-9001, PROBARE entre outras e
> > não tem
> > relação direta com informática, mas sim com você excluir um
> > registro de
> > controle exigido pela norma, por isso a numeração sempre deve ser se
> > quencial
> > ok?
> >
> > Antes de responder e criticar como "Berçário", entenda o que leu é
> > mais
> > profissional.
> >
> > Luis
> >
> >
> > -----Mensagem original-----
> > De: lista-bounces em firebase.com.br [mailto:lista-
> > bounces em firebase.com.br] Em
> > nome de RM
> > Enviada em: quinta-feira, 3 de dezembro de 2009 11:44
> > Para: FireBase
> > Assunto: Re: [firebase-br] RES: Otimização de Transação
> >
> > Auditoria e Controle...
> >
> > Isso só existe se no mínimo todas as alterações/modificações do
> > banco sejam
> > registradas por mecanismo de LOG (Isso sim seria auditoria do DB)...
> >
> > Menos que isso é coisa de berçário...
> >
> >
> > t++
> >
> > --------------------------------------------------
> > From: "Luis" <luisfirevb em gmail.com>
> > Sent: Thursday, December 03, 2009 9:24 AM
> > To: "'FireBase'" <lista em firebase.com.br>
> > Subject: [firebase-br] RES:  Otimização de Transação
> >
> >> Sandro bom dia.
> >>
> >> No meu caso isso não é perfumaria, muito pelo contrário. Porém mi
> >> nha
> >> necessidade é um pouco diferente. Não se trata de reaproveitamento
> >>  dos
> >> números ou preenchimento de lacunas, mas não deixar a sequência se
> >>  quebrar
> >> explico.
> >>
> >> Trabalho com auditoria de normas técnicas e a gestão das mesmas im
> >> plica em
> >> rastreabilidade. Sendo assim os controles realizados, devem
> >> obrigatoriamente
> >> seguir uma sequência sem lacunas, pois se houver lacunas pode ser
> >> assumido
> >> que houve exclusão de uma informação importante para ser ocultada,
> >>  mesmo
> >> que
> >> manualmente no banco. Assim essa numeração não pode "falhar". Exem
> >> plo: Um
> >> dos controles é reclamação de clientes, essas reclamações devem
> >> ser
> >> cadastradas e tem seu processo normalmente, com apuração, ações,
> >> aprovação
> >
> >> e
> >> verificação final de sua solução. Se houver uma falha um auditor
> >> pode
> >> entender como exclusão de informação crítica que compromete o
> >> sistema de
> >> controle e não certificar a empresa.
> >>
> >> Para evitar isso implementei justamente a forma mais viável, pegar
> >>  sempre
> >> o
> >> último código cadastrado e somar + 1, se na hora de gravar alguém
> >> fez isso
> >> miléssimos de segundos antes, então haverá um erro retornável, o
> >> sistema
> >> interceptará e realizará nova tentativa + 2 e assim até conseguir
> >> gravar.
> >>
> >> Até hoje não encontrei outra solução mais viável que essa para
> >> evitar
> >> buracos na numeração.
> >>
> >> Luis
> >>
> >> -----Mensagem original-----
> >> De: lista-bounces em firebase.com.br [mailto:lista-
> >> bounces em firebase.com.br]
> >> Em
> >> nome de Sandro Souza
> >> Enviada em: quinta-feira, 3 de dezembro de 2009 02:15
> >> Para: FireBase; Josauro S. J.
> >> Assunto: Re: [firebase-br] Otimização de Transação
> >>
> >> Bom dia/tarde Josauro.
> >>
> >> No meu caso, faço tudo dentro de uma única transação, mas como v
> >> ocê
> >> mesmo citou, o problema de dois ou mais usuários tentarem utilizar o
> >> mesmo código devido à concorrência existe realmente. A única
> >> vantagem,
> >> no meu caso, é não necessitar de uma tabela de códigos
> >> reaproveitáveis,
> >> mas no restante, não foge dos problemas que você já está passan
> >> do.
> >>
> >> Como já foi citado várias vezes em outros posts, o uso de
> >> geradores/sequences poderia realmente resolver essa questão de
> >> concorrência, mas por outro lado, fugiria a reutilização de
> >> códigos como
> >> é o nosso caso.
> >>
> >> Uma outra abordagem poderia ser a seguinte:
> >>
> >> 1 - Todas as chaves estrangeiras seriam criadas utilizando a opção
> >>  "ON
> >> UPDATE CASCADE".
> >>
> >> 2 - Utilizaríamos geradores/sequences, e dessa forma, nas inclusõe
> >> s não
> >> reutilizaríamos mais os códigos excluídos, ganhando performance e
> >> nos
> >> livrando de problemas de concorrência no que se refere ao uso do m
> >> esmo
> >> código.
> >>
> >> 3 - Criaríamos uma stored procedure que seria acionada sempre que
> >> desejássemos encontrar essas "brechas" de código em cada uma das t
> >> abelas
> >> dos nossos bancos, e encontrando-as, executaria UPDATEs nesses campos
> >> chaves para efetuar as "correções" e rearrumar os códigos para dei
> >> xar
> >> tudo sequencial e sem essas "brechas". Como as chaves estrangeiras
> >> teriam sido criadas com a opção "ON UPDATE CASCADE" (item 1), esses
> >> mesmos códigos nas tabelas filhas/detalhes seriam automaticamente
> >> alinhados/ajustados pelo próprio banco. Para caad tabela que sofreu
> >> ajustes de código, seu respectivo gerador/sequence também seria
> >> reajustado.
> >>
> >> Dessa forma, eu acredito que teriamos uma forma melhor de conseguir o
> >> que pretendemos.
> >>
> >> Sei que o fato de deixar essas "brechas" de código não tem realme
> >> nte
> >> qualquer impacto negativo no sistema, que viveria tranquilamente com
> >> isso, e que essa necessidade de manter todos os códigos em ordem
> >> sequencial e sem "brechas" é apenas questão de gosto pessoal,
> >> "perfumaria" ou simplesmente ter a sensação de que tudo está organ
> >> izado
> >> no banco, e que só haveria necessidade real disso se por acaso
> >> tivéssemos tabelas com tantos registros que poderia acontecer de e
> >> sgotar
> >> os valores disponíveis para os campos chaves.
> >>
> >> No meu caso específico, assumo que se trata apenas de gosto pessoa
> >> l mesmo.
> >>
> >> Josauro, o que você acha dessa nova abordagem?
> >>
> >> Espero ter ajudado mais que atrapalhado. :D
> >>
> >> Josauro S.J. escreveu:
> >>
> >>
> >> ______________________________________________
> >> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> >> Para saber como gerenciar/excluir seu cadastro na lista, use:
> >> http://www.firebase.com.br/fb/artigo.php?id=1107
> >> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >>
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> > http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> >
> >
> > ______________________________________________
> > FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> > Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> > Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> E-mail verificado pelo Terra Anti-Spam.
> Para classificar esta mensagem como spam ou não spam, visite
> http://ecp.terra.com.br/cgi-bin/reportspam.cgi?+_d=SCY0NDU0NzM0I3Blcm0hdGVycmEmMSwxMjU5ODU1NjQ1Ljk2NzUyLjE3MjMzLnRyaWJ1bmUudGVycmEuY29tLDEzMDQ1TerraMail
> Verifique periodicamente a pasta Spam para garantir que apenas mensagens
> indesejadas sejam classificadas como Spam.
> 
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa






Mais detalhes sobre a lista de discussão lista