Progress (UNIX 8.2C) prostrct add problem :(

matt_

New Member
Greetings!

One of my databases has run out of space and I am trying to add an extent.

This is my .lg before the crash:
Code:
[FONT=courier new]...
13:07:36 Usr    29: bkioWrite: lseek error 22 on file 24 at -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6081)[/FONT]
 [FONT=courier new]13:07:36 Usr    29:  bkioWrite:Insufficient disk space during write, fd 24, len 16384, offset  -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6091)[/FONT]
 [FONT=courier new]13:07:36 Usr    29: bkioWrite: lseek error 22 on file 24 at -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6081)[/FONT]
[FONT=courier new]13:07:36  Usr    29: bkioWrite:Insufficient disk space during write, fd 24, len  16384, offset -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6091)[/FONT]
 [FONT=courier new]13:07:36 Usr    29: bkioWrite: lseek error 22 on file 24 at -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6081)[/FONT]
[FONT=courier new]13:07:36  Usr    29: bkioWrite:Insufficient disk space during write, fd 24, len  16384, offset -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6091)[/FONT]
 [FONT=courier new]13:07:36 Usr    29: bkioWrite: lseek error 22 on file 24 at -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6081)[/FONT]
[FONT=courier new]13:07:36  Usr    29: bkioWrite:Insufficient disk space during write, fd 24, len  16384, offset -2147483648, file /p_dtr/p_dbs/tmm10.d15. (6091)
...
[/FONT]

I do have enough partition space, so I assume the database ran out of space.

It seems like my variable-length extent is very large.

Code:
root [ /p_dtr/p_dbs ] > ls -l tmm10*
-rwxrwx---   1 root     system    256016384 Apr 15 13:36 tmm10.d1
-rwxrwx---   1 root     system    256016384 Apr 15 13:07 tmm10.d10
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d11
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d12
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d13
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d14
[COLOR=red]-rwxrwx---   1 root     system   2147483648 Apr 15 13:07 tmm10.d15[/COLOR]
-rwxrwx---   1 root     system    256016384 Apr 15 13:02 tmm10.d2
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d3
-rwxrwx---   1 root     system    256016384 Apr 15 13:01 tmm10.d4
-rwxrwx---   1 root     system    256016384 Apr 15 12:06 tmm10.d5
-rwxrwx---   1 root     system    256016384 Apr 15 13:01 tmm10.d6
-rwxrwx---   1 root     system    256016384 Apr 15 12:53 tmm10.d7
-rwxrwx---   1 root     system    256016384 Apr 15 12:33 tmm10.d8
-rwxrwx---   1 root     system    256016384 Apr 15 13:06 tmm10.d9
-rwxrwx---   1 root     system        16384 Mar 30 21:24 tmm10.db
-rwxrwx---   1 root     system     24206514 Apr 15 17:03 tmm10.lg
-rwxrwx---   1 root     system      2248300 Apr 15 13:00 tmm10.lic
-rwxrwx---   1 root     system         1104 Apr 15 16:26 tmm10.st
-rwxrwx---   1 root     system           96 Apr 15 15:32 tmm10add.st

This is the current .st file:

Code:
d /p_dtr/p_dbs/tmm10.d1                                        f 250016
d /p_dtr/p_dbs/tmm10.d2                                        f 250016
d /p_dtr/p_dbs/tmm10.d3                                        f 250016
d /p_dtr/p_dbs/tmm10.d4                                        f 250016
d /p_dtr/p_dbs/tmm10.d5                                        f 250016
d /p_dtr/p_dbs/tmm10.d6                                        f 250016
d /p_dtr/p_dbs/tmm10.d7                                        f 250016
d /p_dtr/p_dbs/tmm10.d8                                        f 250016
d /p_dtr/p_dbs/tmm10.d9                                        f 250016
d /p_dtr/p_dbs/tmm10.d10                                       f 250016
d /p_dtr/p_dbs/tmm10.d11                                       f 250016
d /p_dtr/p_dbs/tmm10.d12                                       f 250016
d /p_dtr/p_dbs/tmm10.d13                                       f 250016
d /p_dtr/p_dbs/tmm10.d14                                       f 250016
d /p_dtr/p_dbs/tmm10.d15
b /bi/tmm10.b1

This is my proposed .st file:
Code:
d /p_dtr/p_dbs/tmm10.d16 f 250016
d /p_dtr/p_dbs/tmm10.d17 f 250016
d /p_dtr/p_dbs/tmm10.d18

I'm having a problem with prostrct add.

Code:
[FONT=courier new]root [ /p_dtr/p_dbs ] > prostrct add tmm10 [/FONT][FONT=Courier New]tmm10add.st[/FONT]
 [FONT=courier new]SYSTEM ERROR: File /p_dtr/p_dbs/tmm10.d15 too small -2147483648, blocksize 8192 extend failed." (4524)[/FONT]

I was thinking that I have to truncate my BI before the prostrct add, but I'm not sure what that affects so I am apprehensive to run this command:

Code:
proutil tmm10 -C truncate bi

Am I completely overlooking something? Sorry for the newbishness of my question, but I am lost on how to proceed, and I don't want to nuke the database.
 
Have you tried making a probkup?

According to Knowledge Center article P1908 you should be able to:

ID: P1908
Title: "Database shutdown with error 6091 with 'offset 2147475456'"
Created: 05/01/2002 Last Modified: 10/16/2008
Status: Verified


Symptoms:
Database abnormal shutdown.
<function>:Insufficient disk space during <system call>, fd <file descriptor>, len <bytes>, offset <bytes>, file <file-name>. (6091)
bkioWrite:Insufficient disk space during write, fd <file descriptor>, len 16384, offset 2147475456, file <file-name>. (6091)
bkxtn: write error, file <file-name> errno: 0. (3646)
SYSTEM ERROR: Unable to extend the database. (111)
<file-name> is a variable-length data extent and is the same for all errors above.
File specified by <file-name> is below 2,147,483,648 bytes.
Database crashes, but can be restarted with no problem.


Facts:
UNIX
Progress 8.x
Progress 9.0x
Progress 9.1A
Progress 9.1B


Cause:
Progress tried to extend the variable-length extent beyond the limit supported by the operating system, which is slightly below 2GB.

Because the Operating System did not allow Progress to expand the extent to exactly 2GB, the database can be recovered.

Had the extent mentioned by <file-name> actually reached 2,147,483,648 bytes, the database would have been unrecoverable.


Fixes:
Given that one of the extents has grown so near the 2GB limit, the best plan of action is to stop the database immediately, and restructure it to a multi-volume database where each extent is well below 2GB.

The easiest way to achieve that is to backup the database using probkup, then create a brand new void database using prostrct create and prorest into the new void database. Please see documentation for further details.
 
File specified by <file-name> is below 2,147,483,648 bytes.
Database crashes, but can be restarted with no problem.

It seems that the filesize is at the limit. So that means it's irrecoverable?
-rwxrwx--- 1 root system 2147483648 Apr 15 13:07 tmm10.d15

Also, an error that I get when I tried to start the database earlier is:

Code:
There is no server for database <filename>. (1423)
** The server terminated with exit code 2. (800)

So it is somewhat starting?

I have an online backup from last night, but I don't think I have enough disk space on the partitions to create a new database. So does that mean I'm relegated to restoring and losing an entire day's work?
 
Did you try making a probkup? You might get lucky.

Once you have made a new backup you should then be able to restore it into a modified structure that has a modified number of extents of smaller size.

Failing that your option is to restore from a day old backup.

If you do not have after-imaging enabled then yes, you would lose a whole day of work.

If you do not have after-imaging you also now know why you need it.

Obviously you should also migrate to supported hardware (with plenty of disk space) and upgrade to a supported release of Progress.
 
Back
Top