Quantcast
Channel: SCN: Message List - SAP Adaptive Server Enterprise (SAP ASE) for Custom Applications
Viewing all articles
Browse latest Browse all 3587

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

$
0
0

Hi Pandey,

Adding notes to the SCN after the Incident was created for benefit of those curious about this report.

 

Whenever creating or altering for space, we allocate as many Allocation Units (AU) that are available up until the requested amount.

What this means is let's say we have 10 megs free on a device and you try to alter for 20.  The alter will be successful, giving you 10 megs.

 

Now enter in this problem.  For whatever reason, the size of this device has a non-rounded number of megabytes free.  There are a couple ways this can happen and most commonly seen on raw partitions when the size of the partition isn't quite a whole meg in size.

 

Some math -

This ASE is 2k page size.  An AU is 256 pages in size. 

This means an AU 256*2048 = 524288 bytes or .5 megabyte.

 

Now going back to the alter logic.  We will alter as long as we have free AU's.  In the case of 2k page, this also means we can get into (1.0*sysusages.size/512) to be a non-rounded number as seen in the math above.

 

Why does create_sql not indicate this?

The short answer is create/alter database accepts whole numbers for size specification and not pages.

The technical answer is only integer values are accepted.

Added reason here, is because of the whole number integers for create/alter, the create_sql is not checking for half meg fragments. 

 

I've logged CR 797291 to have create_sql be half meg aware.

 

How do you create so you can load this database?

Using the example above:

You can disk init xxx_data04 to be 7.5M, then when create/alter specify "on xxx_data04='8M'" which in turn will give you the 7.5 megs.  To be safe, have this particular alter all by itself, just to avoid confusion.  This works because device sizes can be created for a specified page count.

 

You can also do a bit of sysusages manipulation during the process which I don't recommend, since updating system tables can be troublesome if not handled carefully.  Essentially it boils down to altering for 8M, subtracting 256 pages (.5M) from size to make 7.5M , run dbcc dbrepair(dbname, remap), then proceed with altering.  Use at your own risk, use a test server first, have master backups, use a transaction, etc. 

 

HTH

Dan


Viewing all articles
Browse latest Browse all 3587

Trending Articles



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