</style><!--[if gte mso 9]><xml><o:shapedefaults v:ext="edit" spidmax="1026" />
</style><!--[if gte mso 9]><xml><o:shapedefaults v:ext="edit" spidmax="1026" />
Hi All,
So I needed to run auditdb on a database…
Wed May 5 09:36:30 2021 E_DM1206_ATP_TOO_MANY_TX Too many
simultaneous transactions.
…
Lots and lots of these, and no transaction details whatsoever.
Never seen that one before!
I tried to restrict it to a specific table of interest, but got the
same result.
Ideas?
Marty
_______________________________________________
Info-ingres mailing list
Info-ingres@lists.planetingres.org https://lists.planetingres.org/mailman/listinfo/info-ingres
it is a new feature. I generated the situation accidentally by
messing with journals involved DR syncronisation to another server.
Level 2 support mentioned there is a hard coded maximum number of open transactions.
it is a new feature. I generated the situation accidentally by messing
with journals involved DR syncronisation to another server.
Level 2 support mentioned there is a hard coded maximum number of open transactions.
I would be interested in seeing results from:
egrep 'End : |Begin :' auditfile | awk '{print $5}' | sort | uniq
-c | sort | more
It should have all the open transactions at the top if i did this right
on my phone.
On Wed, 5 May 2021, 9:13 pm Martin Bowes, <martin.bowes@ndph.ox.ac.uk>
wrote:
Thanks Paul, that’s very interesting intel.
2048 seems a low number in this day and age. Did they hint that this may
be bumped or configurable in a later release?
Marty
*From:* Paul White <paul.white@shift7solutions.com.au>
*Sent:* 05 May 2021 12:06
*To:* info-ingres@lists.planetingres.org
*Subject:* Re: [Info-ingres] Error from auditdb
From case 1176237
*Actually, it is not strictly "simultaneous" transactions in terms of
transactions that were running at the same time and not committed (as I
initially thought and tried to build with a test case). The 2048 limitation >> is rather transactions to be processed in one auditdb run which is also why >> the message disappears when using -e/-b limiting the data to be processed.* >>
I too would be interested to hear what the transaction limit was!
Marty
Did they mention what the limit is?
Roy
The comment doesnt make sense because my daily auditdb sometimes records
over 100k transactions.
I haven't returned to the implications of the comment because in my case
the problem started on the DR server running incremental rollforward on
journals I had collected from two different instances. It was SIGSEGV
TUPLE_MISMATCH and all sorts of errors, errlog filled the disk yada yada.
At the root of the problem was a table which was originally created
unjournalled and was not replicating properly.
As part of the issue, I found auditdb had stopped recording the Begin of
transactions. I think it is in the middle of sysmod.
Begin : Transaction Id 00005ea5138c69af 13-Feb-2021 02:52:13.75 Username ingres
Fcreate : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf6x1.m00
Modify : Transaction Id 00005ea5138c69af Id (225,0) Table [ii_vqtables ,$ingres ]
Update/Replace : Transaction Id 00005ea5138c69af Id (1,0) Table [iirelation,$ingres]
Old: <225|0|8|0|2|11|2445317|0|0|5|1|1|0|1611125819|1612538207|1612538207|104786|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|4|1
6|0|70|1|0|84|84|84|84|68|0|0|0|0|||^A|$ingres|ii_vqtables> >>
New: <225|0|8|0|2|11|2445317|2048|0|5|1|1|0|1611125819|1613145133|1613145133|771094|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|
4|16|0|70|1|0|84|84|84|84|68|0|0|0|0|||^A|$ingres|ii_vqtables>
Frename : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ aaaaaaob.t00 to
rtf6zr.d00
Frename : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf6x1.m00 to
aaaaaaob.t00
End : Transaction Id 00005ea5138c69af 13-Feb-2021 02:52:13.78
Begin : Transaction Id 00005ea5138c69b3 13-Feb-2021 02:52:13.79 Username ingres
Fcreate : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf61h.m00
Modify : Transaction Id 00005ea5138c69b3 Id (219,0) Table [ii_stored_nstrings ,$ingres ]
Update/Replace : Transaction Id 00005ea5138c69b3 Id (1,0) Table [iirelation,$ingres]
Old: <219|0|4|0|2|11|2379781|0|0|5|1|1|0|1611125817|1612538207|1612538207|158487|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|4|1
6|0|70|1|0|1800|1800|1800|1800|41|0|0|0|0|||^A|$ingres|ii_stored_nstrings>
New: <219|0|4|0|2|11|2379781|2048|0|5|1|1|0|1611125817|1613145133|1613145133|836549|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|
4|16|0|70|1|0|1800|1800|1800|1800|41|0|0|0|0|||^A|$ingres|ii_stored_nstrings>
Frename : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ aaaaaanl.t00 to
rtf628.d00
Frename : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf61h.m00 to
aaaaaanl.t00
End : Transaction Id 00005ea5138c69b3 13-Feb-2021 02:52:13.85
Update/Replace : Transaction Id 00005ea51393a887 Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4172|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1730560|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4172|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1731584|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393a887
Update/Replace : Transaction Id 00005ea51393b6de Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4173|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1731584|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4173|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1732608|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393b6de
Update/Replace : Transaction Id 00005ea51393bebc Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4174|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1732608|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4174|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1733632|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393bebc
(goes on for several hundred mini transactions)
Paul
_______________________________________________
Info-ingres mailing list
Info-ingres@lists.planetingres.org
https://lists.planetingres.org/mailman/listinfo/info-ingres
Thanks Paul, that’s very interesting intel.
2048 seems a low number in this day and age. Did they hint that this may
be bumped or configurable in a later release?
Marty
*From:* Paul White <paul.white@shift7solutions.com.au>
*Sent:* 05 May 2021 12:06
*To:* info-ingres@lists.planetingres.org
*Subject:* Re: [Info-ingres] Error from auditdb
From case 1176237
*Actually, it is not strictly "simultaneous" transactions in terms of transactions that were running at the same time and not committed (as I initially thought and tried to build with a test case). The 2048 limitation is rather transactions to be processed in one auditdb run which is also why the message disappears when using -e/-b limiting the data to be processed.*
I too would be interested to hear what the transaction limit was!
Marty
Did they mention what the limit is?
Roy
The comment doesnt make sense because my daily auditdb sometimes records
over 100k transactions.
I haven't returned to the implications of the comment because in my case
the problem started on the DR server running incremental rollforward on journals I had collected from two different instances. It was SIGSEGV TUPLE_MISMATCH and all sorts of errors, errlog filled the disk yada yada.
At the root of the problem was a table which was originally created unjournalled and was not replicating properly.
As part of the issue, I found auditdb had stopped recording the Begin of transactions. I think it is in the middle of sysmod.
Begin : Transaction Id 00005ea5138c69af 13-Feb-2021 02:52:13.75 Username ingres
Fcreate : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf6x1.m00
Modify : Transaction Id 00005ea5138c69af Id (225,0) Table [ii_vqtables ,$ingres ]
Update/Replace : Transaction Id 00005ea5138c69af Id (1,0) Table [iirelation,$ingres]
Old: <225|0|8|0|2|11|2445317|0|0|5|1|1|0|1611125819|1612538207|1612538207|104786|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|4|1
6|0|70|1|0|84|84|84|84|68|0|0|0|0|||^A|$ingres|ii_vqtables>
New: <225|0|8|0|2|11|2445317|2048|0|5|1|1|0|1611125819|1613145133|1613145133|771094|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|
4|16|0|70|1|0|84|84|84|84|68|0|0|0|0|||^A|$ingres|ii_vqtables>
Frename : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ aaaaaaob.t00 to
rtf6zr.d00
Frename : Transaction Id 00005ea5138c69af File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf6x1.m00 to
aaaaaaob.t00
End : Transaction Id 00005ea5138c69af 13-Feb-2021 02:52:13.78
Begin : Transaction Id 00005ea5138c69b3 13-Feb-2021 02:52:13.79 Username ingres
Fcreate : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf61h.m00
Modify : Transaction Id 00005ea5138c69b3 Id (219,0) Table [ii_stored_nstrings ,$ingres ]
Update/Replace : Transaction Id 00005ea5138c69b3 Id (1,0) Table [iirelation,$ingres]
Old: <219|0|4|0|2|11|2379781|0|0|5|1|1|0|1611125817|1612538207|1612538207|158487|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|4|1
6|0|70|1|0|1800|1800|1800|1800|41|0|0|0|0|||^A|$ingres|ii_stored_nstrings>
New: <219|0|4|0|2|11|2379781|2048|0|5|1|1|0|1611125817|1613145133|1613145133|836549|100000|0|0|0|80|80|70|0|0|8192|0|0|0|0|3|
4|16|0|70|1|0|1800|1800|1800|1800|41|0|0|0|0|||^A|$ingres|ii_stored_nstrings>
Frename : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ aaaaaanl.t00 to
rtf628.d00
Frename : Transaction Id 00005ea5138c69b3 File /data/ingresII/ingres/data/default/ctrust_docs_2021/ rtf61h.m00 to
aaaaaanl.t00
End : Transaction Id 00005ea5138c69b3 13-Feb-2021 02:52:13.85
Update/Replace : Transaction Id 00005ea51393a887 Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4172|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1730560|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4172|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1731584|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393a887
Update/Replace : Transaction Id 00005ea51393b6de Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4173|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1731584|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4173|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1732608|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393b6de
Update/Replace : Transaction Id 00005ea51393bebc Id (1,0) Table [iirelation,$ingres]
Old: <247|0|2|0|1|11|3215364|67110914|4174|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1732608|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
New: <247|0|2|0|1|11|3215364|67110914|4174|38|1|1|0|1611319122|1613142939|1613143751|441340|100000|0|0|0|80|80|70|0|0|16384|0
|0|0|1733632|36|4|16|0|70|1|0|37|37|37|37|27|0|0|0|0|||^A|ingres|crm_doc2021>
End Mini: Transaction Id 00005ea51393bebc
(goes on for several hundred mini transactions)
Paul
_______________________________________________
Info-ingres mailing list
Info-ingres@lists.planetingres.org https://lists.planetingres.org/mailman/listinfo/info-ingres
The alteration to iirelation affects only the rellow_logkeyfield. Anyoneknow what that refers to?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 418 |
Nodes: | 16 (2 / 14) |
Uptime: | 38:06:26 |
Calls: | 8,810 |
Calls today: | 6 |
Files: | 13,305 |
Messages: | 5,971,429 |