Issue about logical restore
Posted in 2013
A user on IDS 9.30.UC2 hit "out of virtual shared memory" and an assertion failure (rsarcutl.c / dologrecvr) during the logical restore phase of setting up an HDR secondary with ontape -p, as the secondary kept allocating virtual segments until SHMTOTAL was exceeded. Art Kagel first suggested a fresh archive/retry or IBM support (unavailable, version long out of support). An IBM support poster called it likely a defect but suggested working around the memory shortage by raising SHMTOTAL or cutting memory use (fewer OFF_RECVRY_THREADS, smaller LOGBUFF, matched on both servers). Art later advised raising the kernel's shared-memory limit and setting SHMTOTAL to 0. No confirmation that the fix worked is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Error Codes & Troubleshooting
Hi,
I need help on an issue which occur during logical restore on Informix
Dynamic Server Version 9.30.UC2
can someone help me?
When I run a logical restore, I get an the error message such as the
one reported at the end of email.
How can I limit the number of virtual shared memory segment used during
logical restore ?
Dynamically allocated new virtual shared memory segment (size 10132KB)
15:00:37 Dynamically allocated new virtual shared memory segment (size
10132KB)
15:00:37 Dynamically allocated new virtual shared memory segment (size
10132KB)
15:00:37 Size of resident + virtual segments 165320KB + 2751156KB >
2910000KB
15:00:37 total allowed by configuration parameter SHMTOTAL
15:00:37 out of virtual shared memory
15:00:37 Assert Failed: ISAM error: An error has occurred during
logical restore.
15:00:37 Informix Dynamic Server Version 9.30.UC2
15:00:37 Who: Session(18, root@server4, 0, 348602480)
Thread(30, logrecover, 14c47c18, 1)
File: rsarcutl.c Line: 127
15:00:37 Action: dologrecvr()/add_Qbuf
15:00:37 stack trace for pid 20705 written to /tmp/af.406e285
15:00:37 See Also: /tmp/af.406e285
15:00:37 ISAM error: An error has occurred during logical restore.
Thanks in advance, Francesco.
15:00:37
15:00:37 Informix Dynamic Server Version 9.30.UC2 Software Serial Number
AAD#J315426
15:00:37 Assert Failed: ISAM error: An error has occurred during logical
restore.
15:00:37 Who: Session(18, root@server4, 0, 348602480)
Thread(30, logrecover, 14c47c18, 1)
File: rsarcutl.c Line: 127
15:00:37 Action: dologrecvr()/add_Qbuf
15:00:37 Stack for thread: 30 logrecover
base: 0x1d252000
len: 69632
pc: 0x08554640
tos: 0x1d262920
state: running
vp: 1
0x08554640 (oninit)afstack (0x1d251018, 0x87a02e0, 0x50e1, 0x1d2629d8,
0x1d24ab80, 0xfe)
0x08553cdf (oninit)afhandler(0x1, 0x1d24ab80, 0x0, 0x8774201, 0x401, 0x1)
0x08553772 (oninit)afwarn_interface(0x1d24ab80, 0x0, 0x8774201, 0x87725c0,
0x7f, 0xb1)
0x0843b045 (oninit)oops_error(0x1d24ab80, 0x8774201, 0xb1, 0xa, 0x0, 0x0)
0x08451dd7 (oninit)dologrecvr(0x1d24a688, 0x0, 0x0, 0x0, 0x0, 0x18)
0x0853d0f9 (oninit)startup (0x18, 0x1d2e3418, 0x1d250fd8, 0x80418, 0x3a5b4809,
0x0)
0x00000000 (*nosymtab*)0x0
15:00:37 See Also: /tmp/af.406e285
---------------------------------
Begin System Alarm Program Output
---------------------------------
Assertion Failure Type: Warning
Host Name: server4
Database Server Name: NULL
Time of failure: dom feb 17 15:00:37 CET 2013
AF file: /tmp/af.406e285
Shared memory file: None
System Blocking: OFF
-------------------------------
End System Alarm Program Output
-------------------------------
15:00:37 sh /opt/informix/etc/evidence.sh 1 0 /tmp/af.406e285 18 0x14c47c18 30
0x1d251018 1025 0 0 0 0
15:00:37
------------------ End of assertion failure 0 -----------------
This isn't something you can get help for here. You could try the archive
and restore again or you can call IBM support or open a support case (PMR)
on the IBM Support web site (www.ibm.com/support and click on <Service
Requests and PMRs> in the menu tabs at the top of the page).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Feb 27, 2013 at 8:20 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Hi,
> I need help on an issue which occur during logical restore on Informix
> Dynamic Server Version 9.30.UC2
> can someone help me?
>
> When I run a logical restore, I get an the error message such as the
> one reported at the end of email.
> How can I limit the number of virtual shared memory segment used during
> logical restore ?
>
> Dynamically allocated new virtual shared memory segment (size 10132KB)
> 15:00:37 Dynamically allocated new virtual shared memory segment (size
> 10132KB)
> 15:00:37 Dynamically allocated new virtual shared memory segment (size
> 10132KB)
> 15:00:37 Size of resident + virtual segments 165320KB + 2751156KB >
> 2910000KB
> 15:00:37 total allowed by configuration parameter SHMTOTAL
> 15:00:37 out of virtual shared memory
>
> 15:00:37 Assert Failed: ISAM error: An error has occurred during
> logical restore.
>
> 15:00:37 Informix Dynamic Server Version 9.30.UC2
> 15:00:37 Who: Session(18, root@server4, 0, 348602480)
>
> Thread(30, logrecover, 14c47c18, 1)
>
> File: rsarcutl.c Line: 127
> 15:00:37 Action: dologrecvr()/add_Qbuf
> 15:00:37 stack trace for pid 20705 written to /tmp/af.406e285
> 15:00:37 See Also: /tmp/af.406e285
> 15:00:37 ISAM error: An error has occurred during logical restore.
>
> Thanks in advance, Francesco.
>
> 15:00:37
> 15:00:37 Informix Dynamic Server Version 9.30.UC2 Software Serial Number
> AAD#J315426
>
> 15:00:37 Assert Failed: ISAM error: An error has occurred during logical
> restore.
>
> 15:00:37 Who: Session(18, root@server4, 0, 348602480)
>
> Thread(30, logrecover, 14c47c18, 1)
>
> File: rsarcutl.c Line: 127
> 15:00:37 Action: dologrecvr()/add_Qbuf
> 15:00:37 Stack for thread: 30 logrecover
>
> base: 0x1d252000
> len: 69632
>
> pc: 0x08554640
> tos: 0x1d262920
> state: running
>
> vp: 1
>
> 0x08554640 (oninit)afstack (0x1d251018, 0x87a02e0, 0x50e1, 0x1d2629d8,
> 0x1d24ab80, 0xfe)
> 0x08553cdf (oninit)afhandler(0x1, 0x1d24ab80, 0x0, 0x8774201, 0x401, 0x1)
> 0x08553772 (oninit)afwarn_interface(0x1d24ab80, 0x0, 0x8774201, 0x87725c0,
> 0x7f, 0xb1)
> 0x0843b045 (oninit)oops_error(0x1d24ab80, 0x8774201, 0xb1, 0xa, 0x0, 0x0)
> 0x08451dd7 (oninit)dologrecvr(0x1d24a688, 0x0, 0x0, 0x0, 0x0, 0x18)
> 0x0853d0f9 (oninit)startup (0x18, 0x1d2e3418, 0x1d250fd8, 0x80418,
> 0x3a5b4809,
> 0x0)
> 0x00000000 (*nosymtab*)0x0
>
> 15:00:37 See Also: /tmp/af.406e285
>
> ---------------------------------
> Begin System Alarm Program Output
> ---------------------------------
>
> Assertion Failure Type: Warning
> Host Name: server4
> Database Server Name: NULL
> Time of failure: dom feb 17 15:00:37 CET 2013
> AF file: /tmp/af.406e285
> Shared memory file: None
> System Blocking: OFF
>
> -------------------------------
> End System Alarm Program Output
> -------------------------------
>
> 15:00:37 sh /opt/informix/etc/evidence.sh 1 0 /tmp/af.406e285 18
> 0x14c47c18 30
> 0x1d251018 1025 0 0 0 0
> 15:00:37
> ------------------ End of assertion failure 0 -----------------
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--e89a8fb207a404389904d6b5c63e
Il 27/02/2013 15:41, Art Kagel ha scritto:
> This isn't something you can get help for here. You could try the archive
> and restore again or you can call IBM support or open a support case (PMR)
> on the IBM Support web site (www.ibm.com/support and click on<Service
> Requests and PMRs> in the menu tabs at the top of the page).
>
> Art
>
> Art S. Kagel
Thanks for your reply,
the problem arise when I try to configure the primary and secondary
server for HDR replication.
I run an ontape -s -L 0 on primary and then, after transferring the
appropriate file, I run ontape -p on secondary.
The problem arise when the primary starts an "
15:01:26 DR: Sending log 190547, size 5000 pages, 57.78 percent used
15:01:41 DR: Sending log 190548 (current), size 5000 pages, 0.86
percent used
"
How can I avoid this ?
There's nothing to avoid, that's what the primary is supposed to do but
something is not right on the secondary, it is having trouble applying the
logical log record(s) sent to it by the primary. The communications may be
flaky, or the last log record is not complete or you've hit a bug. Are all
of your databases logged? Having unlogged databases in a replicated server
can cause some trouble occassionally.
Beyond that, I'll repeat myself: Call IBM
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Feb 27, 2013 at 8:56 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 27/02/2013 15:41, Art Kagel ha scritto:
> > This isn't something you can get help for here. You could try the archive
> > and restore again or you can call IBM support or open a support case
> (PMR)
> > on the IBM Support web site (www.ibm.com/support and click on<Service
> > Requests and PMRs> in the menu tabs at the top of the page).
> >
> > Art
> >
> > Art S. Kagel
>
> Thanks for your reply,
> the problem arise when I try to configure the primary and secondary
> server for HDR replication.
> I run an ontape -s -L 0 on primary and then, after transferring the
> appropriate file, I run ontape -p on secondary.
>
> The problem arise when the primary starts an "
> 15:01:26 DR: Sending log 190547, size 5000 pages, 57.78 percent used
> 15:01:41 DR: Sending log 190548 (current), size 5000 pages, 0.86
> percent used
> "
> How can I avoid this ?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec54d3f8443be4204d6b64527
Il 27/02/2013 16:17, Art Kagel ha scritto:
> There's nothing to avoid, that's what the primary is supposed to do but
> something is not right on the secondary, it is having trouble applying the
> logical log record(s) sent to it by the primary. The communications may be
> flaky, or the last log record is not complete or you've hit a bug. Are all
> of your databases logged? Having unlogged databases in a replicated server
> can cause some trouble occassionally.
>
> Beyond that, I'll repeat myself: Call IBM
>
I'm sorry to insist, bu I haven't a support from Ibm !
This is the output of onstat -l on primary
Informix Dynamic Server Version 9.30.UC2 -- On-Line (Prim) -- Up
01:21:25 -- 879944 Kbytes
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-1 0 5000 4 1 4.00
phybegin physize phypos phyused %used
100107 50000 2441 0 0.00
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-2 0 5000 20 16 16 1.2 1.0
Subsystem numrecs Log Space used
OLDRSAM 20 1040
address number flags uniqid begin size used %used
4ec809f0 1 U-B---- 190551 10c457 5000 1 0.02
4ec80a28 2 U-B---- 190552 10d7df 5000 1 0.02
4ec80a60 3 U-B---- 190553 10eb67 5000 1 0.02
4ec80a98 4 U-B---- 190554 10feef 5000 2 0.04
4ec80ad0 5 U---C-L 190555 111277 5000 5 0.10
4ec80b08 6 F------ 0 1125ff 5000 0 0.00
4ec80b40 7 U-B---- 190547 113987 5000 2889 57.78
4ec80b78 8 U-B---- 190548 114d0f 5000 45 0.90
4ec80bb0 9 U-B---- 190549 116097 5000 1 0.02
4ec80be8 10 U-B---- 190550 11741f 5000 1 0.02
10 active, 10 total
From secondary:
Informix Dynamic Server Version 9.30.UC2 -- Fast Recovery (Sec) --
Up 00:03:32 -- 2906344 Kbytes
Blocked:CKPT
Physical Logging
Buffer bufused bufsize numpages numwrits pages/io
P-2 0 5000 0 0 0.00
phybegin physize phypos phyused %used
100107 50000 2441 0 0.00
Logical Logging
Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
L-1 0 5000 0 0 0 0.0 0.0
Subsystem numrecs Log Space used
address number flags uniqid begin size used %used
14c809f0 1 F------ 0 10c457 5000 0 0.00
14c80a28 2 F------ 0 10d7df 5000 0 0.00
14c80a60 3 F------ 0 10eb67 5000 0 0.00
14c80a98 4 F------ 0 10feef 5000 0 0.00
14c80ad0 5 U---C-L 190555 111277 5000 1 0.02
14c80b08 6 F------ 0 1125ff 5000 0 0.00
14c80b40 7 F------ 0 113987 5000 0 0.00
14c80b78 8 F------ 0 114d0f 5000 0 0.00
14c80bb0 9 F------ 0 116097 5000 0 0.00
14c80be8 10 F------ 0 11741f 5000 0 0.00
Can I clear log from primary or disable log from primary to avoid this
problem ?
I've not been following this thread too closely, however I would not try to
'insist' on anything. People in this forum are volunteers on whom you are
relying rather than paying IBMs maintenance charges.
You haven't included much of any previous posts to set the context so it is
difficult to offer much constructive advice (some log extracts would be
useful)
but there does not seem to be too much wrong here.
Keith
On 27 February 2013 15:25, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 27/02/2013 16:17, Art Kagel ha scritto:
> > There's nothing to avoid, that's what the primary is supposed to do but
> > something is not right on the secondary, it is having trouble applying
> the
> > logical log record(s) sent to it by the primary. The communications may
> be
> > flaky, or the last log record is not complete or you've hit a bug. Are
> all
> > of your databases logged? Having unlogged databases in a replicated
> server
> > can cause some trouble occassionally.
> >
> > Beyond that, I'll repeat myself: Call IBM
> >
> I'm sorry to insist, bu I haven't a support from Ibm !
>
> This is the output of onstat -l on primary
> Informix Dynamic Server Version 9.30.UC2 -- On-Line (Prim) -- Up
> 01:21:25 -- 879944 Kbytes
>
> Physical Logging
> Buffer bufused bufsize numpages numwrits pages/io
>
> P-1 0 5000 4 1 4.00
>
> phybegin physize phypos phyused %used
>
> 100107 50000 2441 0 0.00
>
> Logical Logging
> Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
>
> L-2 0 5000 20 16 16 1.2 1.0
>
> Subsystem numrecs Log Space used
>
> OLDRSAM 20 1040
>
> address number flags uniqid begin size used %used
> 4ec809f0 1 U-B---- 190551 10c457 5000 1 0.02
> 4ec80a28 2 U-B---- 190552 10d7df 5000 1 0.02
> 4ec80a60 3 U-B---- 190553 10eb67 5000 1 0.02
> 4ec80a98 4 U-B---- 190554 10feef 5000 2 0.04
> 4ec80ad0 5 U---C-L 190555 111277 5000 5 0.10
> 4ec80b08 6 F------ 0 1125ff 5000 0 0.00
> 4ec80b40 7 U-B---- 190547 113987 5000 2889 57.78
> 4ec80b78 8 U-B---- 190548 114d0f 5000 45 0.90
> 4ec80bb0 9 U-B---- 190549 116097 5000 1 0.02
> 4ec80be8 10 U-B---- 190550 11741f 5000 1 0.02
> 10 active, 10 total
>
> >From secondary:
>
> Informix Dynamic Server Version 9.30.UC2 -- Fast Recovery (Sec) --
> Up 00:03:32 -- 2906344 Kbytes
> Blocked:CKPT
>
> Physical Logging
> Buffer bufused bufsize numpages numwrits pages/io
>
> P-2 0 5000 0 0 0.00
>
> phybegin physize phypos phyused %used
>
> 100107 50000 2441 0 0.00
>
> Logical Logging
> Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
>
> L-1 0 5000 0 0 0 0.0 0.0
>
> Subsystem numrecs Log Space used
>
> address number flags uniqid begin size used %used
> 14c809f0 1 F------ 0 10c457 5000 0 0.00
> 14c80a28 2 F------ 0 10d7df 5000 0 0.00
> 14c80a60 3 F------ 0 10eb67 5000 0 0.00
> 14c80a98 4 F------ 0 10feef 5000 0 0.00
> 14c80ad0 5 U---C-L 190555 111277 5000 1 0.02
> 14c80b08 6 F------ 0 1125ff 5000 0 0.00
> 14c80b40 7 F------ 0 113987 5000 0 0.00
> 14c80b78 8 F------ 0 114d0f 5000 0 0.00
> 14c80bb0 9 F------ 0 116097 5000 0 0.00
> 14c80be8 10 F------ 0 11741f 5000 0 0.00
>
> Can I clear log from primary or disable log from primary to avoid this
> problem ?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--bcaec50163013d7ce504d6b6a45e
Il 27/02/2013 16:43, Keith Simmons ha scritto: > I've not been following this thread too closely, however I would not try to > 'insist' on anything. People in this forum are volunteers on whom you are > relying rather than paying IBMs maintenance charges. > You haven't included much of any previous posts to set the context so it is > difficult to offer much constructive advice (some log extracts would be > useful) > but there does not seem to be too much wrong here. > > Keith Hi all, thanks for your suggestion, but I do not have any IBM maintenance contract. What kind of information can I provide you to get help? Thanks for your help, Francesco.
OK, first thing, version 9.30.xC2 is circa late 2001 and was a buggy. OK,
you cannot get IBM support for v9.30 any longer, I know, it has been out of
support for more than 6 years now. Fine. However, there isn't anything we
can do for you except to suggest that you take a completely new archive
which will skip over any damaged logical log records and try the ontape -p
restore again using the new archive. That's the only advice I have for
you.
If that fails, then the only thing you can try would be to upgrade to a
supported version (which probably doesn't have the bug you appear to be
running into anyway) and set up replication from there. If your site is
small and activity is low, you could try using the free Innovator-C Edition
of Informix. It does support a single secondary server (paid releases
support more secondary servers now - 9.30 only supported a single HDR
secondary anyway) and it is limited to a single CPU VP and only 2GB of
memory, but you can purchase support for it (even though it is free) for
very little money. If your needs are more extensive than Innovator-C can
handle, you could try Express Edition or Growth Edition.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
On Wed, Feb 27, 2013 at 9:25 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 27/02/2013 16:17, Art Kagel ha scritto:
> > There's nothing to avoid, that's what the primary is supposed to do but
> > something is not right on the secondary, it is having trouble applying
> the
> > logical log record(s) sent to it by the primary. The communications may
> be
> > flaky, or the last log record is not complete or you've hit a bug. Are
> all
> > of your databases logged? Having unlogged databases in a replicated
> server
> > can cause some trouble occassionally.
> >
> > Beyond that, I'll repeat myself: Call IBM
> >
> I'm sorry to insist, bu I haven't a support from Ibm !
>
> This is the output of onstat -l on primary
> Informix Dynamic Server Version 9.30.UC2 -- On-Line (Prim) -- Up
> 01:21:25 -- 879944 Kbytes
>
> Physical Logging
> Buffer bufused bufsize numpages numwrits pages/io
>
> P-1 0 5000 4 1 4.00
>
> phybegin physize phypos phyused %used
>
> 100107 50000 2441 0 0.00
>
> Logical Logging
> Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
>
> L-2 0 5000 20 16 16 1.2 1.0
>
> Subsystem numrecs Log Space used
>
> OLDRSAM 20 1040
>
> address number flags uniqid begin size used %used
> 4ec809f0 1 U-B---- 190551 10c457 5000 1 0.02
> 4ec80a28 2 U-B---- 190552 10d7df 5000 1 0.02
> 4ec80a60 3 U-B---- 190553 10eb67 5000 1 0.02
> 4ec80a98 4 U-B---- 190554 10feef 5000 2 0.04
> 4ec80ad0 5 U---C-L 190555 111277 5000 5 0.10
> 4ec80b08 6 F------ 0 1125ff 5000 0 0.00
> 4ec80b40 7 U-B---- 190547 113987 5000 2889 57.78
> 4ec80b78 8 U-B---- 190548 114d0f 5000 45 0.90
> 4ec80bb0 9 U-B---- 190549 116097 5000 1 0.02
> 4ec80be8 10 U-B---- 190550 11741f 5000 1 0.02
> 10 active, 10 total
>
> >From secondary:
>
> Informix Dynamic Server Version 9.30.UC2 -- Fast Recovery (Sec) --
> Up 00:03:32 -- 2906344 Kbytes
> Blocked:CKPT
>
> Physical Logging
> Buffer bufused bufsize numpages numwrits pages/io
>
> P-2 0 5000 0 0 0.00
>
> phybegin physize phypos phyused %used
>
> 100107 50000 2441 0 0.00
>
> Logical Logging
> Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io
>
> L-1 0 5000 0 0 0 0.0 0.0
>
> Subsystem numrecs Log Space used
>
> address number flags uniqid begin size used %used
> 14c809f0 1 F------ 0 10c457 5000 0 0.00
> 14c80a28 2 F------ 0 10d7df 5000 0 0.00
> 14c80a60 3 F------ 0 10eb67 5000 0 0.00
> 14c80a98 4 F------ 0 10feef 5000 0 0.00
> 14c80ad0 5 U---C-L 190555 111277 5000 1 0.02
> 14c80b08 6 F------ 0 1125ff 5000 0 0.00
> 14c80b40 7 F------ 0 113987 5000 0 0.00
> 14c80b78 8 F------ 0 114d0f 5000 0 0.00
> 14c80bb0 9 F------ 0 116097 5000 0 0.00
> 14c80be8 10 F------ 0 11741f 5000 0 0.00
>
> Can I clear log from primary or disable log from primary to avoid this
> problem ?
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--e89a8fb20486e4d06a04d6b70ca5
Original post: Hi, I need help on an issue which occur during logical restore on Informix Dynamic Server Version 9.30.UC2 can someone help me? When I run a logical restore, I get an the error message such as the one reported at the end of email. How can I limit the number of virtual shared memory segment used during logical restore ? Dynamically allocated new virtual shared memory segment (size 10132KB) 15:00:37 Dynamically allocated new virtual shared memory segment (size 10132KB) 15:00:37 Dynamically allocated new virtual shared memory segment (size 10132KB) 15:00:37 Size of resident + virtual segments 165320KB + 2751156KB > 2910000KB 15:00:37 total allowed by configuration parameter SHMTOTAL 15:00:37 out of virtual shared memory 15:00:37 Assert Failed: ISAM error: An error has occurred during logical restore. 15:00:37 Informix Dynamic Server Version 9.30.UC2 15:00:37 Who: Session(18, root@server4, 0, 348602480) Thread(30, logrecover, 14c47c18, 1) File: rsarcutl.c Line: 127 15:00:37 Action: dologrecvr()/add_Qbuf 15:00:37 stack trace for pid 20705 written to /tmp/af.406e285 15:00:37 See Also: /tmp/af.406e285 15:00:37 ISAM error: An error has occurred during logical restore. Thanks in advance, Francesco. <stuff removed> Response: This looks to be a defect. It appears to have something to do with recovery and running out of memory, which your server appears to be having memory issues based on the MSGPATH output you've included (the "out of virtual shared memory messages" prior to the rest of the failure). You could try increasing SHMTOTAL to allow more memory, or possibly reduce the memory requirements for the secondary...like by decreasing the number of recovery threads (OFF_RECVRY_THREADS), or what do you have LOGBUFF set to? That's another parameter that impacts the amount of memory required for the restore and HDR to function. Obviously to change LOGBUFF you would have to also change it on the primary as that needs to match between the 2 servers. So you should be able to work around the issue if you can avoid the out of memory failures while HDR is starting up and trying to sync. Jacques Renaut IBM Informix Advanced Support
Il 27/02/2013 16:17, Art Kagel ha scritto:
> Re: Issue about logical restore
> Posted By: Art Kagel <Send E-Mail>
> Date: Wednesday, 27 February 2013, at 11:13 a.m.
> In Response To: Re: Issue about logical restore (Francesco Alfano)
> OK, first thing, version 9.30.xC2 is circa late 2001 and was a buggy. OK,
> you cannot get IBM support for v9.30 any longer, I know, it has been out of
> support for more than 6 years now. Fine. However, there isn't anything we
> can do for you except to suggest that you take a completely new archive
> which will skip over any damaged logical log records and try the ontape -p
> restore again using the new archive. That's the only advice I have for
> you.
> If that fails, then the only thing you can try would be to upgrade to a
> supported version (which probably doesn't have the bug you appear to be
> running into anyway) and set up replication from there. If your site is
> small and activity is low, you could try using the free Innovator-C Edition
> of Informix. It does support a single secondary server (paid releases
> support more secondary servers now - 9.30 only supported a single HDR
> secondary anyway) and it is limited to a single CPU VP and only 2GB of
> memory, but you can purchase support for it (even though it is free) for
> very little money. If your needs are more extensive than Innovator-C can
> handle, you could try Express Edition or Growth Edition.
>
> Art
> Art S. Kagel
>
Thanks for your response and your time,
I don't have any damaged logical log, Ids works correctly both on
primary and secondary.
The problem is only when primary starts a
< DR: Secondary server needs failure recovery >
then the secondary allocate to much "virtual shared memory" and the goes in
<
shmdt: errno = 22
15:12:34 out of virtual shared memory
15:12:34 Assert Failed: ISAM error: An error has occurred during
logical restore
>
Ahh missed that. Ok. You need to increase the maximum shared memory
allowed on the kernel and make sure that SHMTOTAL is zero.
Art
Il 27/02/2013 16:17, Art Kagel ha scritto:
> Re: Issue about logical restore
> Posted By: Art Kagel <Send E-Mail>
> Date: Wednesday, 27 February 2013, at 11:13 a.m.
> In Response To: Re: Issue about logical restore (Francesco Alfano)
> OK, first thing, version 9.30.xC2 is circa late 2001 and was a buggy. OK,
> you cannot get IBM support for v9.30 any longer, I know, it has been out
of
> support for more than 6 years now. Fine. However, there isn't anything we
> can do for you except to suggest that you take a completely new archive
> which will skip over any damaged logical log records and try the ontape -p
> restore again using the new archive. That's the only advice I have for
> you.
> If that fails, then the only thing you can try would be to upgrade to a
> supported version (which probably doesn't have the bug you appear to be
> running into anyway) and set up replication from there. If your site is
> small and activity is low, you could try using the free Innovator-C
Edition
> of Informix. It does support a single secondary server (paid releases
> support more secondary servers now - 9.30 only supported a single HDR
> secondary anyway) and it is limited to a single CPU VP and only 2GB of
> memory, but you can purchase support for it (even though it is free) for
> very little money. If your needs are more extensive than Innovator-C can
> handle, you could try Express Edition or Growth Edition.
>
> Art
> Art S. Kagel
>
Thanks for your response and your time,
I don't have any damaged logical log, Ids works correctly both on
primary and secondary.
The problem is only when primary starts a
< DR: Secondary server needs failure recovery >
then the secondary allocate to much "virtual shared memory" and the goes in
<
shmdt: errno = 22
15:12:34 out of virtual shared memory
15:12:34 Assert Failed: ISAM error: An error has occurred during
logical restore
>
*******************************************************************************
Forum Note: Use "Reply" to post a response in the discussion forum.
--f46d040838b33ca9fe04d6deabfd