The Database Trace
The Database Trace produces a text file containing the SQL statements, rule cache hit statistics, timings, and other data that reflect the interactions of your requestor session with the Pega Platform™ database or other relational databases. A basic familiarity of SQL Operations, (for example read, write, and insert), and BLOB is useful to interpret the output.
The Database Trace is available on the Performance landing page in Dev Studio (Configure > System > Performance > Database Trace) or from the Performance tool in the toolbar.
In the center of the following image, slide the vertical line to compare the Performance landing page and the Performance tool in the toolbar:
Operating the Database Trace tool can adversely affect performance by producing a large volume output. Use the tool for short periods, in non-production environments appropriate for debugging.
Check your knowledge with the following interaction:
Configure the Trace settings
Click Trace Options to open the settings window. The settings window lists all possible events to trace. If an event is inapplicable to a situation, remove it from the list to streamline the results. You also have the option to generate a stack trace. Generating the stack trace is an expensive process and should only be used when required. The following image displays the Database Trace Events window:
Generate Trace
Match the numbers to the following image to learn more about generating a database trace from the Performance landing page:
1. Start trace: The green Play button is a toggle that starts the Database Trace. Once you start the trace, the button changes to a red Stop button.
2. Stop trace: After performing the steps you want to trace, use the red Stop button to stop the Database Trace. After you stop the tool, the table updates with the results for all of the threads traced so far. For example, this trace was generated for a portal.
3. Trace Options: Configure the trace setting prior to running the Database trace.
4. Download trace results: Identify the thread corresponding to the process where you performed the work. Then download a tab-delimited file to view the Database Trace readings using a spreadsheet program such as Excel.
Download data and interpret readings
If database operations, such as queries or commits, take a long time to process, the DB Trace can help determine the source of the performance issue. For example, if you have a query that is taking a long time to process, you can review the Database Trace details in a spreadsheet to investigate the operations that took the most time.
Downloaded data contains a sequential progression of trace events. Match the numbers to the following images to learn more about some of the important fields in the trace. Some spreadsheet columns are hidden in order to showcase the most useful fields:
1. Time(s): The duration, in seconds, of the operation you run.
2. Operation: The type of event. For example, readBlob, writeBlob, or preparedStatement.
3. Size: Blob size or number of rows returned from the SQL operation.
4. Note: A plain language description of the operation. Examples include:
- Looking for instance Rule-Obj-Property
- EMBED-ACTIVITYSTEPS!PYSTEPS
5. SQL: SQL statements that are run to accomplish the event (where applicable). Examples include:
- select pzInsKey, select pyRuleStarts, select pyRuleSet, select pyRuleSetVersion, select pyClassName, select pyRuleAvailable, select pyRuleEnds, select pyCircumstanceProp, pyCircumstanceVal, pyCircumstanceDateProp, or pyCircumstanceDate from pr4_rule_property where pxObjClass = xyz and pxInsId = xyz
Check your knowledge with the following interaction:
This Topic is available in the following Modules:
Quer nos ajudar a melhorar esse conteúdo?