Subject | RE: [firebird-support] Recording Update statements and User that executed |
---|---|
Author | Marius Labuschagne |
Post date | 2013-02-26T22:23:03Z |
[Marius Labuschagne] "Hi,
Is it possible to record any UPDATE statement that is executed against a
database, from the database level?
Something very strange happened to one of my Clients databases, where one
field in a table was set to another field in the same table (both double
precision fields). I suspect that this was executed by an end user using
one of the database tools like IBExpert or Database Workbench, but there is
no way that I can prove it.
After analysis of the data and my application, I found that the particular
UPDATE that was executed is not present at all anywhere in the source code
of the application.
Regards
Marius J. Labuschagne "
Hi,
I think I could possibly use the trace manager to accomplish what I want to
track.
The section below is my database section in my fbtrace.conf file, but the
logfile is not created. Could anyone please advise me of where I am going
wrong?
I am running Firebird 2.5.2 in superclassic mode on a Windows 7 64 bit
machine.
I start the trace manager with the following command, and can see the traces
in the cmd window: C:\Program Files\Firebird\Firebird_2_5\bin>fbtracemgr -se
service_mgr -U sysdba -P masterkey -start -name my_trace -CONFIG
fbtrace.conf
<database>
# Do we trace database events or not
enabled true
# Operations log file name. For use by system audit trace only
log_filename "C:\\Program
Files\\Firebird\\Firebird_2_5\\trace_log.log"
# Maximum size of log file (megabytes). Used by system audit trace
for
# log's rotation : when current log file reached this limit it is
renamed
# using current date and time and new log file is created. Value of
zero
# means that the log file size is unlimited and rotation will never
happen.
max_log_size 0
# SQL query filters.
#
# Only SQL statements falling under given regular expression are
reported
# in the log.
include_filter %(UPDATE|DELETE)%
# SQL statements falling under given regular expression are NOT
reported
# in the log.
#exclude_filter
# Put attach/detach log records
log_connections true
# Trace only given connection id. If zero - trace all connections
connection_id 0
# Put transaction start/end records
log_transactions true
# Put sql statement prepare records
log_statement_prepare true
# Put sql statement free records
log_statement_free true
# Put sql statement execution start records
log_statement_start true
# Put sql statement execution finish\fetch to eof records
log_statement_finish true
# Put record when stored procedure is start execution
log_procedure_start true
# Put record when stored procedure is finish execution
log_procedure_finish false
# Put trigger execute records
log_trigger_start false
# Put trigger execute records
log_trigger_finish false
# Put context variable change records (RDB$SET_CONTEXT)
#log_context false
# Print access path (plan) with sql statement
print_plan false
# Print detailed performance info when applicable
print_perf false
# Put blr requests compile/execute records
log_blr_requests false
# Print blr requests or not
print_blr false
# Put dyn requests execute records
log_dyn_requests false
# Print dyn requests or not
print_dyn false
# Put xxx_finish record only if its timing exceeds this number of
milliseconds
time_threshold 0
# Maximum length of SQL string logged
# Beware when adjusting max_xxx parameters! Maximum length of log
record
# for one event should never exceed 64K.
max_sql_length 300
# Maximum length of blr request logged
max_blr_length 500
# Maximum length of dyn request logged
max_dyn_length 500
# Maximum length of individual string argument we log
max_arg_length 80
# Maximum number of query arguments to put in log
max_arg_count 30
</database>
Regards
Marius
Is it possible to record any UPDATE statement that is executed against a
database, from the database level?
Something very strange happened to one of my Clients databases, where one
field in a table was set to another field in the same table (both double
precision fields). I suspect that this was executed by an end user using
one of the database tools like IBExpert or Database Workbench, but there is
no way that I can prove it.
After analysis of the data and my application, I found that the particular
UPDATE that was executed is not present at all anywhere in the source code
of the application.
Regards
Marius J. Labuschagne "
Hi,
I think I could possibly use the trace manager to accomplish what I want to
track.
The section below is my database section in my fbtrace.conf file, but the
logfile is not created. Could anyone please advise me of where I am going
wrong?
I am running Firebird 2.5.2 in superclassic mode on a Windows 7 64 bit
machine.
I start the trace manager with the following command, and can see the traces
in the cmd window: C:\Program Files\Firebird\Firebird_2_5\bin>fbtracemgr -se
service_mgr -U sysdba -P masterkey -start -name my_trace -CONFIG
fbtrace.conf
<database>
# Do we trace database events or not
enabled true
# Operations log file name. For use by system audit trace only
log_filename "C:\\Program
Files\\Firebird\\Firebird_2_5\\trace_log.log"
# Maximum size of log file (megabytes). Used by system audit trace
for
# log's rotation : when current log file reached this limit it is
renamed
# using current date and time and new log file is created. Value of
zero
# means that the log file size is unlimited and rotation will never
happen.
max_log_size 0
# SQL query filters.
#
# Only SQL statements falling under given regular expression are
reported
# in the log.
include_filter %(UPDATE|DELETE)%
# SQL statements falling under given regular expression are NOT
reported
# in the log.
#exclude_filter
# Put attach/detach log records
log_connections true
# Trace only given connection id. If zero - trace all connections
connection_id 0
# Put transaction start/end records
log_transactions true
# Put sql statement prepare records
log_statement_prepare true
# Put sql statement free records
log_statement_free true
# Put sql statement execution start records
log_statement_start true
# Put sql statement execution finish\fetch to eof records
log_statement_finish true
# Put record when stored procedure is start execution
log_procedure_start true
# Put record when stored procedure is finish execution
log_procedure_finish false
# Put trigger execute records
log_trigger_start false
# Put trigger execute records
log_trigger_finish false
# Put context variable change records (RDB$SET_CONTEXT)
#log_context false
# Print access path (plan) with sql statement
print_plan false
# Print detailed performance info when applicable
print_perf false
# Put blr requests compile/execute records
log_blr_requests false
# Print blr requests or not
print_blr false
# Put dyn requests execute records
log_dyn_requests false
# Print dyn requests or not
print_dyn false
# Put xxx_finish record only if its timing exceeds this number of
milliseconds
time_threshold 0
# Maximum length of SQL string logged
# Beware when adjusting max_xxx parameters! Maximum length of log
record
# for one event should never exceed 64K.
max_sql_length 300
# Maximum length of blr request logged
max_blr_length 500
# Maximum length of dyn request logged
max_dyn_length 500
# Maximum length of individual string argument we log
max_arg_length 80
# Maximum number of query arguments to put in log
max_arg_count 30
</database>
Regards
Marius