Comments on My SysAd Blog -- Unix: Dump Sybase Database to File

A quick tip, if you want to break up a large db to...

2008-05-05T11:18:00.000-07:00

A quick tip, if you want to break up a large db to multiple files, use the "stripe on" argument.

dump database yourdb to "/tmp/mydatabase1.dat"
stripe on "/tmp/mydatabase2.dat"
...

Hmmm. I can't say that I agree with you. I have se...

2008-02-29T02:32:00.000-08:00

Hmmm. I can't say that I agree with you. I have seen on several occasions where people thought they were doing the right thing but in fact they were not.

If a database that is about to be moved has been altered several times then it has to be recreated in exactly the same fashion on the receiving end, otherwise you risk ending up with segments containing both log and data.

The following query will show you exactly how the database is constructed (to be run from the master database):

select size/512, segmap from sysusages where dbid=[database id]

You will need to know your database id (you can find it from running sp_helpdb) and you also need to know that the different segmap numbers mean. For example:

1> select size/512, segmap from sysusages where dbid=4;
segmap
----------- -----------
200 3
300 3
100 4
300 3
1000 3
500 3
500 3
1000 3

Here we have a database that has a single log segment that is 100MB (segmap = 4) and several data segments that are a total of 3800MB (segmap = 3). If I want to recreate this database elsewhere then you will be making a mistake if you do this:

create database newdb on data01=3800 log on log01=100 for load

This will guarantee that you will mix and match log and data.

You indicate that you think everybody knows this but my experience is the opposite. I have seen this mistake being done by Sybase admins - even in production sites.

And as a last note, I might add that if you are seeing segmap numbers other than 3 or 4 on a user database then it might mean trouble. But that is another story alltogether....

dabbi,If I find more time, I might write something...

2008-02-28T08:23:00.000-08:00

dabbi,

If I find more time, I might write something up in the future. Frankly speaking, I assumed most readers of this blog knows how to create the database on the receiving end.

Sybase isn't that bad, but I do agree that you wer...

2008-02-28T07:58:00.000-08:00

Sybase isn't that bad, but I do agree that you were using the wrong platform.

This is the fastest way to move a database from one Sybase ASE server to another. I would however recommend that you do a writeup of how to create the database on the receiving end since this tip is worthless if it isn't correctly created...

Thanks Noah for the comment. I figured many admins...

2008-02-28T07:20:00.000-08:00

Thanks Noah for the comment.

I figured many admins have used something similar or maybe something with bcp. I'm curious as what methods others are using or have used in the past.

I loathe SyBase, but when I was working for a loca...

2008-02-27T08:33:00.000-08:00

I loathe SyBase, but when I was working for a local college, I was in charge of the dental lab's new server. It stored patient records for the dental lab clinic, x-ray images, inventory and billing data.

Windows 2000 with SyBase. What a winning combo. That server is one of the few things I hated about that job.

I used a method similar to yours so that we could, likewise, back it up (with TSM).