RE: [Info-ingres] OPF_memory logging.
- From: "Peter Gale" <PGale@xxxxxxxxxxxxxxx>
- Date: Fri, 16 Jun 2006 13:00:02 +0100
Whoaa!!
Mr Mason you surprise me.
' I'd no more expect to see it in the errlog.log than I would
a duplicate key on insert or constraint violation message.'
Running out of memory can hardly be considered a front-end issue. If the
business/application/user needs to run a piece of SQL that blows away OPF
memory then I would respectfully suggest that's at least in part a
configuration but possibly also a bug. I could possibly argue that in this
day and age of servers with vast amounts of memory any query that is within
the specified limits of the DBMS in terms of tables, joins, restrictions,
row width etc, etc should just run regardless. I accept there have to be
limits on the amount of memory allocated in certain areas to prevent runaway
memory allocation but those limits should be in proportion to the amount of
memory available on the host not on some arbitrary configuration limit.
Thus in the current way of doing things (ie configured limits) the DB/Sys
Admin needs to know this has happened so they can tweak the config
accordingly. Therefore this kind of problem should be reported at the server
end.
The Prosecution rests.
--
Peter Gale (PGale@xxxxxxxxxxxxxxx)
UK: Comprehensive Solutions International (www.comp-soln.co.uk)
US: Comprehensive Solutions (www.comp-soln.com)
T: +44 (0)1398 341777 M: +44 (0)7831 513181
Ingres Corp. Partner
www.ingres.com/partners/Partners_Quotes.html
-----Original Message-----
From: info-ingres-admin@xxxxxxxxxxxxxxx
[mailto:info-ingres-admin@xxxxxxxxxxxxxxx] On Behalf Of Paul Mason
Sent: 16 June 2006 11:30
To: info-ingres@xxxxxxxxxxxxxxx
Subject: Re: [Info-ingres] OPF_memory logging.
On 6/16/06, martin.bowes@xxxxxxxxxxxxx <martin.bowes@xxxxxxxxxxxxx> wrote:
Hi Everyone,
I have an II 2.6/0305 (int.lnx/00) patch9892 installation which is
occassionaly producing errors regarding opf_memory but only at the
user end and these are not being printed in the Ingres Errlog.
I would have thought they should be. Any commments.
User applications see:
optimizer ran out of memory before generating execution plan
I've checked in the errlog and the only OPF errors I have see - and not
at the times the users reports problems - are:
E_OP04AA_HISTOMOD Histogram modification failed. Original
histogram will be used.
Well as far as the server is concerned a session hitting the limit of
how much OPF memory it can use is not an error, it's a normal
condition to be handled, business as usual. So the message is rightly
front-end. I'd no more expect to see it in the errlog.log than I would
a duplicate key on insert or constraint violation message.
Now if the server tried to allocate more OPF and failed, or there was
an error reading/writing OPF memory then I'd expect to see that in the
errlog.log.
Now as to whether the errlog.log should be considered the _server(s)_
error log or the _installation_ error log - i.e. should all errors be
logged there, including front-end - is open to debate, but as things
stand it's really the former. Since it's friday I'll now hand it over
to the group to a) tell me why that's the wrong design and b) how
there are all sorts of exceptions now anyway. ;)
--
Paul Mason
_______________________________________________
Info-ingres mailing list
Info-ingres@xxxxxxxxxxxxxxx
http://mailman.cariboulake.com/mailman/listinfo.py/info-ingres
.
- Prev by Date: Re: [Info-ingres] OPF_memory logging.
- Next by Date: Re: [Info-ingres] OPF_memory logging.
- Previous by thread: Re: [Info-ingres] OPF_memory logging.
- Next by thread: Re: [Info-ingres] OPF_memory logging.
- Index(es):
Relevant Pages
|
|
