Your database will crash. You don't want that to happen. Depending on the version of Progress and exactly how and why you ran out of space it might be very painful (or impossible) to recover. In the short term keep an eye on it and make sure that you always have plenty of space. In the longer term you need to make sure that after-imaging is enabled, running properly and that you know how to use it to recover.Kopperton said:What will be with them after they will reach 2gb file limit unixware has?
TomBascom said:Your database will crash. You don't want that to happen.
In the short term keep an eye on it and make sure that you always have plenty of space.
Kopperton said:Hi TomBascom. Progress is version 9.1e and I have 10times more free space than whole database is.
The problem I am raising is that what if these .d3 files reach 2gb size which eventually they will. unixware has 2gb file size limit. what happen next.
TomBascom said:By "make sure you always have plenty of space" I meant both on the filesystem and within the storage area.
Area Name Total Blocks High Watermark Free
|
||||||||||||||||||||||||||||||||| |||||||||||| ||||||||||||||
|||||||||| |
|Control Area 31 5 26 |
|Primary Recovery Area 11998 8640 3,358 |
|Schema Area 1471 1451 20 |
|trhead 35309 35299 10 |
|trhead_idx 24001 10729 13,272 |
|trlines 61133 61067 66 |
|trlines_idx 24001 15558 8,443 |
|trother 39085 38984 101 |
|trother_idx 24001 11984 12,017 |
|trsm 24001 10883 13,118 |
|trsm_idx 24001 3540 20,461 |
|trstat 24001 12608 11,393 |
|trstat_idx 24001 2828 21,173 |
|trtrans 88813 88737 76 |
|trtrans_idx 30829 30801 28 |
|trcust 24001 2 23,999 |
|trcust_idx 24001 2 23,999
151,560 TOTAL|
===============================
df.
filesystem kbytes used avail mounted on
/dev/root 4096575 2496874 1599701 /
/dev/stand 32130 5563 26566 /stand
/proc 0 0 0 /proc
/dev/fd 0 0 0 /dev/fd
/dev/_tcp 0 0 0 /dev/_tcp
/dev/dsk/c0b0t0d0sc 2465977 1479757 986220 /rd
/processorfs 0 0 0 /system/processor
/dev/dsk/c0b0t0d1s1 39929552 5557176 34372376 /db
/dev/dsk/c0b0t0d1s2 13309848 4631600 8678248 /usr
If the user leaves for lunch (or goes home for the weekend) leaving the input and the transaction open then the "bi cluster" that records that note cannot be reused. Since the BI file is organized as a ring of clusters this open transaction causes the database manager to add clusters if other users are actively committing transactions. Lots of clusters. Until the original user comes back and finishes the input...
By the way I daresay it's not quite right. Because all you need is to keep bi cluster number in the inner transaction structure, I mean _trans VST. And I think a couple of hundreds bytes isn't a big trouble whereas a size of a new cluster is more significant.You would need to either track all of the notes reated to every open transaction (which would take a lot of memory -- especially for large systems)
I don't think it's quite that simple... you'd need to (at least) keep track of each cluster that each open trx has at least one open note in