[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::sql_services

Title:SQL/Services Forum
Notice:kits(3) ft info(7) QAR access (8) SPR access (10)
Moderator:SQLSRV::MAVRIS
Created:Thu Oct 13 1988
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2214
Total number of notes:8586

2139.0. "How to use SQLSRV$MEMORY_DEBUG_FLAGS with 7.0?" by 4107::PLINDGRE (A customer called...) Tue Feb 11 1997 10:31

    	Hi all,
    
    is it possible to use SQLSRV$MEMORY_DEBUG_FLAGS for debuging memory
    problems under SQL/Services 7.0?
    
    Where Should it be defined and where does the output go?
    
    A customer is seeing his pgflquota being "eaten up" until it is nothing
    left for his GENERIC service. He has raised PGFLQUO for the
    SQLSRV$DEFLT account to 300.000 but the execution process takes it all.
    
    He is running Rdb 7.0 on Alpha OpenVMS 7.0.
    
    
    Reference note  2124.3.
    
    Regards
    
    Peter  
T.RTitleUserPersonal
Name
DateLines
2139.1Some guidelinesSQLSRV::OXBURYOracle Corporation, Rdb Desktop Group|DTN 381-2704Tue Feb 11 1997 17:1535
Hi Peter,

I've just entered note 2141 which describes how to use SQL/Services memory
debugging. We did some fairly extensive testing of both SQL/Services V7.0 and
Rdb V7.0 to find and fix some fairly bigs leaks in the field test kits, but
these were all fixed before the final kits were shipped. Unfortunately, it
seems you've uncovered something we didn't find in our tests. 

I'd start out with the simple test first - turn on the statistics and dump-on-
no-memory flags ($ DEFINE SQLSRV$MEMORY_DEBUG_FLAGS 5 in a process init. file)
to see if SQL/Services is eating memory for each association to which an
executor is assigned. If you see the current count increase between each
association, then its SQL/Services problem. If not, its SQL's, Rdb dispatch's
or the Rdb exec's problem. 

Things get tricky if the problem happens for a single association, because the
code only logs stats at the end of an association. If SQL/Services detects a
memory allocation failure, it'll dump a small chunk of all allocated memory to
the executor log file before it terminates. Unfortunately, this doesn't work if
another component detects the problem. 

If it turns out that SQL/Services is the problem, then we get to fix it
(assuming it isn't the client that's at fault, eg, by preparing and not
releasing loads of statements). If you determine that SQL/Services isn't the
problem, then it has to be SQL, Rdb dispatch or the Rdb exec. One thing you
could try here is to use remote Rdb to the same system. This will force the Rdb
exec into a separate server process, which will then show whether its SQL or
Rdb client dispatch, or whether its Rdb server dispatch or the Rdb exec. Either
way, if its not SQL/Services, its going to be really hard to figure it out (I
spent a long time with the VAX/VMS heap analyzer and SDA to track down the
leaks in 7.0).

Hope this and note 2141 help get you going on this.

Si
2139.2Keword LOGIN and PROCESS INITIALIZATION file141.147.17.8::PLINDGREA customer called...Thu Feb 13 1997 05:3513
    Thanks Si, 
    
    I'm working on the problem with help of our suggestions. For everyone
    who has problems (as I had) defining logicals in an PROCESS
    INITIALIZATION file using the keyword LOGIN in the SQL/Services
    service configuration should read note 2115.
    
    
    Regards
    
    Peter