Recently, a performance monitoring project is mainly due to the basic performance of the host and database. The host uses JNI mode to collect, data is acquired in a variety of ways (different ways according to different databases), mainly in JDBC mode Database analysis tool assistance. During the process of doing projects, there must be a certain understanding of Oracle's StatsPack. This tool will make a simple analysis of the database performance issues caused by various reasons, including the performance of the SQL statement. Here is a brief introduction to this.
The STATSPACK tool is a tool with later versions of Oracle8.1.6, which is completely written, the operation process is consistent with the run script. When the tool is created, the default tablespace, temporary table space, and user Perfstat password are required. User Perfstat is a user created when the tool is created, which has read-only permissions to all tables that require monitoring performance. Tool creation is to implement script spcreate.sql:
For Example, on UNIX: SQL> Connect / As Sysdba
SQL> Define default_tablespace = 'Tools'
SQL> Define Temporary_tablespace = 'TEMP'
SQL> Define perfstat_password = 'my_perfstat_password'
SQL> @? / Rdbms / admin / spcreate
This process creates more than 40 tables, and the table name begins with Stats $, and the sampling cycle parameters are set by calling the stored procedure dbms_job.interval (Job_Number, 'sysdate (1/48)'). SQL> Connect Perfstat / My_PERFSTAT_PASSWORD Connected. SQL> @? / Rdbms / admin / spreport needs to be obtained from this report, if the information is insufficient, the acquisition can be set by execute statspack.snap; The level of information, the higher the level, the more detailed information. It's just a very simple introduction, mainly telling you what to do? Instead of how to do ?, this way to a proxy monitoring program, there is a fatal weak point: Many indicators in monitoring must It is 1 second, such time intervals will cause the data volume in the database to increase, and must be cleared. In addition, due to the analysis package needs to be installed, the proxy monitoring will also be more troublesome, and you need to make a lot of operations for the monitored database.
Consider the solution to the agent monitoring the database, the condition is a report that the cumulative value stored in the Oracle database must be logically processed. For the three-layer business logic (the monitor is a business logic layer, just providing data returns a certain format), this part of the most reasonable way should be placed in the business layer, and the display layer obviously should not store large number of business logic. The data layer is the object of acquisition, the number is uncertain, the impact on flexibility and extensibility is relatively large, that is, the reason is very inconvenient to use, then this part is placed on logical layer processing obviously reasonable. This also brings a certain challenge to the implementation!
