Search results

Thanks for your answers, Tom & Tim! I believe the problem with the "slow physical redo" has been resolved. I discovered that the Progress 10.101B database (using Type1 storage) had used a bi cluster size of 12,288. But, when I re-created the new database in preparation for the load to...

Tom, Thanks so much for your response! One detail that I didn't mention: truncating the bi helps immensely - for about 1 day. We do it after our weekly cold backups, and the database comes back up very quickly afterwards. But, if I have to restart the dbs thereafter, it takes much longer -...

I wish it were that simple. Our disks may be of the "boat anchor" variety, but they're the same "boat anchors" that we used before the D&L. And, the slowness follows the database. As soon as I restore that data to a new database on another server, it starts having the same slow "Physical...

Tom, Thanks for your response. Yes, we're aware that there are some bugs with 10.1B, sp1, and had hoped that using the old locking algorithm (-lkrela) would do the trick. Unfortunately, the vendor has not tested their application on 10.1C, and as such, cannot recommend moving to it yet...

Hi, folks I recently converted the database from Type 1 storage to Type 11, using binary dump & load. The database had already been upgraded to 10.1B, sp 1, last fall and was running fine until the D&L. Now, we receive daily locking errors on one heavily-used table. It appears to occur...

Tom, First, I want to say, Thanks for your help - you were a real life-saver!!! I did the "unlock" command and deleted the bad extents, which allowed me to finish creating the new S.A.'s. Now, however, when I bring up the database, I get the following: $ $ start_db unifiprd OpenEdge...

Hi, folks I hope that someone can help me; I'm in a bit of a bind.... I was creating some new storage areas, when I realized that there was not enough disk space. When I killed the prostrct command (before it could exceed the available diskspace), it left partial data files, apparently in...

Hi, Casper I'm still a relative newbie at Progress, but I did have this error recently (w/o the line that says "Out of free shared memory. Use -Mxs to increas..."). To remedy the situation, all I did was increase the size of the lock table. But, your lock table is already humongous! I...

Hi, Casper I just have a couple of things to add to what I had mentioned earlier. I had thought that we use Type II storage areas because they were storage areas with multiple extents, but after reading more on it, I realize that it's the cluster size that you look at. And, all of my cluster...

Well, that explains it. We do use the variable extent, so that particular scenario is not an issue. My issue is exceeding the limit on storage space size, especially the Schema Area. My understanding is that it was 256 GB in Progress V9, and we were coming close to that (I think), as I was...

Hello again, Casper OK. Operator error, here - I missed a few lines...my apologies..:blush1:...it works great! Thanks.

Thanks for the program, Casper I did try it out, but it doesn't appear to run on my system (tried it through the procedure editor, and it bombed on line 5). But, is there no utility already written within Progress (like the dbanalysis utility) that can give this information (i.e. how big is...

Thanks, Rrojo I had hoped that the figures from the dbanalysis would suffice. Do you really have to run a program just to determine how close your storage area is getting to its limits? my email is bjagnandan@bbandt.com Thanks, Brenda

Greetings! I have a question about storage area size that I'm hoping someone knows about: From the dbanalys output, which figure should I use to determine how big my storage area is getting: the "Block Analysis" total blocks or highwater mark, or the "Record block summary for area "xxx"...

Sounds good to me...I'll give you a call, if that's oK. :)

Thanks for your response! So far, FiServ has offered us nothing in the way of guidance or programs. We had to pay for V10 upgrade "support", but no one there seems to know Progress on Unix very well (at least the folks that we have talked to). I have been trying for a week just to get the...

Casper... I see that I didn't answer one of your questions...do we use 64-bit Progress. The answer is...I thought we were using 32-bit, but can't seem to find where it tells that. I can't find it on the license sheet or any of the promon displays. If you can tell me how to find out, I'll...

Hi, Roy I see that you are using the Unifi application, as I am, and was dealing with the lt-bin-dtl table, which I am, also. Ours is now over 100 GB, and located in the Schema area (Area 6), along with a whole slew of other tables, so I'm looking at putting it in its own area, or at least a...

Thanks, "Tamhas". That's an intriguing idea...I've never copied a table to another area, just did the "tablemove" command... which takes a long time. Do you know if this would be quicker than doing a dump/"delete table"/"recreate on new area"/reload?? When you're trying to move a 100+ GB...

Hello, Casper...please see below