db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: regarding derby.log being overwritten on startup. [was Re: [jira] Commented: (DERBY-515) Network Server should log server start and shutdown time to derby.log]
Date Fri, 19 Aug 2005 22:10:45 GMT
Actually, when  derby.language.logStatementText=true is set,  messages  
that are currently printed to derby.log  uses a  ":" delimiter format.

e.g.
..... Begin compiling prepared statement : SELECT * from tbl1 : end 
compiling prepared statement
etc...

For really huge derby.log traces,  I usually use this delimiter option 
and pull it up in Excel to view the queries etc.

Sunitha.
Danesh wrote:

>I agree with going the delimited format route. Having the database
>write out XML would probably impact preformance quite a bit. I also
>wonder what would happen if the database were to die (power failure or
>the like) and the XML file ended up invalid due to it missing those
>crucial few closing tags. To simplify things and satisfy both parties
>someone could write a log conversion tool i.e. DEL -> XML.
>
>~Danesh
>
>On 8/19/05, David Van Couvering <David.Vancouvering@sun.com> wrote:
>  
>
>>Please, God, no :).  Machines like reading XML but people (at least
>>certain people) find it a bit horrific.
>>
>>What I have seen done in the past is using a simple delimiter format, e.g.
>>
>>|Fri Aug 19 14:06:31 PST
>>2005|org.apache.derby.engine.impl.jdbc.EmbedConnection|Thread
>>275|Invalid user, please try again| | |
>>
>>then you can write tools that slurp this right into Excel, load into a
>>database, etc.  We did this with an app I worked on at Sybase and it was
>>quite successful.
>>
>>David
>>
>>Rick Hillegas wrote:
>>
>>    
>>
>>>At the risk of overloading this topic: While we're talking about
>>>improvements to our error logging, I'd like to see us emit more
>>>structured logs. This is one of the things that xml is actually good
>>>for. It would be pretty easy to turn our log records into xml entries.
>>>This would make it easy to write or use off-the-shelf tools for
>>>viewing the logs and for filtering signal out of the noise.
>>>
>>>Cheers,
>>>-Rick
>>>
>>>David Van Couvering wrote:
>>>
>>>      
>>>
>>>>Well, the most common solution is log rotation.  On restart, you
>>>>rename the old log to derby.log.1 and then derby.log.2 and so on.
>>>>After <n> log files, you start over again at derby.log.1.
>>>>This is also useful for long-running systems so you don't run out of
>>>>disk space because of your error logs.  When the error log gets a
>>>>configurable X MBs, the system copies the log to derby.log.1,
>>>>derby.log.2, etc.,  and starts a fresh log.  After N log files it
>>>>starts back at 1 and overwrites the old log file.  Similar but
>>>>different from above, but both are great to reduce administrative
>>>>overhead for the user.
>>>>
>>>>David
>>>>
>>>>Sunitha Kambhampati wrote:
>>>>
>>>>        
>>>>
>>>>>Øystein Grøvlen wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>>>>>>"KM" == Kathey Marsden <kmarsdenderby@sbcglobal.net>
writes:
>>>>>>>>>>>
>>>>>>>>>>>                      
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                    
>>>>>>>>>>
>>>>>>   KM> Øystein Grøvlen (JIRA) wrote:
>>>>>>   >> [    >> This would be even more helpful if the derby.log
file
>>>>>>was not overwritten on the next startup.  (Probably a separate issue).
>>>>>>   >>    >>    >>    KM> The derby.infolog.append
property is
>>>>>>helpful in this regard.
>>>>>>
>>>>>>   KM>
>>>>>>http://db.apache.org/derby/docs/10.1/tuning/rtunproper13217.html
>>>>>>
>>>>>>Thanks, Kathey, that is really what I need.
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>One concern I have is that by default, the derby.log gets
>>>>>overwritten on subsequent boot. From my experience with customers,
>>>>>whenever there is an issue, I always end up telling them to add this
>>>>>property almost every time to see the debug logs. It is very common
>>>>>to see users reboot the system if they hit an error and in this
>>>>>case, it is probable that important relevant information in the
>>>>>derby.log is lost because it gets overwritten ( ex - recovery issues
>>>>>, deadlock etc ).
>>>>>
>>>>>Maybe we could do something smart for derby.log , a balance between
>>>>>keeping history across boots and disk space taken by the derby.logs.
>>>>>
>>>>>Any comments ?
>>>>>
>>>>>Sunitha.
>>>>>          
>>>>>
>>>>
>>>>        
>>>>
>>
>>    
>>


Mime
View raw message