OAT SQL Explorer - Live vs Saved Data
Nick asked how often OAT SQL Explorer moves Live data to Saved Data and whether it is configurable. Erika L Von bargen explained a 'Save SQL Trace' task in the OAT Task Scheduler controls it, with a data delete field defaulting to 1 day. Nick set 100,000 statements and a 5-minute schedule but warned it generates huge mon_syssql data; brenddie also nearly filled rootdbs and saw two crashes.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Does anyone know how often the Live data gets pushed into the Saved Data within OAT's SQL Explorer? I've been playing with it for a few days. I've set my "number of traces" to 20000 and still get less than 60 seconds of live data to look at, which makes it hard to debug. So the Saved Data is much easier to work with, but gets updated sparadically. Sometimes I see data about 15 minutes old, sometimes it does not get updated for hours. Is this configurable? Where is this data stored when it's between the Live and Saved areas? Also I'm seeing varying results with the Host Variable setting, some times I see what the host variables are, sometimes I don't. Has anybody noticed this? Any help would be appreciated, Nick
OAT is using a task in the Task Scheduler to save off of the SQL trace data. So you can configure how often IDS saves SQL trace data by modifying the schedule of the task. If you go to the OAT Task Scheduler -> Scheduler page, find the task named "Save SQL Trace". Clicking on the task name will take you to the task details & schedule. You can configure when and how often the task is run by modifying the start time, stop time, and frequency of the task. The data delete field is also important as it specifies how long to save the data. By default, it is only set to 1 day, so you'd want to modify it if you want to keep saved tracing data for longer than a day. Regards, Erika
Thanks Erika - exactly what I was looking for. I had to configure to capture 100,000 statements, and then schedule the task to save data every 5 minutes, to not miss anything. And this creates LOTS of data in the mon_syssql tables... would have filled up our rootdbs (2G) in about an hour. So I think I will move those tables out of root and into their own space, and only run the trace when I can supervise it. This is really cool, but dangerous too! Nick
On Jan 14, 6:18 pm, Nick <milesnmi...@gmail.com> wrote: > Thanks Erika - exactly what I was looking for. > > I had to configure to capture 100,000 statements, and then schedule > the task to save data every 5 minutes, to not miss anything. And this > creates LOTS of data in the mon_syssql tables... would have filled up > our rootdbs (2G) in about an hour. So I think I will move those > tables out of root and into their own space, and only run the trace > when I can supervise it. This is really cool, but dangerous too! > > Nick I too went overboard with the tracing and almost filled rootdbs while playing with tracing. Be careful as I have experienced 2 engine crashes that could be related to the tracing and reporting features. I opened a ticket with IBM and Im waiting for their answer on the crashes but on both occasions I was modifying tracing and running reports from the system reports section.