Hi All,

Having recently installed p14025 to a server running II 10.0.0 (a64.lnx/132)NPTL.

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, sc0m.c:1384 ]: Mon Mar 21 19:00:17 2011 E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
mepages.c:1151 brk() failed with operating system error 12 (Cannot allocate memory)
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, scumsvc.c:295 ]: Mon Mar 21 19:00:17 2011 E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, scumsvc.c:295 ]: Mon Mar 21 19:00:17 2011 E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, dm0m.c:761 ]: Mon Mar 21 19:00:17 2011 E_DM9425_MEMORY_ALLOCATE Error allocating memory for DMF operation. Could not allocate requested memory. Memory request was for 4194304 bytes.
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, dm0m.c:762 ]: Mon Mar 21 19:00:17 2011 E_DM9429_EXPAND_POOL Error in expand_pool() adding to the virtual address space of the process.
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, scsdbfcn.c:865 ]: Mon Mar 21 19:00:17 2011 E_SC0121_DB_OPEN Error opening database. Name: reveal_internal_dev Owner: reveal Access Mode: 00000002 Flags 40000000
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, scsdbfcn.c:874 ]: Mon Mar 21 19:00:17 2011 E_SC010D_DB_LOCATION Database Location Name: $default Physical Specification: /dbdata1/II/ingres/data/default/reveal_internal_dev Flags: 00000003
DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200, scsinit.c:4338 ]: Mon Mar 21 19:00:17 2011 E_DM00A0_UNKNOWN_COLLATION Could not open a database because collation sequence not installed.

The database in question was not created with a specific collation sequence.. So I assume something about the Bad size expand managed to trigger the E_DM00A0 message.

I've checked the DBMS log and there is nothing in there that would shed anylight on this problem.

Anyone seen this before?

Martin Bowes

On Mar 22, 2011, at 7:18 AM, Martin Bowes wrote:

Was it created with -i or -n? The database must have some sort of collation
defined, or it wouldn't have been asking for memory for it. Is the installation
UTF8?

The text of the DM00A0 message is a bit misleading; it probably should read
simply "could not open collation file" and it would be nice if it included the collation
name that it's trying to open.

In any case, once the DBMS server hits SC0107_BAD_SIZE_EXPAND, it's
pretty much all over. None of the facilities have any real notion of
garbage collection to release memory. A few of them can reclaim individual
objects to make room for new ones, but there's no mass reclaim, and there's
no ability for one facility to release memory back to SCF for use by
a different facility.

Karl

Hi Karl,

Yes it was defined with NFC but is using the standard unicode collation.

I trapped some vmstat stuff at the time the error occurred. But its not particularly useful. Would it be worthwhile tripping inglogs out of II_EXCEPT?

Marty

-----Original Message-----
From: Karl Schendel [mailto:schendel (AT) kbcomputer (DOT) com]
Sent: 22 March 2011 11:44
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] When does a bad size expand lead to E_DM00A0?


On Mar 22, 2011, at 7:18 AM, Martin Bowes wrote:

Was it created with -i or -n? The database must have some sort of collation
defined, or it wouldn't have been asking for memory for it. Is the installation
UTF8?

The text of the DM00A0 message is a bit misleading; it probably should read
simply "could not open collation file" and it would be nice if it included the collation
name that it's trying to open.

In any case, once the DBMS server hits SC0107_BAD_SIZE_EXPAND, it's
pretty much all over. None of the facilities have any real notion of
garbage collection to release memory. A few of them can reclaim individual
objects to make room for new ones, but there's no mass reclaim, and there's
no ability for one facility to release memory back to SCF for use by
a different facility.

Karl



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

On Mar 22, 2011, at 8:28 AM, Martin Bowes wrote:

Ah. It still has to read the udefault collation file.

This came up in some development discussions not too long ago. The original
theory behind -i/-n on createdb was to save memory, since unicode would
be relatively rare (back then). Now, it's much more common, and ideally
the DBMS server would simply read in udefault once and that would be the
end of it. No more need for funky createdb options either, except possibly
to indicate the normalization mode. One more thing for the todo list, I guess.

Karl

It might be; the other thing to do would be to make sure you have a DBMS log
defined (II_DBMS_LOG). DMF and ULM pool expands are logged in the DBMS log,
and you can relatively easily see which pools are eating up all of the memory.

Karl

Collation could do with further thought:
* UCS_BASIC requires no collation tables so in theory you could use UTF8
with it and not really need -i or -n on the DB. This being the only
supported collation with Vectorwise table means that the Unicode tables
are possibly just a memory overhead for an IVW installation.
* The ADUL based collation could be made to work with UTF8. This is not
so stupid as it might seem as the latter form of collation is more
easily user customised and better for small variation collations
compared to the big bang of Unicode collation. This might also be a
better model for implementation in VW than Unicode table solution which
by its sheer size will not be cache friendly.
* Part of the collation table data involved is not related to collation
either - more akin to transliteration and as such is fixed - much better
for such data to be loaded in readonly memory and not lumped in with the
collation overheads.

Ian

-----Original Message-----
From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of Karl
Schendel
Sent: 22 March 2011 12:41
To: Ingres and related product discussion forum
Subject: Re: [Info-Ingres] When does a bad size expand lead to E_DM00A0?


On Mar 22, 2011, at 8:28 AM, Martin Bowes wrote:


Ah. It still has to read the udefault collation file.

This came up in some development discussions not too long ago. The
original
theory behind -i/-n on createdb was to save memory, since unicode would
be relatively rare (back then). Now, it's much more common, and ideally
the DBMS server would simply read in udefault once and that would be the
end of it. No more need for funky createdb options either, except
possibly
to indicate the normalization mode. One more thing for the todo list, I
guess.

Karl

II_EXCEPT?
It might be; the other thing to do would be to make sure you have a
DBMS log
defined (II_DBMS_LOG). DMF and ULM pool expands are logged in the DBMS
log,
and you can relatively easily see which pools are eating up all of the
memory.

Karl

E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.
E_DM9425_MEMORY_ALLOCATE Error allocating memory for DMF operation.
Could not allocate requested memory. Memory request was for 4194304
bytes.
E_DM9429_EXPAND_POOL Error in expand_pool() adding to the virtual
address space of the process.
E_SC0121_DB_OPEN Error opening database. Name: reveal_internal_dev
Owner: reveal Access Mode: 00000002 Flags 40000000
E_SC010D_DB_LOCATION Database Location Name: $default Physical
Specification: /dbdata1/II/ingres/data/default/reveal_internal_dev
Flags: 00000003
E_DM00A0_UNKNOWN_COLLATION Could not open a database because
collation sequence not installed.
trigger the E_DM00A0 message.



_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

On 22 bře, 12:18, Martin Bowes <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote:
Do you have enough shared memory? I've seen it when the cache is big
(or a lot of locks configured) and shmmax is small. Check the file /
etc/sysctl.conf.

Anyone seen this before?

Yes. We currently have a client issue where the behaviour was reported.

The behaviour could not be replicated when applying this patch to a
freshly installed II 10.0.0 (a64.lnx/132).

(Neither at the client site, nor in-house.)



Then we noticed that config.dat revealed that the installation started
out as II 10.0.0 (a64.lnx/125). (A GPL version)





If you have been testing using the GPL version, do not attempt to
upgrade the installation to the Enterprise Supported version.

Unload your databases and reload in a freshly installed II 10.0.0
(a64.lnx/132).



Cheers,

Michael



________________________________

From: info-ingres-bounces (AT) kettleriver...ting (DOT) com
[mailto:info-ingres-bounces (AT) kettleriverconsulting (DOT) com] On Behalf Of
Martin Bowes
Sent: 22 March 2011 11:19
To: Ingres and related product discussion forum
Subject: [Info-Ingres] When does a bad size expand lead to E_DM00A0?



Hi All,



Having recently installed p14025 to a server running II 10.0.0
(a64.lnx/132)NPTL.



DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
sc0m.c:1384 ]: Mon Mar 21 19:00:17 2011
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

mepages.c:1151 brk() failed with operating system error 12 (Cannot
allocate memory)

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
scumsvc.c:295 ]: Mon Mar 21 19:00:17 2011
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
scumsvc.c:295 ]: Mon Mar 21 19:00:17 2011
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
dm0m.c:761 ]: Mon Mar 21 19:00:17 2011
E_DM9425_MEMORY_ALLOCATE Error allocating memory for DMF operation.
Could not allocate requested memory. Memory request was for 4194304
bytes.

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
dm0m.c:762 ]: Mon Mar 21 19:00:17 2011 E_DM9429_EXPAND_POOL
Error in expand_pool() adding to the virtual address space of the
process.

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
scsdbfcn.c:865 ]: Mon Mar 21 19:00:17 2011 E_SC0121_DB_OPEN
Error opening database. Name: reveal_internal_dev Owner: reveal Access
Mode: 00000002 Flags 40000000

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
scsdbfcn.c:874 ]: Mon Mar 21 19:00:17 2011 E_SC010D_DB_LOCATION
Database Location Name: $default Physical Specification:
/dbdata1/II/ingres/data/default/reveal_internal_dev Flags: 00000003

DECIUS_CTSU_OX_AC_::[51605 , 22965 , 000000003ae36200,
scsinit.c:4338 ]: Mon Mar 21 19:00:17 2011
E_DM00A0_UNKNOWN_COLLATION Could not open a database because
collation sequence not installed.



The database in question was not created with a specific collation
sequence. So I assume something about the Bad size expand managed to
trigger the E_DM00A0 message.



I've checked the DBMS log and there is nothing in there that would shed
any light on this problem.



Anyone seen this before?



Martin Bowes

Hi Vaclav,

Should have enough..68G is the allowance.

Marty

-----Original Message-----
From: Vaclav Dohnal [mailto:vdohnal (AT) uniscomp (DOT) cz]
Sent: 22 March 2011 14:17
To: info-ingres (AT) kettleriverconsulting (DOT) com
Subject: Re: [Info-Ingres] When does a bad size expand lead to E_DM00A0?

On 22 bře, 12:18, Martin Bowes <martin.bo... (AT) ctsu (DOT) ox.ac.uk> wrote:
Do you have enough shared memory? I've seen it when the cache is big
(or a lot of locks configured) and shmmax is small. Check the file /
etc/sysctl.conf.
_______________________________________________
Info-Ingres mailing list
Info-Ingres (AT) kettleriverconsulting (DOT) com
http://ext-cando.kettleriverconsulti...fo/info-ingres

The only trouble with that theory is that I use set trace ouput '...' a lot in regular monitoring. So even though I have the II_DBMS_LOG defined, its next to useless.

I think I'll re-look at all that stuff where I save dm420 output (etc) and see if its really worth the effort and if I'd be better off usin ima to get that data.

Marty

If you want DM420 via IMA have a look at KB doc 416740 - it might save
you a little time.