http://www.sybase.com/detail?

id=1324

SEGMENT
REMAPPING WITH
LOAD DATABASE

WHEN MOVING A
DATABASE
To safely load an old database onto a new
database, create the target database exactly the
same as the source.

Contents
To move a database to new devices on your system or to rebuild a database on the old devices, you
have to first create the new database, then load a dump of the old database onto it. SQL Server
preserves the logical structure of the source database when it is loaded onto the target database.
From System 10 on, SQL Server also preserves the segment mapping.
In order to successfully load the dump, you have to create the target database to be identical to the
source, with devices of the same size and in the same order. If you can't or don't create the
database just like the source, you may get unexpected results when you the load the database.
This TechNote discusses potential load database problems. It contains the following sections:

Terminology

History of How load Handles Fragments

Unexpected Results From load database

Explanation of Results

Summary

How to Avoid Problems When Moving or Re-creating Databases

References

Terminology
This TechNote uses the following terminology:
Source database the original database.
Target database the new database onto which a dump of the source database is loaded.
Fragment a disk piece containing part or all of a database. It is represented by a row in the
sysusages table in the master database. The create database and alter database commands
create new rows in sysusages. For example, this command:

1> create database source_db

2> on dev1 = 2
3> log on dev2 = 2
4> go
creates two fragments, therefore two rows in sysusages.
Segment a label used to indicate the type of data that can be put on a fragment. Segments 0, 1,
and 2 are always the system, default, and log segments. Segments 3 and following are user- defined
segments. Segments for a database are represented by rows in the syssegments table of the
database.
Segments are logical. They are a way of organizing data in a database. You can place segments on
fragments, then associate objects with the segments. Segments do not have a one-to-one
relationship with physical space. You can place two or more segments on a fragment, or you can
extend a segment over several fragments.
sysusages table the sysusages table in the master database keeps track of database fragments. It
contains one row for each fragment of all your databases. Query sysusages as follows:

1> use master

2> go
1> select dbid,
size,

segmap
vstart

, lstart,

2> from sysusages where dbid = 5

3> go
dbid

segmap
size

vstart

----

------

--

lstart

-----

---

--------

3
1024

33554432
4

1024
5

2048

67108864
16

2048

1024

50331648
8

2048

4096

83886080

(4 rows affected)
The columns in this output are:
dbid the database ID number.
segmap a bitmapped representation of the values of all segments associated with a disk fragment.
Figure 1 shows how the segmap value in sysusages is determined:

Figure: How segmap values are determined

In Figure 1, a fragment contains both the system and default segments. Therefore the bits in the first
and second positions of the bitmap are turned on, for a value of 3.
lstart The logical page number on which a database fragment begins. Logical pages are used by the
database. The first fragment of a database has an lstart value of 0.
size The fragment size is in 2K pages. To get the number of megabytes, divide the size by 512.
vstart The virtual page number on which a fragment begins. Virtual pages are used by the database
device. The vstart values for a database on several devices have no relationship to each other; they
describe the location of the fragment on the device as an offset in 2K pages.

Note
For more information about segments and placing databases on devices, see the SQL Server System
Administration Guide.

History of How load Handles Fragments

The way that SQL Server handled fragments changed with System 10, as described in the following
sections.

Pre-System 10 load Functionality

Before release 10.0, SQL Server preserved the logical page order but not the segment mapping of a
database during a load. Loading a database dump onto a target database that you created
differently than the source databasewith differently sized fragments or fragments created in a
different ordercould result in Error 2558 (for example, log-on-data or data-on-log). Figure 2 shows
how Error 2558 might occur. In this example, the segments were placed on the target database in a
different order than on the source, resulting in data pages on a log segment and log pages on a data
segment.

Figure: Error 2558 in pre-System 10 load

Note
See the SQL Server Error Messages manual for more information about Error 2558.

System 10 Change in load Functionality

In System 10, Sybase changed load functionality to avoid the 2558 error. Now when you load a
dump onto a target database, the target acquires the segment mapping of the source; any
segments that you may have placed on the target database are overwritten.

Figure: System 10 load overwrites target segments

Unexpected Results From load database

While data mixing no longer happens in the current release of SQL Server, you can still get
unexpected results if you move a database spanning several devices onto a new set of devices
where the fragments were created differently than on the original database. The ways you can
create a database differently are:

Creating the database with fragments of different sizes than the source database

Creating the fragments in a different order than the source if the fragments are of varying
sizes

Unexpected results include:

Disk fragmentation more fragments than you started with

Data and log fragments on one device

A database that is impossible to re-create with create database

Example
The following example demonstrates how loading a dump onto a database created with differently
sized fragments or fragments in a different order than the source database can increase the number
of fragments and place data and log on the same device.

Creating source_db
The source database, source_db, was created as follows:

1> create database source_db

2> on dev1 = 2
3> log on dev2 = 2
4> go
Later, two more devices were added to the database:

1> alter database source_db

2> on dev3 = 4,
3> dev4 = 4
4> go
Then two user-defined segments, seg1 and seg2, were added to the new devices:

1> sp_addsegment seg1, source_db, dev3

2> go
1> sp_addsegment seg2, source_db, dev4
2> go
Finally, the system and default segments were dropped from dev3 and dev4:

1> sp_dropsegment system, source_db, dev3

2> go
1> sp_dropsegment "default", source_db, dev3
2> go
1> sp_dropsegment system, source_db, dev4
2> go
1> sp_dropsegment "default", source_db, dev4
2> go
A select from sysusages shows four fragments for source_db:

1> select dbid,

size,

segmap

, lstart,

vstart

2> from sysusages where dbid = 5

3> go
dbid

segmap
size

----

vstart
------

--

lstart

-----

--------

3
1024

33554432
4

1024
5

2048

67108864
16

2048

1024

50331648
8

2048

83886080

4096

---

(4 rows affected)
The segmap column shows the two user-defined segments, seg1 and seg2, as values 8 and 16
respectively.
The database fragments now look like this:

Figure: source_db fragments

Creating target_db
target_db was created differently than source_db. The database was created in a single command
on all its devices at once instead of being altered onto them later. This placed the log segment last
and resulted in a different order of fragment sizes:

1> create database target_db

2> on dev5 = 2,
3> dev6 = 4,
4> dev7 = 4
5> log on dev8 = 2
6> go
User-defined segments seg1 and seg2 were added to dev6 and dev7:

1> sp_addsegment seg1, target_db, dev6

2> go
1> sp_addsegment seg2, target_db, dev7
2> go
The system and default segments were dropped from dev6 and dev7:

1> sp_dropsegment system, source_db, dev6

2> go
1> sp_dropsegment "default", source_db, dev6
2> go
1> sp_dropsegment system, source_db, dev7
2> go
1> sp_dropsegment "default", source_db, dev7
2> go
A select from sysusages shows four fragments for target_db:

1> select dbid,

size,

segmap

, lstart,

vstart

2> from sysusages where dbid = 6

3> go
dbid

segmap

lstart

size

vstart
----

-------

--

-----

-----

-------6

1024

1024

2048

16

3072

2048

5120

1024

100663296
6
117440512
6
134217728
6
150994944

(4 rows affected)
Figure 5 shows target_db's fragments as they were created:

Figure: target_db with fragments in the order created

Loading Dump from source_db onto target_db

To continue the example, source_db is dumped to tape and the dump loaded onto target_db with the
load database command:

load database target_db from "/devices/source_dump"

Two things happen:

SQL Server overwrites the segments originally added to target_db with the segment map of
source_db.

Because more than one segment is now assigned to the same fragment, SQL Server divides
the fragment into smaller fragments, each with its own segment.

Figure 6 shows illustrates the changes to segment mapping:

Figure: target_db acquires segment map from source_db

A select from sysusages now shows six disk fragments for target_db:

1> select dbid,

size,

segmap

, lstart,

vstart

2> from sysusages where dbid = 6

3> go
dbid

segmap

lstart

size

------

-----

1024

1024

1024

2048

1024

3072

1024

vstart
----

----

-----6
100663296
6
117440512
6
117441536
6
134217728

16

4096

1024

16

5120

1024

134218752
6
150994944
Loading the dump of source_db onto target_db caused the following unexpected results:

Log and data are on the same physical device, although not mixed on the same fragment.

The number of disk fragments increased from four to six.

Explanation of Results
The results in the example are due to the way SQL Server handles loads and how it resolves
differences in the way databases are created. When you move a database to a new set of devices or
re-create it on the same devices, the physical and logical storage is determined as follows:

The target database determines the physical storage, that is, how much space is allocated
on which database devices.

The source database determines logical storage, that is, the logical page order and segmap
values of the fragments. This occurs whether or not you have defined segments on the new
fragments with sp_addsegment and sp_extendsegment.

Resolving Differences
When a database dump is loaded onto a database that was created differently, SQL Server resolves
the differences as follows:

The load process overwrites any segment mapping you may have created on the target
database.

If data which was on different fragments with different segmaps on separate devices is now
placed on the same device, SQL Server will create separate fragments on the device for
each fragment. In other words, it will add rows to sysusages with different segmap values.

If data which was the same segment on separate devices is placed on contiguous fragments
on the same device, SQL Server will merge the fragments. In other words, it will delete the
separate rows in sysusages and insert a single row with a larger size.

Databases That Cannot Be Re-Created

If you made a size error when initializing a device and later created a database on the device, you
could have a database that cannot be created with the create or alter database commands.
When you initialize a device with the disk init command, you must specify a size in 2K pages. One
megabyte is 512 2K pages. If you enter a device size that is not divisible by 512, you may create a
device whose size is not in whole megabytes. SQL Server allocates space in units of 256 pages, or
1/2MB, so your device may have a size that includes 1/2MB.

If you create a database that is too large to fit on the device, SQL Server uses all the space
available, so you get a database whose size also includes 1/2MB.
If you have such a database, you may not experience any problems until you try to move or rebuild
it. The create and alter database commands allow you to enter only whole megabytes to specify
database size. Therefore you cannot create a new database exactly the size of the old one. If you
load the old database onto the new, SQL Server has to remap the fragments, creating 1/2MB
fragments.
Similarly, if you create the target database on a device whose size includes 1/2MB, and try to load a
dump of a database whose size is in whole megabytes, you get 1/2MB fragments.

Summary
The unintended results of loading a source database onto a target database that was created
differently include:

Log and data fragments on the same device

An unpredictable number of fragments

If you have 1/2MB fragments, a database which you cannot re-create in exactly the same
way

How to Avoid Problems When Moving or Re-creating

Databases
The only way to avoid unexpected results when moving a database is to create the new database
with fragments in the same size and order as the source. The following methods allow you to do this.

Gather Information About Your Database

To get a complete picture of how your source database was createdwhat devices it's on, what
segments it has, and what size the fragments areyou can gather information from the following
system tables:

sysdevices

sysdatabases

sysusages

syssegments

Follow these steps to get information about your database:

1.

To see what segments are on the database, select from the syssegments table:

2.

1> use source_db

3.

2> go

4.

1> select segment, name from syssegments

5.

2> go

6.

segment

name

7.

------

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

8.

system

9.

default

10. 2

logsegment

11. 3

seg1

12. 4

seg2

13.
14. (5 rows affected)
15. Determine your database's ID number:
16. 1> use master
17. 2> go
18. 1> select name, dbid from sysdatabases
19. 2> where name = source_db
20. 3> go
21.

name

dbid

22. ---------------

----

23.

master

24.

model

25.

source_db

26.

sybsystemprocs

27.

target_db

28.

tempdb

6
2

29.
30. (6 rows affected)
31. Use the database ID to select from the sysusages table. The sysusages table shows you the
order the fragments were created, their sizes, and their segmap values:
32. 1> select dbid, segmap, lstart, size, vstart
33. 2> from sysusages where dbid = 5
34. 3> go
35. dbid

size
36. ----

----37. 5

segmap
vstart
-------

38. 5

39. 5

40. 5

1024

2048

67108864
16

2048

50331648
8

2048

-----

33554432
4

1024

--

-------3

1024

lstart

4096

83886080

41.
42. (4 rows affected)
Verify that all your size values are divisible by 512, that is, that they are whole megabytes.

WARNING!
If you have fragments whose sizes are not divisible by 512, you cannot re-create the database. If
you want to avoid 1/2MB fragments, do not try to load it onto another database. Call Technical
Support if you need help with this problem.

1.

To see what devices the database is on, look at the sysdevices table. Each vstart value from
sysusages will fit between the high and low virtual page numbers of one of the devices.

2.

1> select low, high, name from sysdevices

3.

2> go

4.

low

high

name
5.

--------

--------

---6.

33554432

33556479

dev1
7.

50331648

50333695

dev2
8.

67108864

67110911

dev3
9.

83886080

83888127

dev4
10. 100663296

100665343

dev5
11. 117440512

117442559

dev6
12. 134217728

134219775

dev7
13. 150994944

150996991

dev8
Figure 7 shows the relationship between the system tables that give you information about your
databases.

Figure: Relationship between system tables that show space usage

Initializing Devices Correctly

When you initialize your new devices, be sure that the size you specify is divisible by 512.
1.

Initialize the disk. Use a command similar to this:

2.

1> disk init name = "dev5",

3.

2> physname = "/work/sybase/devices/dev5",

4.

3> vdevno = 6,

5.

4> size = 2048

This example command creates a 4MB device.

6.

Check the sysdevices table in the master database for the page ranges of the device:

7.

1> use master

8.

2> go

9.

1> select low, high, name from sysdevices

10. 2> where name = dev5

11. 3> go
12. low

high

name
13. --------

--------

---14. 100663296

100665343

dev5
15. Use this equation to see if the size of the device is a whole megabyte:
16.

(high

low + 1) / 512

If the device size is not a whole megabyte, drop the device with sp_dropdevice. See the
System Administration Guide for more information on initializing devices.

Creating the Database Correctly

Follow these steps to create the target database:
1.

Refer to the output from the sysusages table for the source database as you create the new
database.

2.

If you have the script which created the source database, run it now, then go to step 5.

3.

Create your database with the fragments in exactly the same order as the source database.
The database in the long example must be created in two steps if you use the log on
option. This is necessary because log is on the second fragment, but the log on option
cannot be used as the second phrase of a create statement.
Depending on where your log segment is, use commands like the following:

1> create database target_db

2> on dev5 = 2
3> log on dev6 = 2

4> for load

5> go
1> alter database target_db
2> on dev7 = 4,
3> dev8 = 4
4> for load
5> go
You do not need to add segments. The target database will acquire the segment mapping of
the source database.
4.

Check the messages from the create and alter commands. Verify that the pages allocated
are divisible by 512.

WARNING!
If the number of allocated pages is not divisible by 512, drop the database. Check the sysdevices
table in the master database for the page ranges of the device. Use this equation to see if the size of
the device is a whole megabyte:
(high low + 1) / 512
If the device size is not a whole megabyte, drop the device with sp_dropdevice. See the System
Administration Guide for more information on initializing devices.

1.

Perform a select from sysusages now:

2.

1> select dbid, segmap, lstart, size, vstart

3.

2> from sysusages where dbid = 6

4.

3> go

5.

dbid
size

6.

lstart

------

-----

vstart

-------

segmap

------

7.

3
1024

8.

4
1024

9.

100663296

1024

117440512
3

2048
10. 6

2048

134217728
3

2048

4096

150994944

11.
12. (4 rows affected)
Verify that the target database has the same number of fragments as the source and that
the size and lstart values are the same as those of the source database.

Note
dbid and vstart values are normally different than those of the source database. This doesn't matter.

1.

Load the database dump from the source database with a command like the following.

2.

load database target_db from "/devices/source_dump"

3.

Look at sysusages again after the load:

4.

1> select dbid, segmap, lstart, size, vstart

5.

2> from sysusages where dbid = 6

6.

3> go

7.

dbid
size

8.

9.

lstart

------

-----

vstart

-------

------

3
1024

segmap

100663296

10. 6

4
1024

11. 6

8
2048

12. 6

2048

134217728
16

2048

1024

117440512

4096

150994944

13.
14. (4 rows affected)
Verify that the target database now has the same segmap values as the source database.

Alternative Method to Create the Database

You can save time by creating the target database in a single step. While this method is not identical
to the one you used to create the source database, the results are the same.
1.

Refer to the output of the sysusages table for the source database and create your database
with a command like the following, specifying only devices and sizes:

2.

1> create database target_db

3.

2> on dev5 = 2,

4.

3> dev6 = 2,

5.

4> dev7 = 4,

6.

5> dev8 = 4

7.

6> for load

8.

7> go
Do not use the log on option and do not add any segments. Segment mapping will come
from the source database when it is loaded.

9.

Perform a select from sysusages now:

10. 1> select dbid, segmap, lstart, size, vstart

11. 2> from sysusages where dbid = 6

12. 3> go
13. dbid

size

15. 6

lstart

------

-----

vstart

14. ----

----

segmap

-----7

1024
16. 6

100663296
7

1024
17. 6

1024

117440512
7

2048
18. 6

2048

134217728
7

2048

4096

150994944

19.
20. (4 rows affected)
Verify that the number of fragments is correct and the size and lstart values are the same as
those of the source database.

Note
dbid and vstart values usually differ from those of the source database. This is not a problem.
The segmap values default to 7. These values will change after the load.

1.

Load the database dump from the source database.

2.

load database target_db from "/devices/source_dump"

3.

Look at sysusages again after the load:

4.

1> select dbid, segmap, lstart, size, vstart

5.

2> from sysusages where dbid = 6

6.

3> go

7.

dbid
size

segmap
vstart

lstart

8.

9.

----

------

----

------

3
1024

10. 6

100663296
4

1024
11. 6

1024

117440512
8

2048
12. 6

2048

134217728
16

2048

-----

4096

150994944

13.
14. (4 rows affected)
Verify that the target database now has the same segmap values as the source database.

References
See the SQL Server Reference Manual for command and stored procedure syntax. See the System
Administration Guide for a discussion of segments.

Case
10509968
Number:
1999-04-01
Open Date:
23:58:38.0
Version/EBF: 1151/0

Adaptive Server
Enterprise
OS: AIX
IBM RISC System
Platform:
6000
Product:

Case Description
All segmap fields were set to 7 by mistake after which
transaction processing took place. There is no recent dump of
the master database and there is no copy of original sysusages
available. Dump transaction fails with 4205 error due to mixed
log and data fragments.
Tip or Workaround
Msg 4205, Level 16, State 1:

Line 1:
Syslogs does not exist in its own segment in database '7' with
segmap '7' with logical start page number of '0'. You may not
use DUMP TRAN in this case, use DUMP DATABASE instead.

dbcc findstrandec(dbid):
Finds the number of non-syslogs extents that reside on a
logsegment and toggles the status bit DBT2_STRANDED
(0x8000) in the dbtable structure field dbt_stat2.

To set segmap to 4 in rows of sysusages:

begin tran
go
update sysusages set segmap=4 where dbid=<dbid> and
lstart=<lstart for log fragment>
go
/* confirm update succeeded as intended */
select * from sysusages where segmap = 4
go
commit
go
Resolution
Examine sysusages and sysdevices to find which fragments are
on log devices (hopefully obvious from device names, or known
to user).

update sysusages.segmap back to 4 for each log fragment.

Run dbcc findstranded(<dbid>) to find tables with data written
on the log device.
bcp all such tables out or select into new tables. If bcp'ed,
recreate tables under different name and bcp data in. Verify
table consistency by running dbcc checktable. If it returns
clean, drop original table. Rename new tables to original table
names.
Finding which fragments were assigned to user-defined
segments can be difficult unless clear naming conventions have
been used. Examining syssegments will reveal if user-defined
segments have been used in the database. If so, it may be
possible to recreate the correct segmaps if the user remembers
well what fragments were assigned to particular segments (TIP
select object_name(id),indid, segment from sysindexes will give
object name, index id and the segment number of the segment
this particular index is placed). If not, these assignments will be
lost. However this will not affect data integrity or the ability to
do dump transaction.
Other Sources Related to Issue
TechNote
Doc ID 1324 "segment remapping with load database when
moving a database"

Case
10924978
Number:
2003-04-21
Open Date:
16:34:59.7
Version/EBF: 1200/0

Adaptive Server
Enterprise
OS: Windows NT
Platform: PC Windows NT
Product:

Case Description
Customer lost hard disk where sql server resides. They have a

database dump from the previous day. Is there a way to get

the device info from the dump? Is there a way to restore their
system?
Key Words: How to question
Key Words: dump database
Key Words: recovery
Key Words: recover
Tip or Workaround
Since the "create database" script or master database backups
are not available, you would need to:
1) Build a new ASE server
2) disk init all devices
3) create database equal or bigger than database dump file.
4) load the dump.
5) After loaded, log fragment may reside on devices reserved
for data devices.
6) Take a hard copy of sysusages and recreate the database
according to
the order in sysusages. For example:
output of sysusages:
5 3 0 2048000 50331648 NULL 1442958
5 3 2048000 1024000 67108864 NULL 1020000
5 3 3072000 1024000 150994944 NULL 1020000
5 4 4096000 1024000 152018944 NULL 946927
5 3 5120000 2048000 167772160 NULL 2040000

5 3 7168000 2048000 184549376 NULL 2040000

Need to create database as follows:
create database dbname on xxx_data1 4000
xxxx_data2 4000
log on xxxx_log 2000
Alter database dbname on
xxxx_data3 4000,
xxxx_data4 4000

7) drop the database and recreate it again with the right order
For details, refer to http://my.sybase.com/detail?id=1324
Resolution
create database as large as the dump file to get the correct
sysusages.
Resolutions: recovery

10431140
Case Number:

1998-08-10
21:47:44.0
Version/EBF: 1191/0
Open Date:

Adaptive Server
Enterprise
OS: HP-UX
Platform: HP-UX PA-RISC
Case Description
Attempting to load a db. The source db has one data device
300 meg and one log device 200 meg, target one has one
datadevice 700 meg and one log device at 200 meg, result
after load shows 3 devices. Why are target devices converted?
Product:

Tip or Workaround
Read the doc id 1324 from the technical library for details.
Resolution
Create database on data_device = 500 log on log_device = 200
then alter the database by 200MB.
Other Sources Related to Issue
TechNote
DocID 1324 in Tech-info Library
Solved Cases

Case
10447969
Number:
1998-09-28
Open Date:
16:47:12.0
Version/EBF: 1103/0

Adaptive Server
Enterprise
OS: Solaris
Platform: Sun Solaris SPARC
Product:

Case Description
After a load from a dump the number of rows for the source
database in sysusages has more rows than the target's.
Tip or Workaround
1> select * from sysusages where dbid=5
2> go
dbid segmap lstart size vstart pad unreservedpgs
------ ----------- ----------- ----------- ----------- -----------------5 3 0 1024 33554432 NULL 640
5 3 1024 1536 33555456 NULL 1536
5 4 2560 1536 50331648 NULL 1528
5 3 4096 512 83886080 NULL 512
5 3 4608 512 83886592 NULL 512
(5 rows affected)
1> drop database test
2> go
1> create database test on datadev1=2, datadev1=3,
logdev1=3,datadev2=1,datadev2=1
2> go

CREATE DATABASE: allocating 1024 pages on disk 'datadev1'

CREATE DATABASE: allocating 1536 pages on disk 'datadev1'
CREATE DATABASE: allocating 1536 pages on disk 'logdev1'
CREATE DATABASE: allocating 512 pages on disk 'datadev2'
CREATE DATABASE: allocating 512 pages on disk 'datadev2'
1> select * from sysusages where dbid=5
2> go
dbid segmap lstart size vstart pad unreservedpgs
------ ----------- ----------- ----------- ----------- -----------------5 7 0 1024 33554432 NULL 632
5 7 1024 1536 33555456 NULL 1536
5 7 2560 1536 50331648 NULL 1536
5 7 4096 512 83886080 NULL 512
5 7 4608 512 83886592 NULL 512
(5 rows affected)
1> load database test from '/tmp/data.dmp'
2> go
Backup Server session id is: 56. Use this value when executing
the
'sp_volchanged' system stored procedure after fulfilling any
volume change
request from the Backup Server.
Backup Server: 6.28.1.1: Dumpfile name 'test982950E7DB '
section number 0001
mounted on disk file '/tmp/data.dmp'
Backup Server: 4.58.1.1: Database test: 10244 kilobytes
LOADed.
Backup Server: 4.58.1.1: Database test: 10252 kilobytes
LOADed.
Backup Server: 3.42.1.1: LOAD is complete (database test).
Use the ONLINE DATABASE command to bring this database
online; SQL Server will
not bring it online automatically.
1> online database test
2> go
Database 'test' is now online.
1> select * from sysusages where dbid=5
2> go
dbid segmap lstart size vstart pad unreservedpgs
------ ----------- ----------- ----------- ----------- ------------------

5 3 0 2560 33554432 NULL 2176

5 4 2560 1536 50331648 NULL 1528
5 3 4096 1024 83886080 NULL 1024
(3 rows affected)
Resolution
Under certain conditions, as detailed below, this is expected
behaviour. There are no disadvantages to this happening, the
data pages are still where they were before only sysusages has
fewer rows, this can be an advantage if the database is
growing as there is limit of 128 fragments per database.
Conditions required for fragments to join.
1. Adjacent fragments (rows in sysusages ) must be on the
same device and contiguous.
2. Prior to the load sysusages.segmap on the target database
does not match with sysusages.segmap from the source
database. (as shown in the example in the tip section).

10391255
Case Number:

1998-05-01
05:22:29.0
Version/EBF: 1102/0
Open Date:

Adaptive Server
Enterprise
OS: UNIX
Platform: HP Tru64
Case Description
Current database is on two 2GB devices. Can the database be
moved to a database on a 4GB device (device was successfully
created on 64bit OS)?
Product:

Tip or Workaround
Not Available
Resolution
The database can be dumped and loaded into the 4GB device if
the segments from the original database both have the same
segmap value and are contiguous.
Other Sources Related to Issue
TechNote

"Segment Remapping with Load Database when Moving a

Database", Doc ID 1324

10391815
Case Number:

1998-05-01
22:10:05.0
Version/EBF: 1150/0
Open Date:

Adaptive Server
Enterprise
OS: Solaris
Platform: Sun Solaris SPARC
Case Description
Problems loading a System 10 database from a dump. When
doing a create database with the data and log on seperate
devices, the space that the previous database dump took is
breaking into segments. Data is being put on a log segment.
Product:

Tip or Workaround
Please Refer to Technote # 1324: Segment Remapping with
load database
Resolution
Drop the database and recreate it according to the sysusages
rows for this database in system 10.