Após uma compactação do Sybase (15.0.3) despejar um banco de dados na plataforma original - Solaris Sparc 64 - com todas as etapas necessárias (até mesmo a etapa quiesce), tentei carregá-lo no meu Sybase (15.7) Solaris x64 (executando sob vmware), [tamanhos de página iguais em ambos os sistemas !!!] e recebi este erro:
1> load database wfcv2 from "compress::1::/20120412_wfcv2_zdump"
2> go
Backup Server session id is: 28. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.132.1.1: Attempting to open byte stream device:
'compress::1::/20120412_wfcv2_zdump::000'
Backup Server: 4.177.2.1: The database page size of 2048 bytes obtained from ASE
is different from the database page size of -1024 bytes read from the dump
header. The LOAD session must exit.
Backup Server: 1.14.2.2: Unrecoverable I/O or volume error. This DUMP or LOAD
session must exit.
Backup Server: 6.32.2.3: compress::1::/20120412_wfcv2_zdump::000: volume not
valid or not requested (server: , session id: 28.)
Backup Server: 1.14.2.4: Unrecoverable I/O or volume error. This DUMP or LOAD
session must exit.
Msg 8009, Level 16, State 1:
Server 'MYSERVER', Line 1:
Error encountered by Backup Server. Please refer to Backup Server messages for
details.
Sugestões?
Pergunta de PHILL: Você pode postar a saída de: carregar banco de dados wfcv2 de "compress::1::/20120412_wfcv2_zdump" com headeronly e carregar banco de dados wfcv2 de "compress::1::/20120412_wfcv2_zdump" com listonly=full – Phil
1> load database wfcv2 from "compress::1::/20120412_wfcv2_zdump" with headeronly
2> go
Backup Server session id is: 31. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.132.1.1: Attempting to open byte stream device:
'compress::1::/20120412_wfcv2_zdump::000'
Backup Server: 4.177.2.1: The database page size of 2048 bytes obtained from ASE
is different from the database page size of -1024 bytes read from the dump
header. The LOAD session must exit.
Backup Server: 1.14.2.2: Unrecoverable I/O or volume error. This DUMP or LOAD
session must exit.
Msg 8009, Level 16, State 1:
Server 'MYSERVER', Line 1:
Error encountered by Backup Server. Please refer to Backup Server messages for
details.
1>
2>
3> load database wfcv2 from "compress::1::/20120412_wfcv2_zdump" with listonly=full
4> go
Backup Server session id is: 33. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.22.1.1: Option LISTONLY is not valid for device
'compress::1::/20120412_wfcv2_zdump::000'.
Msg 8009, Level 16, State 1:
Server 'MYSERVER', Line 3:
Error encountered by Backup Server. Please refer to Backup Server messages for
details.
1>
2>
3>
Backup Server messages
-------------------------------------------------------------------------------------------------------------------------
Apr 12 11:38:00 2012: Backup Server: 2.23.1.1: Connection from Server MYSERVER on Host MyMachine with HostProcid 3776.
Apr 12 11:38:00 2012: Backup Server: 4.132.1.1: Attempting to open byte stream device: 'compress::1::/20120412_wfcv2_zdump::000'
Apr 12 11:38:00 2012: Backup Server: 4.177.2.1: The database page size of 2048 bytes obtained from ASE is different from the database
page size of -1024 bytes read from the dump header. The LOAD session must exit.
Apr 12 11:38:00 2012: Backup Server: 1.14.2.2: Unrecoverable I/O or volume error. This DUMP or LOAD session must exit.
Apr 12 11:38:18 2012: Backup Server: 2.23.1.1: Connection from Server MYSERVER on Host MyMachine with HostProcid 3776.
Apr 12 11:38:18 2012: Backup Server: 4.22.1.1: Option LISTONLY is not valid for device 'compress::1::/20120412_wfcv2_zdump::000'.
Pergunta/comentário de PHILL: Na verdade, acho que é a sua sintaxe. O tamanho do bloco -1024 é uma pista falsa. Tente: carregue o banco de dados wfcv2 de "compress::/20120412_wfcv2_zdump" - Em qual diretório está 20120412_wfcv2_zdump? Está realmente no diretório raiz (/) da sua caixa? Se não, altere o caminho. – Phil
1) Eu tentei sua sugestão e recebi o mesmo erro!
2) Como a máquina onde estou tentando carregar o dump, é minha máquina de teste (e não tenho mais espaço disponível em nenhum lugar...), estou usando a localização /(root) para colocar o arquivo dump para carregamento. Sim, não é a coisa certa a fazer, mas como afirmei "não há espaço livre disponível!".
Pergunta/comentário de PHILL: A sintaxe LOAD está incorreta.
Você não deve especificar o nível de compactação entre os pares de: caracteres no comando LOAD DATABASE.
Supondo que seu arquivo dump esteja no sistema de arquivos local em /20120412_wfcv2_zdump, seu comando load deve ser:
1> carregue o banco de dados wfcv2 de "compress::/20120412_wfcv2_zdump" 2> vá
A Sybase recomenda a opção nativa "compression = compress_level" como preferida em relação à opção mais antiga "compress::compression_level". Se você usar a opção nativa para o banco de dados de despejo, não precisará usar "compress::compression_level" ao carregar seu banco de dados.
Conforme declarado, a sybase recomenda!
Eu sei que a sintaxe de carregamento está correta e funciona - por experiência própria. Ontem consegui carregar outros BDs do mesmo servidor de origem para MyMachine. Apenas este DB que está acima de 10 GB de espaço (+/- 2GB compactado...), está causando problemas...
Pergunta/comentário de PHILL: Tem certeza de que ocorreu o mesmo erro? O nome do arquivo está correto? Qual é a saída de ls -al /20120412_wfcv2_zdump ? Você pode precisar chmod 777 /20120412_wfcv2_zdump it – Phil
1) Sim, o nome está correto!
2) Não é um problema de permissões. Estou usando o usuário root para tudo (sim, não é a coisa certa a fazer, mas como afirmei, esta é minha máquina de teste pessoal!).
Pergunta/comentário de PHILL: Ok, li o manual novamente. O formato de carregamento é definitivamente carregar o banco de dados wfcv2 de "compress::/20120412_wfcv2_zdump" para volumes compactados e não "compress::1::/ ... - Por favor, poste a saída do erro gerado por isso para que eu possa ver (eu sei você afirmou que tentou, mas eu gostaria de dar uma olhada de qualquer maneira).
OK ! Aqui vai ! ... E a resposta para "você ftp o arquivo em ASCII" é NÃO ! Obrigado de qualquer maneira!
1>
2>
3> load database wfcv2 from "compress::/20120412_wfcv2_zdump"
4> go
Backup Server session id is: 35. Use this value when executing the
'sp_volchanged' system stored procedure after fulfilling any volume change
request from the Backup Server.
Backup Server: 4.132.1.1: Attempting to open byte stream device:
'compress::/20120412_wfcv2_zdump::000'
Backup Server: 4.177.2.1: The database page size of 2048 bytes obtained from ASE
is different from the database page size of -1024 bytes read from the dump
header. The LOAD session must exit.
Backup Server: 1.14.2.2: Unrecoverable I/O or volume error. This DUMP or LOAD
session must exit.
Backup Server: 6.32.2.3: compress::/20120412_wfcv2_zdump::000: volume not valid
or not requested (server: , session id: 35.)
Backup Server: 1.14.2.4: Unrecoverable I/O or volume error. This DUMP or LOAD
session must exit.
Msg 8009, Level 16, State 1:
Server 'MYMACHINE', Line 3:
Error encountered by Backup Server. Please refer to Backup Server messages for
details.
Acredito que a resposta para todo esse problema pode ser a resposta mais simples: - Corrupção de dados ... !
Por via das dúvidas, farei outro despejo e tentarei carregá-lo novamente!
Phill, obrigado pelo seu tempo! ;-)
1) Definitivamente, houve um problema de corrupção causado por um problema com as ferramentas vmware no solaris 10. Quando a interface de rede tinha altas operações de transferência/carregamento (exemplo: cópia de um banco de dados de 2 GB ....), ela simplesmente parou de funcionar, em meio da operação. Para colocar a interface funcionando novamente, tive que desconectar e conectar a interface de rede novamente (na interface vmware!). Basicamente, tive que desinstalar as ferramentas vmware na máquina virtual solaris. Havia um problema, as taxas de transferência mais altas que poderiam ser alcançadas eram de cerca de 300 Kb. Basicamente, eu poderia levar horas para realizar uma simples transferência ftp de um banco de dados de 2 GB, mas não havia nenhuma corrupção. Como provar/testar que existe/não existe corrupção. Acabei de compactar (na máquina de origem) o despejo do banco de dados em um arquivo tar (sim, 20kb extras), mas após a conclusão do download, no servidor de destino,
2) Depois de ter certeza de que o dump estava ok, recebi um erro diferente:
Tive que configurar alguns parâmetros que estavam relacionados às operações de carregamento, como:
número de buffers de i/o grandes -> 32 memória máxima
Eu também tive que ajustar a Memória Compartilhada do Sistema Operacional para o mecanismo sybase...!
E finalmente consegui carregar o banco de dados (tamanho > 2,1 GB)!
;-) Felicidades !