Discussion:
failed to loading a dump
(too old to reply)
alexander
2009-10-02 17:12:47 UTC
Permalink
Hi, all!
I've encountered a problem while i was loading a dump.

Dump was performed with compress level 6.
after dump was ready it was uploded to another server where
we store our dumps via ftp.

Today i've downloaded the made dump back to ase server and
tried to loaded it. Failed.

I get such errors:

Backup Server session id is: 59. 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::/disk1/syb_data_dump/staging_20090930.dmp::00'
Backup Server: 6.28.1.1: Dumpfile name 'staging0927302C8D'
section number 1 mounted on byte stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Number (412402) Severity (2) State (1) Server (yulia_BS)
Procedure (bs_perform_load) Backup Server: 4.124.2.1:
Archive API error for
device='compress::/disk1/syb_data_dump/staging_20090930.dmp::00':
Vendor application name=Compress API, Library version=1, API
routine=syb_read(), Message=
Number (8009) Severity (16) State (1) Server (yulia) Error
encountered by Backup Server. Please refer to Backup Server
messages for details.

But if i perform load database with headeronly
i get this

Backup Server session id is: 57. 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::/disk1/syb_data_dump/staging_20090930.dmp::00'
Backup Server: 6.28.1.1: Dumpfile name 'staging0927302C8D'
section number 1 mounted on byte stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
This is a database dump of database ID 14, name 'staging',
from Sep 30 2009 3:10AM. SQL Server version: Adaptive
Server Enterprise/12.5.4/EBF 16831
ESD#9.1/P/x86_64/Enterprise Linux/ase1254/2146/64-bit/OP.
Backup Server version: Backup Server/12.5.4/EBF 16831
ESD#9.1/P/Linux AMD Opteron/Enterprise
Linux/ase1254/2510/64-bit/OPT. Database page size is
46909632811008.
Database contains 4864000 pages; checkpoint RID=(Rid pageid
= 0x42dd50; row num = 0xb); next object ID=841767025; sort
order ID=50, status=0; charset ID=53.
Database log version=6; database upgrade version=31.
segmap: 0x00000003 lstart=0 vstart=83886080 lsize=3840000
unrsvd=3421880
segmap: 0x00000004 lstart=3840000 vstart=100663296
lsize=1024000 unrsvd=1020000

I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from 'compress::/disk1/syb_data_dump/staging_20090930.dmp'
go
online database load_bkp
go
sp_dboption load_bkp, 'single user', false
go

I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which was
originaly made in ASE ESD8?

Thanks.
"Cory Sane [TeamSybase]" <cory!=sane>
2009-10-05 01:10:15 UTC
Permalink
Alexander,
Compress is very platform dependant. Are the two machines running the exact same Operating System?
Compress cannot be used for cross platform dump and load. i've tried and failed.

Going from ESD 9 to ESD#8 should be ok but not guaranteed. ASE 12.5.4 had some backupserver changes introduced.

FYI - the newer form of compression ("dump... with compression=6") is preferred by Sybase folks going forward.
You will get the benefit of greater support by switching. I switched 3+ yrs ago.
--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
Post by alexander
Hi, all!
I've encountered a problem while i was loading a dump.
Dump was performed with compress level 6.
after dump was ready it was uploded to another server where
we store our dumps via ftp.
Today i've downloaded the made dump back to ase server and
tried to loaded it. Failed.
Backup Server session id is: 59. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Backup Server: 6.28.1.1: Dumpfile name 'staging0927302C8D'
section number 1 mounted on byte stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Number (412402) Severity (2) State (1) Server (yulia_BS)
Archive API error for
Vendor application name=Compress API, Library version=1, API
routine=syb_read(), Message=
Number (8009) Severity (16) State (1) Server (yulia) Error
encountered by Backup Server. Please refer to Backup Server
messages for details.
But if i perform load database with headeronly
i get this
Backup Server session id is: 57. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Backup Server: 6.28.1.1: Dumpfile name 'staging0927302C8D'
section number 1 mounted on byte stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
This is a database dump of database ID 14, name 'staging',
from Sep 30 2009 3:10AM. SQL Server version: Adaptive
Server Enterprise/12.5.4/EBF 16831
ESD#9.1/P/x86_64/Enterprise Linux/ase1254/2146/64-bit/OP.
Backup Server version: Backup Server/12.5.4/EBF 16831
ESD#9.1/P/Linux AMD Opteron/Enterprise
Linux/ase1254/2510/64-bit/OPT. Database page size is
46909632811008.
Database contains 4864000 pages; checkpoint RID=(Rid pageid
= 0x42dd50; row num = 0xb); next object ID=841767025; sort
order ID=50, status=0; charset ID=53.
Database log version=6; database upgrade version=31.
segmap: 0x00000003 lstart=0 vstart=83886080 lsize=3840000
unrsvd=3421880
segmap: 0x00000004 lstart=3840000 vstart=100663296
lsize=1024000 unrsvd=1020000
I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from 'compress::/disk1/syb_data_dump/staging_20090930.dmp'
go
online database load_bkp
go
sp_dboption load_bkp, 'single user', false
go
I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which was
originaly made in ASE ESD8?
Thanks.
alexander
2009-10-05 07:11:34 UTC
Permalink
Thanks for respond.
Machines are identical, RHEL 5.3 64 bit. On both ASE 12.5.4
ESD#9.1 is installed, dump were made with 6 compression.
I've read that it could be because ftp transfers in ascii by
default, i didn't know about this. We store dumps on
different server (Win2003R2 32 bit ) on which i upload dumps
from linux servers via ftp. Few days ago i tried to load a
dump and received such error. I uploaded dump from win ftp
client in binary mode and this could cause a problem, but
then i downloaded a dump from linux in ascii mode. After
that i was managed to load one dump, but it was only once.
When i tried to restore other dumps i get such error.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Alexander,
Compress is very platform dependant. Are the two machines
running the exact same Operating System? Compress cannot
be used for cross platform dump and load. i've tried and
failed.
Going from ESD 9 to ESD#8 should be ok but not guaranteed.
ASE 12.5.4 had some backupserver changes introduced.
FYI - the newer form of compression ("dump... with
compression=6") is preferred by Sybase folks going
forward. You will get the benefit of greater support by
switching. I switched 3+ yrs ago.
--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
Post by alexander
I've encountered a problem while i was loading a dump.
Dump was performed with compress level 6.
after dump was ready it was uploded to another server
where we store our dumps via ftp.
Today i've downloaded the made dump back to ase server
and tried to loaded it. Failed.
Backup Server session id is: 59. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name
'staging0927302C8D' section number 1 mounted on byte
Post by alexander
stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Number (412402) Severity (2) State (1) Server (yulia_BS)
Archive API error for
device='compress::/disk1/syb_data_dump/staging_20090930.dm
Post by alexander
p::00': Vendor application name=Compress API, Library
version=1, API routine=syb_read(), Message=
Number (8009) Severity (16) State (1) Server (yulia)
Error encountered by Backup Server. Please refer to
Backup Server messages for details.
But if i perform load database with headeronly
i get this
Backup Server session id is: 57. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name
'staging0927302C8D' section number 1 mounted on byte
Post by alexander
stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
This is a database dump of database ID 14, name
Adaptive Server Enterprise/12.5.4/EBF 16831
ESD#9.1/P/x86_64/Enterprise
Backup Server/12.5.4/EBF 16831 ESD#9.1/P/Linux AMD
Opteron/Enterprise Linux/ase1254/2510/64-bit/OPT.
Database page size is 46909632811008.
Database contains 4864000 pages; checkpoint RID=(Rid
pageid = 0x42dd50; row num = 0xb); next object
ID=841767025; sort order ID=50, status=0; charset ID=53.
Database log version=6; database upgrade version=31.
segmap: 0x00000003 lstart=0 vstart=83886080
lsize=3840000 unrsvd=3421880
segmap: 0x00000004 lstart=3840000 vstart=100663296
lsize=1024000 unrsvd=1020000
I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from
'compress::/disk1/syb_data_dump/staging_20090930.dmp' go
online database load_bkp
go
sp_dboption load_bkp, 'single user', false
go
I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which was
originaly made in ASE ESD8?
Thanks.
Sherlock, Kevin [TeamSybase]
2009-10-05 18:39:28 UTC
Permalink
One thing to check is to make sure your $SYBASE/SYBASE.sh environment
variables are sourced before the backup server is started.

Something like:

. $SYBASE/SYBASE.sh
cd $SYBASE/$SYBASE_ASE/install
./startserver -f RUN_SYBBACKUP


I've seen where the backupserver is started without the correct environment
variables set and the compression libraries aren't found by backupserver
when attempting backup/restore. Or sometimes, the backup server is running
under a different account (like "root") where the environment for SYBASE is
not set.
Post by alexander
Thanks for respond.
Machines are identical, RHEL 5.3 64 bit. On both ASE 12.5.4
ESD#9.1 is installed, dump were made with 6 compression.
I've read that it could be because ftp transfers in ascii by
default, i didn't know about this. We store dumps on
different server (Win2003R2 32 bit ) on which i upload dumps
from linux servers via ftp. Few days ago i tried to load a
dump and received such error. I uploaded dump from win ftp
client in binary mode and this could cause a problem, but
then i downloaded a dump from linux in ascii mode. After
that i was managed to load one dump, but it was only once.
When i tried to restore other dumps i get such error.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Alexander,
Compress is very platform dependant. Are the two machines
running the exact same Operating System? Compress cannot
be used for cross platform dump and load. i've tried and
failed.
Going from ESD 9 to ESD#8 should be ok but not guaranteed.
ASE 12.5.4 had some backupserver changes introduced.
FYI - the newer form of compression ("dump... with
compression=6") is preferred by Sybase folks going
forward. You will get the benefit of greater support by
switching. I switched 3+ yrs ago.
--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
Post by alexander
I've encountered a problem while i was loading a dump.
Dump was performed with compress level 6.
after dump was ready it was uploded to another server
where we store our dumps via ftp.
Today i've downloaded the made dump back to ase server
and tried to loaded it. Failed.
Backup Server session id is: 59. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name
'staging0927302C8D' section number 1 mounted on byte
Post by alexander
stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Number (412402) Severity (2) State (1) Server (yulia_BS)
Archive API error for
device='compress::/disk1/syb_data_dump/staging_20090930.dm
Post by alexander
p::00': Vendor application name=Compress API, Library
version=1, API routine=syb_read(), Message=
Number (8009) Severity (16) State (1) Server (yulia)
Error encountered by Backup Server. Please refer to
Backup Server messages for details.
But if i perform load database with headeronly
i get this
Backup Server session id is: 57. 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
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name
'staging0927302C8D' section number 1 mounted on byte
Post by alexander
stream
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by alexander
This is a database dump of database ID 14, name
Adaptive Server Enterprise/12.5.4/EBF 16831
ESD#9.1/P/x86_64/Enterprise
Backup Server/12.5.4/EBF 16831 ESD#9.1/P/Linux AMD
Opteron/Enterprise Linux/ase1254/2510/64-bit/OPT.
Database page size is 46909632811008.
Database contains 4864000 pages; checkpoint RID=(Rid
pageid = 0x42dd50; row num = 0xb); next object
ID=841767025; sort order ID=50, status=0; charset ID=53.
Database log version=6; database upgrade version=31.
segmap: 0x00000003 lstart=0 vstart=83886080
lsize=3840000 unrsvd=3421880
segmap: 0x00000004 lstart=3840000 vstart=100663296
lsize=1024000 unrsvd=1020000
I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from
'compress::/disk1/syb_data_dump/staging_20090930.dmp' go
online database load_bkp
go
sp_dboption load_bkp, 'single user', false
go
I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which was
originaly made in ASE ESD8?
Thanks.
alexander
2009-10-06 10:59:53 UTC
Permalink
Thank you, Kevin.
SYBASE environment variables are set. ASE is installed in
/opt/sybase, so when i issued cd $SYBASE/$SYBASE_ASE and
then pwd i get /opt/sybase/ASE-12_5
I've stopped backupserver and then issued
/install/RUN_servername_BS
then i examined the BS log and found nothing special which
could signalize that BS server had not found something he
needs for correct work. And it's nothing to say all this
commands i issued under sybase user in rhel.
I also can say that i copied SYBASE.sh in /etc/profile.d and
make SYBASE.sh available for readind for sybase user.
In BS log i found nothing about incorrect run of dump
work(when dump database was performed). No signal that space
on hdd is insufficient or whatever else. So in this case i
think that my dumps are ok. The one thing that i think is
ftp. As i said i upload my dumps on another server via ftp,
and it was made in ascii mode as default mode of ftp
transfering. I have an sh script that opens an ftp
connection with win ftp service and then uploads dumps. Then
i downloaded dump from win server also in ascii mode on
another linux box and tried to load dump and failed. But one
dump i load. Maybe it depends on size of dumps. Dump that
i've loaded was not verry big, approximately 350 Kb. And now
i tried to load a dump wich is 7.5 Gb in size.
Post by Sherlock, Kevin [TeamSybase]
One thing to check is to make sure your $SYBASE/SYBASE.sh
environment variables are sourced before the backup
server is started.
. $SYBASE/SYBASE.sh
cd $SYBASE/$SYBASE_ASE/install
./startserver -f RUN_SYBBACKUP
I've seen where the backupserver is started without the
correct environment variables set and the compression
libraries aren't found by backupserver when attempting
backup/restore. Or sometimes, the backup server is
running under a different account (like "root") where the
environment for SYBASE is not set.
respond. Machines are identical, RHEL 5.3 64 bit. On
both ASE 12.5.4 ESD#9.1 is installed, dump were made
with 6 compression. I've read that it could be because
ftp transfers in ascii by default, i didn't know about
this. We store dumps on different server (Win2003R2 32
bit ) on which i upload dumps from linux servers via
ftp. Few days ago i tried to load a dump and received
such error. I uploaded dump from win ftp client in
binary mode and this could cause a problem, but then i
downloaded a dump from linux in ascii mode. After that i
was managed to load one dump, but it was only once. When
i tried to restore other dumps i get such error. >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Alexander,
Compress is very platform dependant. Are the two
machines >> running the exact same Operating System?
Compress cannot >> be used for cross platform dump and
load. i've tried and >> failed.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Going from ESD 9 to ESD#8 should be ok but not
guaranteed. >> ASE 12.5.4 had some backupserver changes
introduced. >>
Post by "Cory Sane [TeamSybase]" <cory!=sane>
FYI - the newer form of compression ("dump... with
compression=6") is preferred by Sybase folks going
forward. You will get the benefit of greater support by
switching. I switched 3+ yrs ago.
--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
Post by alexander
I've encountered a problem while i was loading a
dump. >> >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Dump was performed with compress level 6.
after dump was ready it was uploded to another server
where we store our dumps via ftp.
Today i've downloaded the made dump back to ase
server >> > and tried to loaded it. Failed.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server session id is: 59. Use this value
when >> > executing the 'sp_volchanged' system stored
procedure >> > after fulfilling any volume change request
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name >>
'staging0927302C8D' section number 1 mounted on byte >> >
stream >> >
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Number (412402) Severity (2) State (1) Server
4.124.2.1: >> > Archive API error for
device='compress::/disk1/syb_data_dump/staging_20090930.dm
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
p::00': Vendor application name=Compress API, Library
version=1, API routine=syb_read(), Message= >> >
Number (8009) Severity (16) State (1) Server (yulia) >> >
Error encountered by Backup Server. Please refer to >> >
Backup Server messages for details. >> >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
But if i perform load database with headeronly
i get this
Backup Server session id is: 57. Use this value
when >> > executing the 'sp_volchanged' system stored
procedure >> > after fulfilling any volume change request
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name >>
'staging0927302C8D' section number 1 mounted on byte >> >
stream >> >
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
This is a database dump of database ID 14, name >>
Adaptive Server Enterprise/12.5.4/EBF 16831 >> >
ESD#9.1/P/x86_64/Enterprise >> >
Linux/ase1254/2146/64-bit/OP. Backup Server version: >> >
Backup Server/12.5.4/EBF 16831 ESD#9.1/P/Linux AMD >> >
Opteron/Enterprise Linux/ase1254/2510/64-bit/OPT. >> >
Database page size is 46909632811008. >> > Database
contains 4864000 pages; checkpoint RID=(Rid >> > pageid =
0x42dd50; row num = 0xb); next object >> > ID=841767025;
sort order ID=50, status=0; charset ID=53. >> > Database
0x00000003 lstart=0 vstart=83886080 >> > lsize=3840000
unrsvd=3421880 >> > segmap: 0x00000004 lstart=3840000
vstart=100663296 >> > lsize=1024000 unrsvd=1020000
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from
'compress::/disk1/syb_data_dump/staging_20090930.dmp'
go >> > online database load_bkp
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
go
sp_dboption load_bkp, 'single user', false
go
I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which was
originaly made in ASE ESD8?
Thanks.
alexander
2009-10-06 11:05:34 UTC
Permalink
./install/RUN_servername_BS of course ;).
Post by alexander
Thank you, Kevin.
SYBASE environment variables are set. ASE is installed in
/opt/sybase, so when i issued cd $SYBASE/$SYBASE_ASE and
then pwd i get /opt/sybase/ASE-12_5
I've stopped backupserver and then issued
/install/RUN_servername_BS
then i examined the BS log and found nothing special which
could signalize that BS server had not found something he
needs for correct work. And it's nothing to say all this
commands i issued under sybase user in rhel.
I also can say that i copied SYBASE.sh in /etc/profile.d
and make SYBASE.sh available for readind for sybase user.
In BS log i found nothing about incorrect run of dump
work(when dump database was performed). No signal that
space on hdd is insufficient or whatever else. So in this
case i think that my dumps are ok. The one thing that i
think is ftp. As i said i upload my dumps on another
server via ftp, and it was made in ascii mode as default
mode of ftp transfering. I have an sh script that opens an
ftp connection with win ftp service and then uploads
dumps. Then i downloaded dump from win server also in
ascii mode on another linux box and tried to load dump and
failed. But one dump i load. Maybe it depends on size of
dumps. Dump that i've loaded was not verry big,
approximately 350 Kb. And now i tried to load a dump wich
is 7.5 Gb in size.
Post by Sherlock, Kevin [TeamSybase]
One thing to check is to make sure your
$SYBASE/SYBASE.sh environment variables are sourced
before the backup server is started.
. $SYBASE/SYBASE.sh
cd $SYBASE/$SYBASE_ASE/install
./startserver -f RUN_SYBBACKUP
I've seen where the backupserver is started without the
correct environment variables set and the compression
libraries aren't found by backupserver when attempting
backup/restore. Or sometimes, the backup server is
running under a different account (like "root") where
the environment for SYBASE is not set.
respond. Machines are identical, RHEL 5.3 64 bit. On
both ASE 12.5.4 ESD#9.1 is installed, dump were made
with 6 compression. I've read that it could be because
ftp transfers in ascii by default, i didn't know about
this. We store dumps on different server (Win2003R2 32
bit ) on which i upload dumps from linux servers via
ftp. Few days ago i tried to load a dump and received
such error. I uploaded dump from win ftp client in
binary mode and this could cause a problem, but then i
downloaded a dump from linux in ascii mode. After that
i was managed to load one dump, but it was only once.
When i tried to restore other dumps i get such error. >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Alexander,
Compress is very platform dependant. Are the two
machines >> running the exact same Operating System?
Compress cannot >> be used for cross platform dump and
load. i've tried and >> failed.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Going from ESD 9 to ESD#8 should be ok but not
guaranteed. >> ASE 12.5.4 had some backupserver changes
introduced. >>
Post by "Cory Sane [TeamSybase]" <cory!=sane>
FYI - the newer form of compression ("dump... with
compression=6") is preferred by Sybase folks going
forward. You will get the benefit of greater support
by >> switching. I switched 3+ yrs ago.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
--
Cory Sane
[TeamSybase]
Certified Sybase Associate DBA for ASE 15.0
Post by alexander
I've encountered a problem while i was loading a
dump. >> >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Dump was performed with compress level 6.
after dump was ready it was uploded to another
server >> > where we store our dumps via ftp.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Today i've downloaded the made dump back to ase
server >> > and tried to loaded it. Failed.
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server session id is: 59. Use this value
when >> > executing the 'sp_volchanged' system stored
procedure >> > after fulfilling any volume change
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name >>
'staging0927302C8D' section number 1 mounted on byte >>
stream >> > >>
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Number (412402) Severity (2) State (1) Server
(yulia_BS) >> > Procedure (bs_perform_load) Backup
Server: 4.124.2.1: >> > Archive API error for >>
device='compress::/disk1/syb_data_dump/staging_20090930.dm
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
p::00': Vendor application name=Compress API,
Library >> > version=1, API routine=syb_read(), Message=
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Number (8009) Severity (16) State (1) Server
(yulia) >> > Error encountered by Backup Server. Please
refer to >> > Backup Server messages for details. >> >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
But if i perform load database with headeronly
i get this
Backup Server session id is: 57. Use this value
when >> > executing the 'sp_volchanged' system stored
procedure >> > after fulfilling any volume change
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Backup Server: 6.28.1.1: Dumpfile name >>
'staging0927302C8D' section number 1 mounted on byte >>
stream >> > >>
'compress::/disk1/syb_data_dump/staging_20090930.dmp::00'
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
This is a database dump of database ID 14, name >>
Adaptive Server Enterprise/12.5.4/EBF 16831 >> >
ESD#9.1/P/x86_64/Enterprise >> >
Linux/ase1254/2146/64-bit/OP. Backup Server version: >>
Backup Server/12.5.4/EBF 16831 ESD#9.1/P/Linux AMD >>
Opteron/Enterprise Linux/ase1254/2510/64-bit/OPT. >> >
Database page size is 46909632811008. >> > Database
contains 4864000 pages; checkpoint RID=(Rid >> > pageid
= 0x42dd50; row num = 0xb); next object >> >
ID=841767025; sort order ID=50, status=0; charset ID=53.
Post by Sherlock, Kevin [TeamSybase]
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Database log version=6; database upgrade
version=31. >> > segmap: 0x00000003 lstart=0
vstart=83886080 >> > lsize=3840000 unrsvd=3421880 >> >
segmap: 0x00000004 lstart=3840000 vstart=100663296 >> >
lsize=1024000 unrsvd=1020000 >> >
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
I'm trying to load database with this command
sp_dboption load_bkp, 'single user', true
go
load database load_bkp
from
'compress::/disk1/syb_data_dump/staging_20090930.dmp' go
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
online database load_bkp >> > go
sp_dboption load_bkp, 'single user', false
go
I have now idea what is wrong.
Is it possible to load dump in ASE ESD 9.1 which
was >> > originaly made in ASE ESD8?
Post by "Cory Sane [TeamSybase]" <cory!=sane>
Post by alexander
Thanks.
Neal Stack [Sybase]
2009-10-06 15:51:24 UTC
Permalink
Hello,

The dump is a binary file so I would do all ftp'ing in binary mode.
When ftp'ing in ascii mode from one platform to another, FTP will
append \r\n and possibly strip it. Binary mode will leave the file
untouched.

Regards,
Neal
alexander
2009-10-06 16:19:45 UTC
Permalink
Thank you, Neal!
Is it possible to remove this \r\n from dump file?
But I do not understand why i was able load one dump while
other couldn't. This 2 dumps were maid on linux box than
ftp'ing to windows server and then ftp'ing to another linux
box. One i loaded another not. They are different in size,
it's true, but i don't think it's the case. Databases were
without user segments, they were dumped with the same
options, etc.
Post by Neal Stack [Sybase]
Hello,
The dump is a binary file so I would do all ftp'ing in
binary mode. When ftp'ing in ascii mode from one platform
to another, FTP will append \r\n and possibly strip it.
Binary mode will leave the file untouched.
Regards,
Neal
Mark A. Parsons
2009-10-06 16:39:58 UTC
Permalink
Post by alexander
Is it possible to remove this \r\n from dump file?
While you could probably use some sort of binary file editor to make such changes ... how would you know which \r\n
strings are valid and which are invalid? ... how would you know what other hex values may need to be
removed/modified/added? ... how much work is it going to be to modify 100's of MBs (GBs) of dump files?

It'll be a lot easier to make sure you don't need to modify the dump files to begin with, eg, make sure you're
performing *all* of your ftp's in binary mode.
Post by alexander
But I do not understand why i was able load one dump while
other couldn't. This 2 dumps were maid on linux box than
ftp'ing to windows server and then ftp'ing to another linux
box.
You've previously mentioned that the windows->linux ftp was performed in ascii mode ... that could explain 1 reason why
the file could not be loaded.

If you're saying that you had another dump file that went through this same linux->windows->linux ftp tango, and said
file loaded successfully ... I'd guess that a) you got lucky or b) both ftp's were conducted in binary mode.

Have you verified that the dump files are the same *exact* size on all 3 platforms? If they are different sizes then
one of the ftp's was probably performed in ascii mode.

NOTE: When I say *exact* size I'm talking about the file size down to the byte; eg, instead of a file size of 5,752KB
(invalid) you want to look at the file size as 5,890,048 bytes (valid). ("Duh, Mark!" ?)

------------

I'd suggest you start over from scratch ...

- forget the dump files you currently have on hand

- perform a new (compressed) dump from the original linux dataserver

- ftp the dump file to the windows machine using binary mode (check and double check that you're using binary mode)

- verify that the dump files are the same *exact* size on both machines

- ftp the dump file to the final linux machine using binary mode (check and double check that you're using binary mode)

- verify that the dump files are the same *exact* size on both machines

- try to load the database dump file

If at this point you still cannot get the dump file to load, then post the contents of the backupserver's errorlog
and/or open a case with Sybase TechSupport.
Neal Stack [Sybase]
2009-10-06 19:57:45 UTC
Permalink
Hello,

As Mark said, there may be valid carriage return/line feed sequences in the dump data
so I would be very hesitant using a utility like "dos2unix" to strip them out.

You can see if there were carriage return line feeds by using the "od" command.
od -c pubs2.dmp | grep "\\r \\n" | more

Notice the size of my original dump file on Solaris:
% ls -l pubs2.dmp
-rw-r--r-- 1 nstack sybase 3371008 Oct 6 13:58 pubs2.dmp

After I transfer it to my PC in "ascii" mode the size increases due to the added CR/LF:
C:\Temp>dir pubs2.dmp
Volume in drive C is Drive_C
Volume Serial Number is 70AA-7A9D

Directory of C:\Temp

10/06/2009 01:45 PM 3,376,842 pubs2.dmp

Depending on the FTP program you are using and it's settings, it may or may not add the CR/LF:
ftp> help cr
cr toggle carriage return stripping on ascii gets


Regards,
Neal
alexander
2009-10-07 20:03:57 UTC
Permalink
Thanks a lot for the answers!
Post by Neal Stack [Sybase]
Hello,
As Mark said, there may be valid carriage return/line feed
sequences in the dump data so I would be very hesitant
using a utility like "dos2unix" to strip them out.
You can see if there were carriage return line feeds by
using the "od" command.
od -c pubs2.dmp | grep "\\r \\n" | more
% ls -l pubs2.dmp
-rw-r--r-- 1 nstack sybase 3371008 Oct 6 13:58
pubs2.dmp
After I transfer it to my PC in "ascii" mode the size
increases due to the added CR/LF: C:\Temp>dir pubs2.dmp
Volume in drive C is Drive_C
Volume Serial Number is 70AA-7A9D
Directory of C:\Temp
10/06/2009 01:45 PM 3,376,842 pubs2.dmp
Depending on the FTP program you are using and it's
settings, it may or may not add the CR/LF: ftp> help cr
cr toggle carriage return stripping on ascii
gets
Regards,
Neal
Loading...