Quantcast
Channel: SCN: Message List
Viewing all articles
Browse latest Browse all 2806

Re: load database xx with listonly=create_sql giving wrong ddl for database

$
0
0

Hi David,

The safest route is to get to the .5 meg fragment naturally.  What I mean is you would alter on an existing device that just so happens to have a .5 meg AU at the end.  You can fill the device with a dummy database first leaving the desired amount free, then alter as needed.  Once this is done then finally drop the dummy filler database.

 

Here's a way to quickly check if you have a .5 meg device on 2k page ASE

1> select name,(1.0*high+1-low)/512 from sysdevices where (1.0*high+1-low)/512 %1 !=0 and status !=16

2> go

name

 

 

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

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

halfmeg

                       7.500000000000

 

 

(1 row affected)

 

The manual update method can be done.  Again, throwing considerable caution here as modifying sysusages can get you into trouble very quickly if you aren't careful.

 

Finally the other safe route is a database can load as long as it is the same size or larger than the dump.  The fragments should remap.

 

Using the example from the first posting

1> select segmap, lstart, size from sysusages where dbid=db_id("test")

2> go

segmap      lstart     size

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

           3          0       5120

           4       5120       5120

           3      10240       3840  <<This is the 7.5M fragment

           4      14080       5120

 

 

(4 rows affected)

 

Let's create and load a copy.

1> create database testload on reprodata=10 log on reprolog=10

2> go

1> alter database testload on reprodata=8  --this will not be 7.5, but a full 8M

2> go

1> alter database testload log on reprolog=10

2> go

--sysusages BEFORE load

1> select segmap, lstart, size from sysusages where dbid=db_id("testload")

2> go

segmap      lstart     size

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

           3          0       5120

           4       5120       5120

           3      10240       4096

           4      14336       5120

 

Now let's load the dump of the source to it.

1> load database testload from "/tmp/test.dmp"

2> go

[snip]

Backup Server: 3.42.1.1: LOAD is complete (database testload).

All dumped pages have been loaded. ASE is now clearing pages above page 19200,

which were not present in the database just loaded.

ASE has finished clearing database pages.

...

1> online database testload

2> go

1> select segmap, lstart, size from sysusages where dbid=db_id("testload")

2> go

segmap      lstart     size

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

           3          0       5120

           4       5120       5120

           3      10240       3840

           4      14080       5120

           3      19200        256

 

 

(5 rows affected)

Now you can see the extra unused .5 meg is tacked on to the end and the 7.5M fragment is regenerated just as it existed in the dump.

 

You could then do some tricks to swallow this space up into a full fragment.

Options include

"alter database off" to remove it entirely

make your next alter add a half meg using the same logic discussed in this thread.

 

Since we are only looking at a single AU, the shortest route to a final solution might be to go straight to alter database off to shrink 256 pages from the device fragment.  Future dump/load can reconcile the database hole.  Alter database accepts page ranges. 

 

Cheers

Dan


Viewing all articles
Browse latest Browse all 2806

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>