We're upgrading from 11.5 to 12.5 and I'm interested in reorganising the
device setup for the databases' data and log fragments. Does it sound
sensible to upload the 11.5 dump into a test 12.5 sever to achieve the
upgrade and then migrate the test server to the new production server with
the new fragment setup?

Martin

After you reorganize your devices, you can use psCopySchema of DBPowerSuite
(http://www.dbpowersuite.com) which transfers your schema and data in the
most efficient manner possible.. Table definitions transfer first along
with the clustered indices, then the data, the non-clustered indexes, etc.
In this manner, your data reorganizes while never fragmenting. You can
also map your old segments to new segments.


Brian


"Martin Hanna" <postmaster (AT) SPAMIGNOREmovilla (DOT) IGNOREplus.com> wrote in
message news:OpSWb.3491$Y%6.458308 (AT) wards (DOT) force9.net...

Martin Hanna wrote:


Your strategy could be to take a Sybase backup of the 11.5 database and
load it into a new database, which is running under a higher version.
First be sure that the old database does not suffer from database
corruption -- run dbcc. Truncate the transaction log in the old
database before you take the backup. After you load the backup of your
database, Sybase software will upgrade it when you issue the "ONLINE
DATABASE <name>" command.

Before you load the backup, you need to create an empty database, which
will be the same size as the old database. The devices must be the same
size, too. Their names don't matter. The create database command and
subsequent alter database commands must be run in a sequence, which will
incorporate the devices into the database in the same order, in which
the devices, to which they correspond, were incorporated into the old
database.

In the new installation, you need to get the ASE logins (users and
database owners) created in the same order as they were created in the
old database -- as defined by SUIDs. To do this, you may bulk copy the
logins out from the old database and bulk copy them into the new database.

After you do this, you will need to drop and recreate views, stored
procedures, triggers and defaults. Any partitioned tables will probably
generate warning messages during the load of the new database, so you
will need to update partition statistics on them. Also update
statistics on all tables after dropping and recreating views, stored
procedures, triggers and defaults. Be sure to check for data corruption
in the new database by running dbcc. Finally, take a backup of the new
database.

Several of the tuning parameters, as defined in sp_configure, have
changed or are new, so that you will need to define them.
HTH,
Tom McCready

"Tom McCready" <noone (AT) nowhere (DOT) com> wrote

Thanks for that Tom. I've already done this in prep work, dumping the 11.5
database and loading it into the 12.5 server with the same sysusages order.
My issue is that the original 11.5 database was extended on an ad hoc basis
resulting in lots of data fragments that just looks a mess. Yes, I know
it'll still work fine under 12.5 but I thought the upgrade would be a good
time to reorganise the database fragments. I went to a Powering Up to Sybase
12.5 course a few weeks ago and the Sybase Migrate utility was introduced.
Primarily it's used for migrating from a 2K 12.5 server to a 4/8/16K 12.5
server. When asked if it could be used to migrate from 2K to 2K and
reorganise the data fragments I was told it was possible. I was just
wondering if anyone else has gone down this route, and if not, what did they
do to reorganise an unsatisfactory database setup.

Martin