Settings for Monitored Instance

Lab128 can be customized in the Settings window. When settings are changed, the "Apply" button becomes enabled. Clicking this button commits all changes. All changes take effect immediately: there is no need to re-start Lab128. The "Cancel" button cancels all changes and closes the Settings window. The "OK" button commits (applies) changes and closes the window. The Settings window has two pages: Main Settings and Save Performance Data.

Main Settings page.

There are three sections on this page: General, SQL Statistics, and Active Session History:

• Data History Length, hours. Select the length of history recorded in this box. Lab128 will dynamically change its internal storage to keep the required amount of data. Increase the history length if you need longer coverage, or save performance data to disk (see Saving Performance Data below). The amount of memory used by Lab128 is directly proportional to this setting. Other settings such as default data collection rate, SQL statistics collection rate, and active session history (ASH) collection rate also affect the amount of memory. With the default value of 9 hours and all other default settings, Lab128 typically needs 12-18MB for data storage. For extremely busy instances, the amount can double; for inactive instances the amount will be less. The current amount of memory used is shown below.
  
  
• Auto-connect on Lab128 startup. Check this option to allow Lab128 to automatically connect to the Instance the next time you start the program. If checked, the username and password are stored in encrypted form in the Lab128.ini file. This option is also available in the Instances Overview window. Note: A strong form of encryption is used to store the username and password; however, it is possible to recover them or to reverse-engineer the code. If you want to use the auto-connect option, it is not advisable to use privileged accounts for the purpose of monitoring. It is much more secure to create a dedicated account, giving it bare minimum privileges. For more information about minimum privileges, see Installation and Setup / Required minimum privileges.
  
  
• Default Time Between Measurements. These options change the default data collection rate. This setting along with Data History Length (see the previous section) affect the amount of memory used by data repository.
  
  
• Mirror Lab128 performance data to the disk. Check this option to allow Lab128 to automatically write its internal, in-memory data to the disk. If you exit Lab128 and then restart it, the previously collected data will be loaded and collection will continue. See also Lab128 Concept for more details on how Lab128 stores the performance data. When this option is used, two files are created in the Lab128 directory: <instance_name>_<host_name>.dt and <instance_name>_<host_name>.~dt. If this option is unchecked, the files will be removed.
  
  
• On ORA-00028 - session has been killed. If the Oracle connection used to collect data is killed, Lab128 receives "ORA-00028 error - your session has been killed". This option sets the response to this error. Select "Pause" (default) to put Lab128 into Pause mode - you will need to resume data collection manually. Select the "Resume" option to automatically reconnect to Oracle and resume data collection.
  
  
• Show Time in Time Zone. For consistency with all other Oracle information, Lab128 uses the server time, not the local workstation time. Internally, all times are stored in GMT time zone. Times shown in the application can be converted to the time zone of the server (default), time zone of the computer Lab128 runs on, or UTC/GMT time zone.

• Enabled. Use this check box to enable / disable SQL statistics collection. If you don't use SQL Explorer, there is no purpose of collecting SQL statistics. Disabling them will save memory for conventional statistics. Note: SQL Statistics are expensive because of the sheer volume of data. Depending on the Oracle version and database load, they can consume 40 - 70% of the storage area. We are confident you will find the benefits of SQL statistics-based troubleshooting worth every byte spent for storage.
  
  
• Time Between Measurements. Changes the collection rate of SQL statistics. The rate can be also changed in the Measurement Query Editor.

• Enabled. Use this check box to enable / disable Active Session History collection. Please note, if you disable collection and commit changes by clicking the "Apply" or "OK" buttons, previously collected history will be lost and memory reserved for data will be released.
  
  
• Use Oracle 10g ASH. Use this check box to enable / disable Active Session History collection using v$active_session_history view (Oracle 10g+ only). If enabled, the Lab128 internal buffer will be pre-populated with ASH data. It will then add new data automatically as it becomes available. If this option is enabled, "Include Parallel Slaves" will not be available. The collection rate "Time Between Measurements" cannot be changed because it is controlled by the Oracle instance. Please note that using the v$active_session_history view (as of December 2007) requires purchasing a separate license for the Oracle Diagnostic Pack, which this view belongs to.
  
  
• Prepopulate from 10g ASH. When checked, Lab128 will populate the Active Session History repository on startup with data from v$active_session_history view (Oracle 10g+ only). Lab128 will then use its own facilities to collect Active Session History data. Depending on connection bandwidth, it may take a few minutes to pump that data, so please wait before attempting to access pre-existing data.
  
  
• Include Parallel Query Slaves. When checked, the PQ slave active sessions will be collected as well. Select this option if the server runs Parallel Queries. This option is not available when "Use Oracle 10g ASH" is selected.
  
  
• Include Active Sessions Waiting on Idle Events. Sometimes, active sessions may wait on events belonging to the Idle group. These idle events do not consume system resources and may be skipped for collection. Uncheck this option when there is a substantial percentage of such active sessions and you wish to focus your attention on non-idle events. It saves some memory too.
  
  
• Time Between Measurements. The collection rate can be as high as 10 queries per second - .1 seconds between measurements. The downside of an increased collection rate is a higher requirement for the reserved memory and potentially increased CPU load on the Oracle server. It is advisable to create a X$KSUSECST view (see x$ suggested views in Installation and Setup chapter) to minimize this load.
  
  
• Include Lab128. When checked, the Active Session History collection will include Lab128's monitoring queries.
  
  
• Coloring of Wait Groups. For those who became familiar with event group colors used by Oracle Enterprise Manager, two color schemes are available for different versions of OEM.
  
  
• Optional Columns. Depending on your database environment, you may add optional columns for Active Session History collection. There is a very small overhead for including optional columns. They can be added / dropped at any time; you can experiment by including all columns to find useful combination.

RAC page.

• Do not use GV$ views You should use this option when monitoring very busy Oracle cluster (RAC).
  
  To better explain this option let's assume that there is a 3-instance RAC database. We open 3 monitors in Lab128 and connect to every instance (see also How Lab128 should connect to Oracle Cluster database). In "do not use GV$ views" mode every monitor will be using V$ views and getting data specific to the connected instance. Because all 3 Lab128 monitors are aware of each other, they provide information to each other from remaining instances. Functionally all windows in Lab128 behaves the same as in $GV views mode.
  
  Even if there is only 2 monitors opened, everything will be working well in "do not use GV$ views" mode. Obviously the information for the third instance will be missing. This can be perfectly OK if you are not interested in the third instance. For example, because it is used for failover purposes and it is idling. The point is, you don't have to connect to every instance in this mode, you decide how many and which instances should be monitored.
  
  This mode is highly recommended for very busy databases. Global GV$ views are convenient, but they inherently more complex than V$ views and sometimes they have performance bugs. When using GV$ views, Oracle starts parallel query slaves in every instance; the interconnect will be used to pull data from all instances; the coordinator will have to aggregate data sets - all that require CPU and network resources. From Oracle perspective, it is less expensive to maintain a connection to every instance and execute queries against light-weight V$ views.
  
  Note. When "do not use GV$ views" mode has been changed, restart all monitors connected to this Oracle cluster. It is not necessary to change this option in another monitors belonging to the same cluster, because they already know about this change.

Saving Performance Data Page.

• Default Folder Path. Defines the default folder that will be used when saving performance data. See also Lab128 Concept for more details on how Lab128 stores the performance data. Please note that this parameter needs to be defined if the Auto Save option is used.
  
  
• Include in the File Name section. Defines how the default file name is generated. The file name can contain the TNS Service Name, Instance Name and Host Name. Use the corresponding boxes to select these options. As an alternative, type a string in the Custom String box. A preview of the file name is shown below.
  
  
• Auto Save - Use suggested interval. Lab128 can automatically save performance data on a regular basis. Check this box to set the time interval between saves to optimal value. If you need to save data more frequently, uncheck this option and set the time interval manually - see the next section.
  
  
• Auto Save - Save every N hours. You should be familiar with the details on how Lab128 stores the performance data. Define the number of hours between saves in the corresponding box. It is advisable to set this time to the Data History Length less 1 hour to allow for some overlap in the time periods covered by consecutive files. For example, if Data History Length is set to 12 hours, set Auto Save to 11 hours. You can also choose "Use suggested interval" option (see the previous section) to handle this setting automatically.
  
  
• Auto Delete Set retention period for .lab performance files in days. Files older than that period of time and having naming pattern specified in the "Include in the File Name" section are deleted automatically.