Algem já perdeu dados
e ai meu povo blzzz...
nos sistemas mais robustos que faço eu costumo usar o MySQL
porem em um sistema de Factoring eu usei o firebird.... e tenho
o seguinte problema
queda de energia normalmente some os 2 ou 3 ultimas coisas que eu
tenha gravado.... e asvezes trava a tabela tambem e tenho que destruila e voltar o bkp....
alguma luzz...?
nos sistemas mais robustos que faço eu costumo usar o MySQL
porem em um sistema de Factoring eu usei o firebird.... e tenho
o seguinte problema
queda de energia normalmente some os 2 ou 3 ultimas coisas que eu
tenha gravado.... e asvezes trava a tabela tambem e tenho que destruila e voltar o bkp....
alguma luzz...?
Mysys
Curtidas 0
Respostas
Afarias
11/03/2004
Se vc não tem um no-break, configure o banco para forced-writes::
gfix -write sync -user sysda -pass sua_senha seu_banco.gdb
T+
gfix -write sync -user sysda -pass sua_senha seu_banco.gdb
T+
GOSTEI 0
Skaarj
11/03/2004
Uma dica cara é voce mudar a escrita padrao de síncrona para assíncrona, assim ele forçará os dados irem para o disco diretamente e nao esperar um commit para enviar das páginas para o disco
[o problema da escrita sicrona se agrava em ambientes Microsoft, pois estes nao respeito o commit do banco e resolvem enviar para o disco esses dados apenas quando o time out da página for o do sistema, é melhor usar sistemas UNIX ou baseados nele, pois assim será respeitado o pedido do banco]
Em uma escrita síncrona a performace superior a assíncrona [arff.. corrija o tamanho da partição swap que voce supera isso] e também cuidado com seus esquemas de backup ao modificar a escrita.
[b:9323f0d155]Ativar escrita síncrona[/b:9323f0d155]
gfix -write sync database.gdb
[b:9323f0d155]Ativar escrita assíncrona[/b:9323f0d155]
gfix -write async database.gdb
[o problema da escrita sicrona se agrava em ambientes Microsoft, pois estes nao respeito o commit do banco e resolvem enviar para o disco esses dados apenas quando o time out da página for o do sistema, é melhor usar sistemas UNIX ou baseados nele, pois assim será respeitado o pedido do banco]
Em uma escrita síncrona a performace superior a assíncrona [arff.. corrija o tamanho da partição swap que voce supera isso] e também cuidado com seus esquemas de backup ao modificar a escrita.
[b:9323f0d155]Ativar escrita síncrona[/b:9323f0d155]
gfix -write sync database.gdb
[b:9323f0d155]Ativar escrita assíncrona[/b:9323f0d155]
gfix -write async database.gdb
GOSTEI 0
Afarias
11/03/2004
|Uma dica cara é voce mudar a escrita padrao de síncrona para
|assíncrona, assim ele forçará os dados irem para o disco diretamente
Ao contrário -- em síncrona é q os dados são gravados no meio físico
|e nao esperar um commit para enviar das páginas para o disco
Quaisquer dos modos de escrita não estão associados ao controle de transações
|[o problema da escrita sicrona se agrava em ambientes Microsoft, pois
|estes nao respeito o commit do banco e resolvem enviar para o disco
|esses dados apenas quando o time out da página for o do sistema, é
|melhor usar sistemas UNIX ou baseados nele, pois assim será
|respeitado o pedido do banco]
Acredito e é minha experiência q em UNIX ou Windows o comportamento é semelhante -- e como disse, a escrita das páginas não tem influência do controle de transação -- um COMMIT não manda gravar nada, apenas atualiza o ´status´ dos registros.
|Em uma escrita síncrona a performace superior a assíncrona [arff..
Ao contrário!! -- vc está certo, mas apenas trocou os nomes (modos)! ;)
Ativar escrita síncrona
gfix -write sync database.gdb
Ativar escrita assíncrona
gfix -write async database.gdb
T+
|assíncrona, assim ele forçará os dados irem para o disco diretamente
Ao contrário -- em síncrona é q os dados são gravados no meio físico
|e nao esperar um commit para enviar das páginas para o disco
Quaisquer dos modos de escrita não estão associados ao controle de transações
|[o problema da escrita sicrona se agrava em ambientes Microsoft, pois
|estes nao respeito o commit do banco e resolvem enviar para o disco
|esses dados apenas quando o time out da página for o do sistema, é
|melhor usar sistemas UNIX ou baseados nele, pois assim será
|respeitado o pedido do banco]
Acredito e é minha experiência q em UNIX ou Windows o comportamento é semelhante -- e como disse, a escrita das páginas não tem influência do controle de transação -- um COMMIT não manda gravar nada, apenas atualiza o ´status´ dos registros.
|Em uma escrita síncrona a performace superior a assíncrona [arff..
Ao contrário!! -- vc está certo, mas apenas trocou os nomes (modos)! ;)
Ativar escrita síncrona
gfix -write sync database.gdb
Ativar escrita assíncrona
gfix -write async database.gdb
T+
GOSTEI 0
Skaarj
11/03/2004
HAHAH!!
Foi malz ae..
[vlw por lembrar cara, sabado ia ter que falar sobre isso e ia pagar mico [viu o que dá achar que possui a verdade absoluta e nao rever a literatura ]] :oops:
Foi malz ae..
[vlw por lembrar cara, sabado ia ter que falar sobre isso e ia pagar mico [viu o que dá achar que possui a verdade absoluta e nao rever a literatura ]] :oops:
GOSTEI 0
Mysys
11/03/2004
desculpe mas eu tenho mais experiencia com MySQL
forced-writes é exatamente oque...?
forced-writes é exatamente oque...?
GOSTEI 0
Afarias
11/03/2004
|forced-writes é exatamente oque...?
forced-writes = escrita síncrona
Quando o banco de dados está em escrita assíncrona (NÃO está em forced-writes), as informações são gravadas em um buffer do SO -- e gravadas definitivamente para o disco de acordo com uma ´otimização´ (ecolha) do SO
Isso é ótimo para performance -- mas só deve ser usado com bons servidores, ou seja:: um servidor estável, usando um bom SO (WindowsNT/2000 ou Linux por exemplo) e de preferência com um sistema UPS (no-break)
Pq?? Pq, pelo fato dos dados não estarem sempre ´fisicamente´ gravados, um travamento repentino do SO ou uma queda de energia, pode fazer q os dados do buffer sejam perdidos (e assim, páginas de registro sejam perdidas, podendo causar corrupção no banco de dados)
Falando em corrupção do banco de dados, verifique se seu banco não está corrompido antes de qualquer coisa::
gfix -v -f seu_banco.gdb
e se estiver, faça a correção e então faça um backup e restaure.
T+
forced-writes = escrita síncrona
Quando o banco de dados está em escrita assíncrona (NÃO está em forced-writes), as informações são gravadas em um buffer do SO -- e gravadas definitivamente para o disco de acordo com uma ´otimização´ (ecolha) do SO
Isso é ótimo para performance -- mas só deve ser usado com bons servidores, ou seja:: um servidor estável, usando um bom SO (WindowsNT/2000 ou Linux por exemplo) e de preferência com um sistema UPS (no-break)
Pq?? Pq, pelo fato dos dados não estarem sempre ´fisicamente´ gravados, um travamento repentino do SO ou uma queda de energia, pode fazer q os dados do buffer sejam perdidos (e assim, páginas de registro sejam perdidas, podendo causar corrupção no banco de dados)
Falando em corrupção do banco de dados, verifique se seu banco não está corrompido antes de qualquer coisa::
gfix -v -f seu_banco.gdb
e se estiver, faça a correção e então faça um backup e restaure.
T+
GOSTEI 0