Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

Those are very small logs and not very many of them.  It could be that other stuff is running, writing to the small amount of log space during the time it takes to add the new chunk.  

Basically, you are going to need to add more logical logs.

I see that these logs are in the root dbspace - the same space that you are trying to expand.  I wouldn't think that would be a problem, but maybe you should start with creating a new dbspace for your logs and move them to the new space.

What are the settings for LTXHWM and LTXEHWM?  With so few logs then even if it's 50/60 then it will only be a couple of logs spanned before a long transaction will occur, i.e. need more logical logs.

Mike

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

Well, Mike,

There ain't nothing happening on that server.  When we create a new instance (12.10) all the logs are in the root dbspace. A run of onstat -x shows there are no transactions happening.

I have suggested to my colleague (who is the actual victim here) to add a log dbspace and add logs in there before trying to add the chunk to the rootdbs. But if it is balking at adding a chunk to rootdbs, why will that work to add a new DBsdpace?

So as far as I know I am still clueless (such is my life :-) but willing to try acts of desperation.

Those are very small logs and not very many of them.  It could be that other stuff is running, writing to the small amount of log space during the time it takes to add the new chunk.  

Basically, you are going to need to add more logical logs.

I see that these logs are in the root dbspace - the same space that you are trying to expand.  I wouldn't think that would be a problem, but maybe you should start with creating a new dbspace for your logs and move them to the new space.

What are the settings for LTXHWM and LTXEHWM?  With so few logs then even if it's 50/60 then it will only be a couple of logs spanned before a long transaction will occur, i.e. need more logical logs.

Mike

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

After saying all that, and before seeing Art's reply,

I had R add a 100mb log.  Plenty of room in rootdbs so far.  And the add-chunk succeeded.  But why was this a problem in the firtst place?

LTXHWM was set at 10%,  (What???!!)  With so little log space the original add-chunk spanned 10% of those little logs, somehow, and it barfed.

Problem solved.  We will be adding a few huge log spaces with 100MB logs, once he gets under weigh and get these out of rootdbs, along with the phys log to plog_dbs.

Thanks y'all!

Well, Mike,

There ain't nothing happening on that server.  When we create a new instance (12.10) all the logs are in the root dbspace. A run of onstat -x shows there are no transactions happening.

I have suggested to my colleague (who is the actual victim here) to add a log dbspace and add logs in there before trying to add the chunk to the rootdbs. But if it is balking at adding a chunk to rootdbs, why will that work to add a new DBsdpace?

So as far as I know I am still clueless (such is my life :-) but willing to try acts of desperation.

Those are very small logs and not very many of them.  It could be that other stuff is running, writing to the small amount of log space during the time it takes to add the new chunk.  

Basically, you are going to need to add more logical logs.

I see that these logs are in the root dbspace - the same space that you are trying to expand.  I wouldn't think that would be a problem, but maybe you should start with creating a new dbspace for your logs and move them to the new space.

What are the settings for LTXHWM and LTXEHWM?  With so few logs then even if it's 50/60 then it will only be a couple of logs spanned before a long transaction will occur, i.e. need more logical logs.

Mike

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

@Jacob,

I may be misremembering, or maybe things have changed in recent versions of Informix, but in general, it is better to have several smaller logical logs than a few (or a single) large ones.  This is because the LTXHWM and LTXEHWM percentages are based not on the percentage of logical log pages that are filled, but on the percentage of logical log files. 

From your description, you had the five 5000 page logical logs and added a sixth logical log of 50,000 pages (I'm rounding here), for a total of 125,000 pages. 

If a transaction starts in the last 100 pages of that sixth logical log and requires 16,000 pages to complete, you'd think that it had consumed less than 13% (16,000 / 125,000) of the logical log space.  However, for LTXHWM purposes, it took over 50%, since logical logs 6, 1, 2, 3, and part of 4 are locked until that transaction completes.  Having twenty four 5000 page logical logs would mean that only a little over 20% (logs 6 - 10) would be locked for that duration.

If I'm wrong, I'm sure that someone will chime in with the correct information.

After saying all that, and before seeing Art's reply,

I had R add a 100mb log.  Plenty of room in rootdbs so far.  And the add-chunk succeeded.  But why was this a problem in the firtst place?

LTXHWM was set at 10%,  (What???!!)  With so little log space the original add-chunk spanned 10% of those little logs, somehow, and it barfed.

Problem solved.  We will be adding a few huge log spaces with 100MB logs, once he gets under weigh and get these out of rootdbs, along with the phys log to plog_dbs.

Thanks y'all!

Well, Mike,

There ain't nothing happening on that server.  When we create a new instance (12.10) all the logs are in the root dbspace. A run of onstat -x shows there are no transactions happening.

I have suggested to my colleague (who is the actual victim here) to add a log dbspace and add logs in there before trying to add the chunk to the rootdbs. But if it is balking at adding a chunk to rootdbs, why will that work to add a new DBsdpace?

So as far as I know I am still clueless (such is my life :-) but willing to try acts of desperation.

Those are very small logs and not very many of them.  It could be that other stuff is running, writing to the small amount of log space during the time it takes to add the new chunk.  

Basically, you are going to need to add more logical logs.

I see that these logs are in the root dbspace - the same space that you are trying to expand.  I wouldn't think that would be a problem, but maybe you should start with creating a new dbspace for your logs and move them to the new space.

What are the settings for LTXHWM and LTXEHWM?  With so few logs then even if it's 50/60 then it will only be a couple of logs spanned before a long transaction will occur, i.e. need more logical logs.

Mike

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!

Mark said:

• I may be misremembering, or maybe things have changed in recent versions of Informix, but in general, it is better to have several smaller logical logs than a few (or a single) large ones.  This is because the LTXHWM and LTXEHWM percentages are based not on the percentage of logical log pages that are filled, but on the percentage of logical log files. 

Mark,

I also remember that.  It  was certainly the case in release 4 and maybe 5.  At some point, it changed to a more realistic span of actual log space.  By release 7?  Now I may be misremembering here.  However, that just to get us started.  Before this server is ready for action there will be over 1000 log files of ~100MB each in a 50+GB DBspace.  We ain't wimping out around here! <grin>

@Jacob,

I may be misremembering, or maybe things have changed in recent versions of Informix, but in general, it is better to have several smaller logical logs than a few (or a single) large ones.  This is because the LTXHWM and LTXEHWM percentages are based not on the percentage of logical log pages that are filled, but on the percentage of logical log files. 

From your description, you had the five 5000 page logical logs and added a sixth logical log of 50,000 pages (I'm rounding here), for a total of 125,000 pages. 

If a transaction starts in the last 100 pages of that sixth logical log and requires 16,000 pages to complete, you'd think that it had consumed less than 13% (16,000 / 125,000) of the logical log space.  However, for LTXHWM purposes, it took over 50%, since logical logs 6, 1, 2, 3, and part of 4 are locked until that transaction completes.  Having twenty four 5000 page logical logs would mean that only a little over 20% (logs 6 - 10) would be locked for that duration.

If I'm wrong, I'm sure that someone will chime in with the correct information.

After saying all that, and before seeing Art's reply,

I had R add a 100mb log.  Plenty of room in rootdbs so far.  And the add-chunk succeeded.  But why was this a problem in the firtst place?

LTXHWM was set at 10%,  (What???!!)  With so little log space the original add-chunk spanned 10% of those little logs, somehow, and it barfed.

Problem solved.  We will be adding a few huge log spaces with 100MB logs, once he gets under weigh and get these out of rootdbs, along with the phys log to plog_dbs.

Thanks y'all!

Well, Mike,

There ain't nothing happening on that server.  When we create a new instance (12.10) all the logs are in the root dbspace. A run of onstat -x shows there are no transactions happening.

I have suggested to my colleague (who is the actual victim here) to add a log dbspace and add logs in there before trying to add the chunk to the rootdbs. But if it is balking at adding a chunk to rootdbs, why will that work to add a new DBsdpace?

So as far as I know I am still clueless (such is my life :-) but willing to try acts of desperation.

Those are very small logs and not very many of them.  It could be that other stuff is running, writing to the small amount of log space during the time it takes to add the new chunk.  

Basically, you are going to need to add more logical logs.

I see that these logs are in the root dbspace - the same space that you are trying to expand.  I wouldn't think that would be a problem, but maybe you should start with creating a new dbspace for your logs and move them to the new space.

What are the settings for LTXHWM and LTXEHWM?  With so few logs then even if it's 50/60 then it will only be a couple of logs spanned before a long transaction will occur, i.e. need more logical logs.

Mike

Strange things happen around here.

Kidding aside: We just created a new instance so there is exactly one DBspace with one chunk.  Now we want to add a chunk.

$ onspaces -a rootdbs -p /usr/informix/bnhprod5_rootdbs_ch2.p -o 0 -s 2097104
Verifying physical disk space, please wait ...
Error in COMMIT WORK.   <==== YIKES!

So the space has been verified: The target of the symlink is a raw device file with crw-rw---- permissions (660) and properly owned by informix:informix and the raw file size is 2097152 K - exactly 2GB.  So there's nothing wrong with the file size.

Here's the API version:

EXECUTE FUNCTION task("add chunk", "rootdbs", "/usr/informix/bnhprod5_rootdbs_ch2.p", "2048", "0");

 And the error message is:

12204: RSAM error: Long transaction detected.
Error in line 1
Near character position 97

That's ridiculous! The logs have been backed up!

address          number   flags    uniqid   begin                size     used    %used
243a07fa0        1        U-B----  1        1:17513              5000     5000   100.00
243c3afa0        2        U-B----  2        1:22513              5000     5000   100.00
243e10fa0        3        U-B----  3        1:27513              5000     5000   100.00
243fdefa0        4        U-B----  4        1:32513              5000     5000   100.00
243ffffa0        5        U---C-L  5        1:37513              5000     3424    68.48

Clues anyone? (Colonel Mustard did it in the kitchen with.. Wrong Clue!  ;-)

What could possibly be wrong?  Something  about the device file?

Thanks!