Presentasi berjudul: " performance monitoring and tuning salah satu tugas penting DBA Komputer bagaimana mendapatkan kinerja yang baik Kinerja DBMS memiliki reputasi."— Transcript presentasi:
performance monitoring and tuning salah satu tugas penting DBA Komputer bagaimana mendapatkan kinerja yang baik Kinerja DBMS memiliki reputasi yang buruk dalam hal performance Konten materi : › Performance monitoring › Tuning › Perbedaan monitoring dan performance management
Organisasi pengguna IT monitor dan tune performa IT infrastruktur Infrastruktur IT meliputi › Server › Jaringan › Aplikasi › Database Performance management yang digunakan masih reaktif Contoh : tablespace yang sudah penuh
Apa database performance ? Efisiensi ? Konsep db performance konsep supply and demand User request informasi dari db Dbms supply informasi Db performance tingkat dimana DBMS mensupply informasi untuk permintaan users
Kombinasi dari transaksi online, batch jobs, adhoc query, analisa data warehousing, dan perintah sistem dalam satu waktu Dapat fluktuatif dari hari ke hari, jam ke jam, menit ke menit terkadang dapat diprediksi (contoh : penggunaan internet paling banyak pada waktu istirahat) Lebih sering tidak dapat diprediksi Memiliki dampak besar pada performa db
Kemampuan seluruh komputer untuk memproses data Gabungan kecepatan I/O, CPU dan kemampuan paralel komputer, efisiensi OS dan system software
Hardware dan software sebagai tempat untuk penampungan data sistem Meliputi › Db kernel › Disk storage › RAM chips › Cache control › microcode
Semua sistem dapat dilakukan optimasi DBMS perlu optimasi khusus dilakukan ke dalam internal DBMS Banyak faktor yang perlu dioptimalkan SQL query, db parameter
Permintaan yang tinggi muncul contention Contention kondisi dimana dua atau lebih komponen dari kerja menggunakan sebuah resource dengan bertentangan Contoh dua upate bersamaan pada satu data Contention naik, througput naik
Butuh langkah proaktif selain langkah reaktif Perubahan pada kode aplikasi belum bisa dianggap langkah proaktif Langkah proaktif memperbaiki masalah sebelum menyelesaikan aplikasi Dba sering menggunakan pendekatan reaktif
Penggunaan event-drivent tools untuk mendeteksi masalah kinerja secara otomatis Manajemen performance != monitoring performance Manajemen performance combine monitoring performance + resolve masalah Meliputi 3 komponen spesifik › Monitoring, analisis, dan koreksi Monitoring identifikasi masalah
Komponen kedua dari performance management Monitoring dapat menghasilkan ribuan laporan masalah Hasil monitoring tidak dapat digunakan untuk mengambil keputusan Analisa diperlukan untuk mencari penyebab utama dan cara mengatasi masalah Hanya dapat dilakukan oleh tenaga ahli, seperti DBA
Estimating the performance of applications differs from analyzing and optimizing single database queries. Performance should be modeled for the entire application, because individual queries may optimize at the expense of other queries. A model will show the overall effect of all the queries and how they affect each other's performance. Such a model enables the DBA to optimize overall performance.
Creating an accurate performance model is an iterative process. Each change must be reviewed and updated, and its impact gauged for effectiveness. DBAs, SAs, application developers, and capacity planners must cooperate to share information and address any business requirement issues that may affect the performance criteria.
Capturing and analyzing resource usage trends and performance statistics over time is another valuable performance task. Historical performance and resource trending allows DBAs to predict the need for hardware upgrades weeks, and perhaps months, in advance. Administrators can track key performance statistics (such as buffer hit ratios, file I/O, and log switches) and store that information in tracker tables in the database. This provides valuable historical information that can be reported and analyzed. DBAs can track performance and resource consumption and predict when hardware resources will be consumed by increasing usage. Furthermore, historical trends can illuminate periods when database performance is slower than usual due to increased user activity. For example, database applications tend to run slower the first three days of the month due to month-end processing requirements. Maintaining key historical performance indicators can provide a huge benefit to DBAs as they attempt to comprehend the performance characteristics of their applications, databases, and systems.
Service-level management (SLM) is the "disciplined, proactive methodology and procedures used to ensure that adequate levels of service are delivered to all IT users in accordance with business priorities and at acceptable cost." In order to effectively manage service levels, a business must prioritize its application and identify the amount of time, effort, and capital that can be expended delivering service for those applications
A service level is a measure of operational behavior. SLM ensures that applications behave accordingly by applying resources to those applications based on their importance to the organization. Depending on the needs of the organization, SLM can focus on availability, performance, or both. In terms of availability, the service level might be defined as "99.95% uptime from 9:00 A.M. to 10:00 P.M. on weekdays." Of course, a service level can be more specific, stating "average response time for transactions will be two seconds or less for workloads of 500 or fewer users."
For a service-level agreement (SLA) to be successful, all parties involved must agree on stated objectives for availability and performance. The end users must be satisfied with the performance of their applications, and the DBAs and technicians must be content with their ability to manage the system to the objectives. Compromise is essential to reach a useful SLA. In practice, though, many organizations do not institutionalize SLM. When new applications are delivered, there may be vague requirements and promises of subsecond response time, but the prioritization and budgeting required to assure such service levels are rarely tackled unless the IT function is outsourced. Internal IT organizations are loath to sign SLAs because any SLA worth pursuing will be difficult to achieve. Furthermore, once the difficulties of negotiating an SLA are completed, the business could very well turn around and outsource the SLA to a lower-cost provider than the internal IT group.
The failure of SLM within most businesses lies with both IT organizations and business users. The business users frequently desire better service but are not willing to make the effort to prioritize their needs correctly or to pay additional cash to achieve better service. Another potential problem with SLM is the context of the service being discussed. Most IT professionals view service levels on an element-by-element basis. In other words, the DBA views performance based on the DBMS, the SA views performance based on the operating system or the transaction processing system, and so on. SLM properly views service for an entire application. However, it can be difficult to assign responsibility within the typical IT structure. IT usually operates as a group of silos that do not work together very well. Frequently, the application teams operate independently from the DBAs, who operate independently from the SAs, as shown in Figure 9-3. When an application team has staffed an application DBA function, that team may not communicate effectively with the corporate DBA silo. These fractured silos make cooperation toward a common application service level difficult.
To achieve end-to-end SLM, these silos need to be broken down. The various departments within the IT infrastructure need to communicate effectively and cooperate with one another. Failing this, end-to-end SLM will be difficult, if not impossible, to implement. SLM is a beneficial practice: A robust SLM discipline makes performance management predictable. SLM manages the expectations of all involved. Without an SLA, how will the DBA and the end users know whether an application is performing adequately? Not every application can, or needs to, deliver subsecond response time. Without an SLA, business users and DBAs may have different expectations, resulting in unsatisfied business executives and frustrated DBAs. Not a good situation.
With SLM in place, DBAs can adjust resources by applying them to the most mission-critical applications as defined in the SLA. Costs will be controlled and capital will be expended on the portions of the business that are most important to the business.
Aplikasi db memerlukan interkasi konstan antara beberapa resource komputer agar bekerja sesuai spesifkasinya Tuning db dapat dipecah menjadi 3 komponen › System tuning › Db tuning › Aplikasi tuning Ketiganya berhubungan
System tuning occurs at the highest level and has the greatest impact on the overall health of database applications because every application depends on the system. For the purposes of this discussion, we will define the system as comprising the DBMS itself and all of the related components on which it relies. No amount of tuning is going to help a database or application when the server it is running on is short on resources or improperly installed.
The DBMS can and must be tuned to assure optimum performance. The way in which the DBMS software is installed, its memory, disk, CPU, other resources, and any configuration options can impact database application performance. The other systems software with which the DBMS interacts includes the operating system, networking software, message queueing systems, middleware, and transaction processors. System tuning comprises installation, configuration, and integration issues, as well as ensuring connectivity of the software to the DBMS and database applications.
Performance can be impacted by the physical design of the database, including normalization, disk storage, number of tables, index design, and use of DDL and its associated parameters. The physical location of database files on disk systems will have an impact on the performance of applications accessing the data. As more data is stored on the same disk device, the possibility of performance degradation increases.
However, design is not the only component of database performance. The organization of the database will change over time. As data is inserted, updated, and deleted from the database, the efficiency of the database will degrade. Moreover, the files that hold the data may need to expand as more data is added. Perhaps additional files, or file extents, will need to be allocated. Both disorganization and file growth can degrade performance. Indexes also need to be monitored, analyzed, and tuned to optimize data access and to ensure that they are not having a negative impact on data modification.
The application itself must be designed appropriately and monitored for efficiency. Most experts agree that as much as 75% of performance problems are caused by improperly coded applications. SQL is the primary culprit; coding efficient SQL statements can be complicated. Developers need to be taught how to properly formulate, monitor, and tune SQL statements. However, not all application problems are due to improperly coded SQL. The host language application code in which the SQL has been embedded may be causing the problem. For example, Java, COBOL, C++, or Visual Basic code may be inefficient, causing database application performance to suffer.
Tools DB efektif membantu mengatur performa DB Beberapa vendor menyertakan beberapa tools untuk performance management Tapi tidak terlalu bisa menangani tipe data yang sangat banyak Tools DB dapat dikatagorikan 2 tuama › Performance management › Performance optimization
Performance monitor Performance estimation Capacity planning tools SQL analysis dan tuning Advisory tools augment SQL System analysis dan tuning
In the performance optimization category, several tools can be used to tune databases. › Reorganization tools automate the process of rebuilding optimally organized databases. Databases can cause performance problems due to their internal organization (e.g., fragmentation, row ordering, storage allocation). › Compression tools enable DBAs to minimize the amount of disk storage used by databases, thereby reducing overall disk utilization and, possibly, elapsed query/program execution time, because fewer I/Os may be required. (Caution: Compression tools can also increase CPU consumption due to the overhead of their compress/decompress algorithms.) › Sorting tools can be used to sort data prior to loading databases to ensure that rows will be in a predetermined sequence. Additionally, sorting tools can be used in place of ORDER BY or GROUP BY SQL. Retrieving rows from a relational database is sometimes more efficient using SQL and ORDER BY rather than SQL alone followed by a standalone sort of the SQL results set.
The DBA will often need to use these tools in conjunction with one another—integrated and accessible from a central management console. This enables the DBA to perform core performance-oriented and database administration tasks from a single platform Many DBMS vendors provide solutions to manage their databases only; for example, Oracle provides Oracle Enterprise Manager and Sybase provides SQL Central for this purpose. Third-party vendors provide more robust options that act across heterogeneous environments such as multiple different database servers or operating systems. In general, it is wise to use the DBMS vendor solution only if your shop has a single DBMS. Organizations with multiple DBMS engines running across multiple operating systems should investigate the third-party tool vendors.
We have defined database performance and discussed it from a high level. Before we delve into the specifics of system, database, and application performance, let's examine some rules of thumb for achieving your DBMS-related performance goals.
Do not over-tune Remain focused Do not panic Communicate clearly Accept reality
Applications that access relational databases are only as good as the performance they achieve. The wise organization will implement a comprehensive performance monitoring, tuning, and management environment that consists of policies, procedures, and integrated performance management tools and utilities.