Dump and Load Strategies Part II: Dumping Data

Dump and Load Strategies Part II: Dumping Data

Wow - it's been a month since my last blog entry. Time flies!

If you read Part I, you've already analyzed your data and designed your Type II storage areas and you're ready to dump your existing data and load it into the new structure. If you're still using Type I storage areas, this will probably be the slowest part of the entire D&L process so don't despair. The load and the index rebuild should take considerably less time than the dump.

You have three choices when it comes to dumping your data:

  1. ASCII Dictionary Dump
  2. ASCII Custom Dump 
  3. Binary Dump

This blog post is going to concentrate on the binary dump as that's what most of you are going to use. Unless the database is very small or you need to do some conversions during the dump, there's really no reason to use the dictionary dump for anything other than users and sequence current values.

Recent Comments
Guest — Guest
A couple places in the article you wrote about the lazy way is to 'just start all the dumps in parallel'. Did you mean "in series... Read More
Thursday, 07 May 2015 2:02 AM
Paul Koufalis
I did not mean "in series". I really meant "in parallel". I try to run as many binary dumps as possible all at the same time. Yes ... Read More
Thursday, 07 May 2015 1:01 PM
Continue reading
19202 Hits

Dump and Load Strategies Part I: Type II Storage Areas

Dump and Load Strategies Part I: Type II Storage Areas

Congratulations! You finally decided to join the modern world and take advantage of Type II Storage Areas (SAII). Hey - better late than never. There's a lot of old, out-of-date or just-plain-wrong information out there, so ignore all that stuff. I have conveniently digested some useful, pertinent and correct information right here.

Basic stuff

  • You need OpenEdge 10
  • DB Block Size: Pretty self-explanatory. Typically 8Kb on UNIX and 4Kb on Windows and Linux
  • BPC = Blocks Per Cluster: The number of database blocks formatted each time an object requires more space
    • Valid values are 8, 64, 512
  • RPB = Records per Block: How many ROWIDs should be reserved for each database block
    • Valid values are 1, 2, 4, 8, 16, 32, 64, 128 or 256
  • Keep data, indexes and LOBs segregated 
  • Storage area are typically defined in a file called


Controversial Assumptions 

A few seasoned DBAs will disagree with the following assumptions. These DBAs are wrong except in very specific cases (0.1% of you) and I can and have proven it mathematically.

Recent Comments
Guest — Rick
Hi Paul, Thanks for this interesting piece of information on SAII. I've been doing quite a few migrations from I to II for our cus... Read More
Wednesday, 06 May 2015 8:08 PM
Paul Koufalis
For such small databases (10 Gb), I wouldn't even bother with any of that. I would just create two SAII for data and two SAII for ... Read More
Thursday, 07 May 2015 12:12 AM
Guest — RichardS
In this statement there is a typo: But Paul, what about an index area? The answer is 64. RPB actually has no meaning for index obj... Read More
Friday, 08 May 2015 3:03 PM
Continue reading
21131 Hits

Is Progress Going to Audit Your Licences? YES!

Is Progress Going to Audit Your Licences?  YES!

Disclaimer: I am not a lawyer and this is not legal advice. The information below may or may not be applicable in your environment.

How many of you have been through a licence audit recently? If you haven't then expect it...and soon. Progress has relied on honour-based licensing for 30 years and now...well...maybe now they're questioning your honour just a little bit!

Recent Comments
Tom Bascom
One small comment -- do not assume that you are under-licensed. Many clients discover that they have a bunch of licenses that the... Read More
Monday, 09 March 2015 3:03 PM
Guest — Montoya
Will Progress do these auditories in all the world?
Tuesday, 17 March 2015 7:07 PM
Paul Koufalis
@Montoya: I would expect yes.
Tuesday, 17 March 2015 10:10 PM
Continue reading
20419 Hits

Migrating OpenEdge to Linux is Easier than You Think

Migrating OpenEdge to Linux is Easier than You Think

Over the past 10 or so years, the number of [AIX, HPUX, Solaris] to Linux migrations have been increasing steadily, along with the "safe" recommended maximum number of concurrent users. The reason is simple, of course: cost. Unless your OpenEdge application is serving thousands of users, Linux can probably do the job just as well as one of the proprietary Unix flavours. If you have less than 250 concurrent users then this should be a no-brainer for 98% of you.

Here are some points to consider for the OpenEdge migration:

Recent comment in this post
Kandavel Elangovan
Very useful info!! Waiting for your blog on OE Upgradation
Tuesday, 24 February 2015 6:06 PM
Continue reading
21667 Hits

OUCH! Backup Time Stamp on Windows

OUCH! Backup Time Stamp on Windows

I was called in to consult at a site where the backups were exhibiting strange behaviour. The backup file was the normal 15Gb in size and the time stamp was from last night, but when they restored it in test there was no new data.  In fact, the most recent data they could find was from a couple of weeks ago.

Looking at the DB log file, it didn't take long to ascertain that the backups were actually failing.  On Windows, if the backup file already exists, probkup just writes on top of it without resetting the size to zero. Furthermore, even if no backup ever occurred, probkup still "touched" the file, changing the time stamp.  The result: a full sized backup file with a valid date and time stamp but still the contents from two weeks ago.

Continue reading
19179 Hits