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

Conference orarep::nomahs::rdb_60

Title:	Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:	RDB_60 is archived, please use RDB_70..
Moderator:	NOVA::SMITHISON

Created:	Fri Mar 18 1994
Last Modified:	Fri May 30 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	5118
Total number of notes:	28246

5011.0. "Performance and TRACE" by UKVMS3::HRUSSELL (Hazel Russell, UK Education) Fri Feb 07 1997 11:37

    In the presentation on the Web about Advanced SQL Programming in Oracle
    Rdb, there is a statement about TRACE
    
    "Code is inactive until enabled using RDMS$DEBUG_FLAGS or the SET FLAGS
    'TRACE' statement"
    
    If you put many TRACE statements in for debugging purposes and leave
    them in the code in a production envrionment, will it affect
    performance?  Is there an overhead in leaving these in?
    
    Can you turn on and off GET DIAGNOSTICS to complement the TRACE? 
    Customer has suggested that it would be nice if you could embed GET
    DIAGNOSTICS into the TRACE so that GET DIAGNOSTICS is only executed
    when TRACE is on.  Is this possible at present?
       
    Thanks

T.R Title User Personal
Name Date Lines

5011.1 NOVA::SMITHI Don't understate or underestimate Rdb! Fri Feb 07 1997 11:48 35

T.R	Title	User	Personal Name	Date	Lines
5011.1		NOVA::SMITHI	Don't understate or underestimate Rdb!	`Fri Feb 07 1997 11:48`	35
	Ah my presentation :-) ~ "Code is inactive until enabled using RDMS$DEBUG_FLAGS or the SET FLAGS ~ 'TRACE' statement" INACTIVE means none or zero activity. The TRACE statement is seen as a comment. If the debug flags are not enabled when we compile the query we literal skip over it as though it didn't exist. ~ If you put many TRACE statements in for debugging purposes and leave ~ them in the code in a production envrionment, will it affect ~ performance? Is there an overhead in leaving these in? There is no execution time overhead. I went ot great lengths to ensure that. The TRACE statement still exists so they still take space in the procedure, but I think you knew that. ~ Can you turn on and off GET DIAGNOSTICS to complement the TRACE? Well no. They will still be executed. However, the over head is extremely small. The GET DIAGNOSTICS code just references some existing registers for information. ~ Customer has suggested that it would be nice if you could embed GET ~ DIAGNOSTICS into the TRACE so that GET DIAGNOSTICS is only executed ~ when TRACE is on. Is this possible at present? No this is not really possible (the actual GET DIAGNOSTICS support code in the engine would allow GET DIAGNOSTICS builtins but we have none right now). In Rdb7 you could place the GET DIAGNOSTICS calls in a stored function. Then call the stored function from the TRACE statement. If the TRACE statement is not processed then the stored function will not be activated. Ian

Ah my presentation :-)

~    "Code is inactive until enabled using RDMS$DEBUG_FLAGS or the SET FLAGS
~    'TRACE' statement"

INACTIVE means none or zero activity.  The TRACE statement is seen as a
comment.  If the debug flags are not enabled when we compile the query we
literal skip over it as though it didn't exist.
    
~    If you put many TRACE statements in for debugging purposes and leave
~    them in the code in a production envrionment, will it affect
~    performance?  Is there an overhead in leaving these in?
    
There is no execution time overhead.  I went ot great lengths to ensure that.
The TRACE statement still exists so they still take space in the procedure,
but I think you knew that.

~    Can you turn on and off GET DIAGNOSTICS to complement the TRACE? 

Well no.  They will still be executed.  However, the over head is extremely
small.  The GET DIAGNOSTICS code just references some existing registers for
information.

~    Customer has suggested that it would be nice if you could embed GET
~    DIAGNOSTICS into the TRACE so that GET DIAGNOSTICS is only executed
~    when TRACE is on.  Is this possible at present?

No this is not really possible (the actual GET DIAGNOSTICS support code in the
engine would allow GET DIAGNOSTICS builtins but we have none right now).

In Rdb7 you could place the GET DIAGNOSTICS calls in a stored function.  Then
call the stored function from the TRACE statement.  If the TRACE statement is
not processed then the stored function will not be activated.

Ian