> Trace config : > > <database orbis-aton> > enabled true > print_perf true > log_sweep true > exclude_filter %RDB$% > time_threshold 0 > </database> > <services> > enabled true > log_services true > include_filter "Repair Database" > </services>
The database filter expects a regular expression and orbis-aton can't be parsed as a regular expression upon trace session start. Either escape the minus symbol resulting in: orbis\-aton or use % as a wildcard, e.g.: %orbis% This should now give you appropriate sweep trace events for the database trace configured in the <database> section. > Cron calls a simple bash script with the following command for each of > the databases : > > /opt/firebird/bin/gfix -user sysdba -password masterkey -sweep orbis-aton I see now that services tracing via the <services> section won't result in any trace data when executing the sweep through gfix, because this doesn't go through the services manager. And the new command-line tool fbsvcmgr doesn't seem to support the switch for sweeping. -- With regards, Thomas Steinmaurer http://www.upscene.com/ Professional Tools and Services for Firebird FB TraceManager, IB LogManager, Database Health Check, Tuning etc. > > > 2014-10-29 20:39 GMT+02:00 Thomas Steinmaurer [email protected] > <mailto:[email protected]> [firebird-support] > <[email protected] > <mailto:[email protected]>>: > > __ > > > Well, I`ve done two things since the last post > > > > 1 I set the sweep interval to 100000 (I assume I`m far from reaching > > that on a normal day) > > No change - Yesterday, another unexpected sweep at 5:08:03 pm > > > > 2 I started a trace session with the suggested config (changing > only DB > > alias, as instructed - I don`t really have much experience with the > > trace API) > > Today a sweep happened at 5:08:56 (about 28000 transactions after the > > morning manual sweep). It`s suspiciously close as a time frame, but > > looking back at the last month or so - sweeps are distributed in the > > 5-10pm range, so I guess it could be a coincidence. > > > > Trace log ti this moment is as follows : > > Trace session ID 2 started > > 2014-10-28T18:06:59.8670 (9756:0x7f5e704849e0) TRACE_INIT > > SESSION_2 > > > > > > 2014-10-28T18:07:57.6530 (9768:0x7f7d2e4399e0) TRACE_INIT > > SESSION_2 > > > > > > 2014-10-28T18:07:57.6530 (9768:0x7f7d2e4399e0) ATTACH_SERVICE > > service_mgr, (Service 0x7f7d2e4578d0, firebird, internal) > > > > 2014-10-28T18:07:57.6530 (9768:0x7f7d2e4399e0) DETACH_SERVICE > > service_mgr, (Service 0x7f7d2e4578d0, firebird, internal) > > > > 2014-10-28T18:07:57.6530 (9768:0x7f7d2e4399e0) TRACE_FINI > > SESSION_2 > > > > > > 2014-10-28T18:08:16.7590 (9779:0x7fdb860fd9e0) TRACE_INIT > > SESSION_2 > > > > > > 2014-10-28T18:08:16.7590 (9779:0x7fdb860fd9e0) ATTACH_SERVICE > > service_mgr, (Service 0x7fdb8611b8d0, firebird, internal) > > > > 2014-10-28T18:08:16.7590 (9779:0x7fdb860fd9e0) DETACH_SERVICE > > service_mgr, (Service 0x7fdb8611b8d0, firebird, internal) > > > > 2014-10-28T18:08:16.7590 (9779:0x7fdb860fd9e0) TRACE_FINI > > SESSION_2 > > I assume those entries are from when I was poking around in the > > beginning. The trace session is still active but log says nothing > about > > sweeping. Wasn`t it supposed to show at least the sweep by gfix > (the one > > running from cron)? I`ll try fine tune it a bit on the weekend > when most > > users are gone and won`t notice. If anyone has any suggestions I > could > > test to help in the mean time - they`d be appreciated. > > Can you show us the changed trace config and the exact gfix call in > your > cron job? > > -- > With regards, > Thomas Steinmaurer > http://www.upscene.com/ > > Professional Tools and Services for Firebird > FB TraceManager, IB LogManager, Database Health Check, Tuning etc. > > > > > 2014-10-27 22:41 GMT+02:00 Thomas [email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > [firebird-support] > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>: > > > > __ > > > > > I`m not sure if running a 24/7 trace is a good idea (database > is under > > > relatively heavy load). Anything else I could do to help? > > > > It might be ok with a proper include filter at service level from a > > Trace API POV. > > > > The following trace configuration should be fully dedicated to > sweeping > > only: > > > > <database yourdatabasealias> > > enabled true > > print_perf true > > log_sweep true > > exclude_filter %RDB$% > > time_threshold 0 > > </database> > > <services> > > enabled true > > log_services true > > include_filter "Repair Database" > > </services> > > > > -- > > With regards, > > Thomas Steinmaurer > > http://www.upscene.com/ > > > > Professional Tools and Services for Firebird > > FB TraceManager, IB LogManager, Database Health Check, Tuning etc. > > > > > btw I am noticing that the unexpected sweep is about 27000-30000 > > > transactions after the scheduled one. I could send a log if > that helps > > > in any way. I set the interval to 100000 and in a day or two > I`ll know > > > if it still runs by its own. > > > > > > 2014-10-27 21:46 GMT+02:00 Thomas > [email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > > [firebird-support] > > > <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>> > > > <mailto:[email protected] > <mailto:[email protected]> > > > <mailto:[email protected] > <mailto:[email protected]>>>>: > > > > > > __ > > > > > > > > > > > I did some reconfiguration on a database yesterday, so I`m > > monitoring > > > > the logs for any issues and I noticed something strange : > > > > > > > > Mon Oct 27 16:54:25 2014 > > > > Sweep is started by SYSDBA > > > > Database "orbis-aton" > > > > OIT 21080, OAT 21081, OST 20456, Next 44177 > > > > > > > > (yes, I know it`s a bad idea but all database connections are by > > > SYSDBA) > > > > > > > > I don`t remember running a sweep (logs say I wasn`t even logged > > in at > > > > the time) and nobody else has access (or knowledge, for that > > > matter) to > > > > run a sweep on that machine so I got curious. > > > > Logs say an unexpected sweep has been running basically every day > > > > (sometime between 5 and 10 pm, which is apparently when it > hits the > > > > number of transactions). I have a manual sweep at 5:40am in cron > > > and I > > > > checked - configuration is correct and runs as expected. I also > > > > double-checked gstat : > > > > > > > > > > > > Database header page information: > > > > Flags 0 > > > > Checksum 12345 > > > > Generation 51454 > > > > Page size 16384 > > > > ODS version 11.2 > > > > Oldest transaction 21357 > > > > Oldest active 50561 > > > > Oldest snapshot 49520 > > > > Next transaction 51318 > > > > Bumped transaction 1 > > > > Sequence number 0 > > > > Next attachment ID 130 > > > > Implementation ID 24 > > > > Shadow count 0 > > > > Page buffers 0 > > > > Next header page 0 > > > > Database dialect 3 > > > > Creation date Oct 26, 2014 12:28:26 > > > > Attributes force write > > > > > > > > Variable header data: > > > > Sweep interval: 0 > > > > *END* > > > > > > > > > > > > Shouldn`t automatic sweep be disabled or have I misread the > > > > documentation? FB version is 2.5.3. > > > > > > Yes, by setting the sweep interval to 0, automatic sweeping > should be > > > disabled. There is also: > > > http://tracker.firebirdsql.org/browse/CORE-4100 > > > (marked as fixed in 2.5.3) but you are mentioning that you are > using > > > 2.5.3, although I'm not entirely sure if CORE-4100 applies to sweep > > > interval = 0 anyway. > > > > > > You could use the Trace API to trace services API requests to get a > > > clearer picture on what client application is causing the sweep > > in case > > > it has been triggered manually. > > > > > > -- > > > With regards, > > > Thomas Steinmaurer > > > http://www.upscene.com/ > > > > > > Professional Tools and Services for Firebird > > > FB TraceManager, IB LogManager, Database Health Check, Tuning etc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
