Type II and local database

Once you've done the dump and load, just furnish the developers with the new .st file and a backup and they'll be able to recreate the database with the nice new Type II storage areas. In fact, it's imperative that they refresh their databases as they will otherwise have trouble compiling anything to ship to other locations!

Thank you both!

Now it's working, but suddendly I feel insecure about I have correctly writed the new .st file.

So please tell me if I have.

The .st goes like this:

#

b c:\dbs\mecsa

#

d "Schema Area":6,256 c:\dbs\mecsa

#

d "admin":7,256;8 c:\dbs\mecsa f 20480

d "admin":7,256;8 c:\dbs\mecsa f 20480

d "admin":7,256;8 c:\dbs\mecsa f 20480

d "admin":7,256;8 c:\dbs\mecsa f 20480

d "admin":7,256;8 c:\dbs\mecsa

#

d "contab":8,256;8 c:\dbs\mecsa f 204800

d "contab":8,256;8 c:\dbs\mecsa f 204800

d "contab":8,256;8 c:\dbs\mecsa f 204800

d "contab":8,256;8 c:\dbs\mecsa

...and so on

What do you think?

Is there a specific reason that you use small fixed extents? I am no DB expert, but my idea was that nowadays it is perfectly feasable to have a limited nr of large extents or - depending on the size of your db - perhaps even one variable extent with no fixed ones at all.

In the old days we were limited by small memory allocations (-B) but today with 64 bit progress there is practically no limit on the size of the buffer pool, so you can virtually run your progress db as an in-memory database. My previous customer uses a -B of approx 200GB and hard drives are hardly doing anything so spreading your extents is not needed from a hardware point of view

Hello Patrick, we have 32 bit OE 11.6.3. This desicion was taken on regard of the 32-bit DLLs we use.

The DB is not a large one, less than 10 Gb. The OS in Windows server and workstations are 64 bit

Thank you all!

Extent size is not related to -B or bitness.

Nor does the db server need to use 32 bit executables just because clients use 32 bit DLLs.  The db server can easily be 64 bits and you can leave the clients in the dark ages until the coders attain enlightenment.

For such a small database I would strongly recommend that you use a single variable extent for each area.

IOW:

#

b c:\dbs\mecsa

#

d "Schema Area":6,64;1 c:\dbs\mecsa

#

d "admin":7,256;8 c:\dbs\mecsa

#

d "contab":8,256;8 c:\dbs\mecsa

...and so on

This will be much easier to manage.  Fewer files and no need to monitor extent fullness and add new ones.  That will be much more useful for a developer copy of a db.

I also strongly dis-recommend the practice of creating areas based on "function" (admin etc...).  Areas should be based on the technical attributes of the data that they contain.  Attributes such as "data", "indexes", "LOBs", rows per block, size, and activity level.

For a simple, small db you probably just need "data" and "indexes".  If your application uses CLOBs or BLOBs then you ought to also create a "lob" area.

These days I don't start thinking about using fixed extents until I start seeing variable extents larger than 32GB.

You can argue that when extents get too big that you're making certain recovery operations more difficult than they would be with smaller extents (for instance, anything that requires scanning an extent will take longer).

Note:  There is a hard limit of 1TB for an extent -- so you can't quite go with "always use variable no matter what" even if  you do think that it is the best idea since pre-sliced bread.

Note 2: I'm assuming that "and so on..." obviously includes after-image extents.

Thank you, Tom, always enlightining.

.

Shame on us, we are not using AI now, but we will. This is the first stage on the .ST changes,

With this small database, we can do it on two or three stages.

After Imaging should be enabled as a top priority. It's not a luxury. After imaging enables you to restore a database to any point in time in the event of an emergency. You can't do that by enabling Type II, or any other mechanism. How much data can the customer reasonably afford to lose? If you're relying on database backups then the best case scenario is you lose everything since the last good backup. That could be many hours of work.

Also, After Imaging is really easy to enable, and to manage. You can even enable it online so there is no excuse.

Thank you, James. So right.