MS SQL Server 2000 Data Collector. Status: 12/8/2008

Transcription

1 MS SQL Server 2000 Data Collector Status: 12/8/2008

2 Contents Introduction... 3 The performance features of the ApplicationManager Data Collector for MS SQL Server:... 4 Overview of Microsoft SQL Server:... 4 The MS SQL Server Data Collector... 6 SQL Server Monitoring:... 7 Monitoring... 8 Data s and Transaction Log... 9 Space requirements:... 9 Performance:... 9 Performance Management: Management of the Windows Operating System Pre-defined Monitoring Policies Appendix A: The Data Collector's Object Structure Copyright REALTECH 2008 Page 2 of 12

3 Introduction There's more to efficient application management than maximizing availability. Targeted tuning can increase the performance and stability of business-critical applications without having to invest in additional hardware (processors, RAM, disk space). A number of data collectors have been developed for theguard! ApplicationManager that provide comprehensive monitoring and generate detailed data analyses. Data collectors do more than simply collect events according to pre-defined rules. They deliver every performance value and the current status of each application object in real time. They also provide insight into configuration attributes, such as the release status or the application's parameter settings. Data collectors model an application in objects and sub-objects, enabling a dedicated handling of alerts, monitoring or status messages. This model ensures that information is clearly structured and that messages are easy to allocate to a problem. Pre-defined and reusable policies for each type of application facilitate the implementation of the solution and the adaptation of monitoring to dynamic landscapes. The ease with which thresholds are set ensures the early recognition of potential errors. Comprehensive reaction management enables flexible alerting for more than 100 different devices and alarm consoles. The automatic discovery of new application instances and objects, including the automatic allocation of policies, enables automatic monitoring even in those cases in which system administrators have completely reconfigured the application, for example, by adding new instances or objects. Central reporting at the application instance and application object level provides for a detailed and effective capacity management of all resources. Integrated Service Level Management ensures that the service levels for application availability and performance are achieved, while Operational Level Agreements (OLAs) can be easily defined at the application object level. Copyright REALTECH 2008 Page 3 of 12

4 The performance features of the ApplicationManager Data Collector for MS SQL Server: The data collector for Microsoft SQL Server enables the comprehensive management of Microsoft SQL Server 2000, as well as Microsoft SQL Server 7.0. With ApplicationManager, a number of MS SQL servers including the databases can be monitored and compared at the same time. All of the components of a Microsoft SQL Server, such as services and databases, are defined and analyzed individually within the framework of the CIM model as managed objects (MO). This enables information to be clearly structured and the components to be individually controlled. The MS SQL data collector is a very powerful application that consists of a number of objects, event calendars and performance counters. All of the information is described in the data collector's online documentation. This document provides an overview of the most important functions. Overview of Microsoft SQL Server: Microsoft SQL Server, a relational database system based on the SQL standard, is generally used to provide with high speed the high data load of business-critical applications such as SAP R/3, to manage the data and to store it permanently. A business-critical application can only be operated smoothly, if the underlying Microsoft SQL Server is high available and does not create bottlenecks. The architecture of the Microsoft SQL Server allows one or more different databases to be managed by a single server process (Win32 service). It is possible to run several databases with just one SQL Server, for example for different applications or business divisions. Every database consists of data files and transaction log files which are combined in so-called filegroups. A database consists at least of one filegroup for data files and one for the transaction log file. These groups consist of at least one data file respectively one transaction log file. It is possible to add more data files to a filegroup in order to increase the volume of a database according to the requirements. Further filegroups for data files can also be added. In addition to the user or customer databases that contain the actual application data, Microsoft SQL Server needs four so-called system databases, "master", "model", "msdb" and "tempdb", which are created during the installation of the SQL Server. The SQL Server needs these system databases to manage internal system information and parameters. It is possible to operate several, completely independent Microsoft SQL Server 2000 instances on large and fast server systems. Copyright REALTECH 2008 Page 4 of 12

5 Architecture of a Microsoft SQL Server system: MS SQL Server Instanz 3 MS SQL Server Instanz 2 System s MS SQL Server Instanz 1 System s master model msdb tempdb master model msdb tempdb User s System s master model msdb tempdb Data group Data- Data- Data- Data- User s User s 3 n n Transaction Log Log- Log- Log- Log n Connections Microsoft SQL Server System DB-Client DB-Client DB-Client Copyright REALTECH 2008 Page 5 of 12

6 The MS SQL Server Data Collector The data collector allows monitoring all installed Microsoft SQL Server instances including its corresponding databases. The following figure shows the status of all objects of a single Microsoft SQL Server in theguard! ApplicationManager's Managed Monitor. Appendix A contains a list of the objects. All important components of an SQL Server system, such as SQL Server instances, databases, SQL Server agent instances, analysis server, etc. are defined and displayed as Managed Objects in the Managed Monitor. The Managed Objects are hierarchically arranged and clearly structured thus providing the current status of every SQL Server component at a glance. It is possible to customize monitoring parameters individually for every component. Copyright REALTECH 2008 Page 6 of 12

7 SQL Server Monitoring: Different criteria can be used to monitor and analyze every instance of a MS SQL Server: Status of SQL Server instance (Win32 Service) Monitoring of SQL server log files Windows event log events generated by SQL Server Number of client connections in relation to the number of licensed clients in % Maximum number of client connections allowed Detection of user logins with security-critical user account (i.e. sa users) Monitoring of SQL Server configuration parameter changes All of the monitored functions can be customized individually and separately for each SQL Server instance. In addition to the monitoring a lot of useful information regarding an SQL Server instance can be displayed in the Managed Monitor. Detailed version information SQL Server logins Internal SQL Server processes Active client connections with the SQL Server SQL Server configuration parameters Copyright REALTECH 2008 Page 7 of 12

8 Monitoring s are important objects regarding the monitoring of the availability, because the availability of applications depends directly on the availability of their databases. All databases of the MS SQL Server can be monitored individually for a large number of different criteria: status availability for clients Required disk space for data files and transaction log files Automatic file growth of data files and transaction log files Check, if database options have been changed In order to check the status, a client connection to the corresponding database is automatically established, thus monitoring the availability of the databases at the same time. All of the monitored functions can be customized individually and separately for each database. The database properties such as database options, total required disc space for data files and transaction log files, file groups, files and configuration, database users, locks, etc. can be directly displayed in the properties. Copyright REALTECH 2008 Page 8 of 12

9 Data s and Transaction Log Data files and transaction log files of a database can be configured to grow automatically in case that the reserved file size does not allow to store more files or transactions. Depending of the configuration, the automatic file growth can be an absolute amount, in relation to the current data file in % or it can be denied entirely. If a database is full because of a failed or deactivated automatic file growth, it cannot store any additional files and its productivity will stop immediately. Therefore, the data collector monitors the size and filling of the databases and signals critical situations at an early stage. In addition, it monitors proactively the file growth by calculating the next file growth and checking the required hard disk space. In total there are three different cases: 1. Fixed file size (not extendable!) => Alert, if more than <X>% of the reserved file space is already in use 2. Extendable file with maximum file size => Alert, if more than <X>% of the max. file space is already in use => Alert, if next file growth will fail due to max. file size => Alert, if there is not enough free disk space for next file growth 3. Extendable file with infinite file size => Alert, if there is not enough free disk space for next file growth The monitoring of data files and transaction log files minimizes the risk of failure due to full databases or transaction log files. The required hard disk space and performance of databases can be measured and evaluated and thresholds can be set for a large number of different criteria. Therefore, bottlenecks will be detected at an early stage and can be corrected. The below list of monitored values is not exhaustive: Space requirements: Total size of database Required disk space for data files Required disk space for transaction log file Current usage rate of transaction log file Performance: Transactions/sec Buffer cache hit ratio Copyright REALTECH 2008 Page 9 of 12

10 Performance Management: Managed Objects such as SQL Server instances or databases display a great number of statistical values regarding their real-time status: utilization and performance values such as number of current client connections, required disk space, database size, transaction log file size, transactions/sec, buffer cache hit ratio, etc.. One can set thresholds for each statistical value, which will generate alerts if violated. This feature also is used for functional and performance monitoring. The statistical values can also be collected in the ApplicationManager database and evaluated using REALTECH Reporting. These reports can be used for trend analysis regarding for example the consumption of disk space as a basis for cost and capacity planning. It is also possible to display and compare all statistical values in the Realtime-Performance-Monitor, which is very useful for the performance and memory optimization. The figure shows the number of transactions/sec of different databases in the Realtime-Performance-Monitor. These views can be used to compare the performance and utilization of the different SQL Servers or databases, for example to distribute the load more efficiently or to change the hardware configuration of individual computers. Copyright REALTECH 2008 Page 10 of 12

11 Management of the Windows Operating System In order to provide complete security for a Microsoft SQL Server one should monitor essential parameters of the Windows operating system, such as physical hard disks, processor utilization, page file, etc. These and other values can be gathered and evaluated with the Windows 2003 and with the Windows 2000 data collector (see the White Paper for Windows data collector"). Pre-defined Monitoring Policies The MS SQL Server data collector contains a number of comprehensive pre-defined policies for each object type, such as server or database. For more information about REALTECH s software solutions see: REALTECH AG Industriestr. 39c Walldorf Germany Tel: +49-(0) Fax: +49-(0) mailto:customer-services@realtech.com Copyright REALTECH 2008 Page 11 of 12

12 Appendix A: The Data Collector's Object Structure The data collector is structured in object types, which among other things, is essential for the configuration and allocation of events as well as for all of the other functions: Object type Metrics Theme Server One to n MS SQL Server instances per Managed Node SQL Server monitoring activity and memory usage on server level SQL Server Agent One SQL Server Agent per MS SQL Server instance SQL Server job monitoring (i.e. backup jobs) Locks Cache Manager Buffer Partition AnalysisServer 4 system databases and n user databases per MS SQL Server instance 7 different lock objects per MS SQL Server instance 9 different Cache Manager objects per MS SQL Server instance One to n Buffer Partition objects per MS SQL Server Instance One MS SQL Analysis Server instance per Managed Node monitoring activity and data volume on database level Locks for different resource types, such as databases, tables, keys, etc. Cache utilization of stored procedures, SQL statements, trigger, etc. Utilization of free pages Activity of Caches, data queues, connections, procedure calls and very much more Copyright REALTECH 2008 Page 12 of 12