Database performance problems are not caused by magic. Indeed, all performance problems are always caused by change. That statement flies in the face of what I normally say, which is “Almost never say always or never”… but in this case, it is true.
Think about it for a moment. If everything remains stable and unchanging in your environment, then why would performance vary? That’s right, it wouldn’t.
Something tangible must change before a performance problem can be experienced. The challenge of performance tuning is to find the source of the change, gauge its impact, and formulate a solution. Change can take many forms – environmental, system, database, application – but regardless of the type of change, if it impacts CPU usage, I/O requests or concurrent data access it can have a significant impact on performance.
But perhaps even more important than reacting to change is to build a performance-centric development organization where you focus on how things will perform early in the application development process. After all, designing an application that accesses hundreds of rows is simple, but many production applications access thousands or even millions of rows of DB2 data. An up-front approach to supporting such volume can reduce the back-end changes required to retrofit applications once they have been migrated to production.
Although the majority of your performance problems are likely to be application-oriented, you must be prepared to explore all other areas when application tuning has little effect. Things like database reorganization, tuning memory usage and setting appropriate system parameters all contribute to the overall performance of your DB2 applications.
With all of that in mind, a best practices approach to DB2 development and performance is required to assure an optimal result. If you are interested in learning about DB2 performance best practices, be sure to attend my upcoming webinar, sponsored by Datavail, titled Best Practices for Optimizing DB2 Performance. Register today for the webinar which is being held on Thursday, November 14th, at 10 a.m. MST.
The presentation will discuss DB2 performance tuning and management from a best practices perspective, outlining the issues involved in maintaining efficient DB2 applications, databases, and subsystems. Along the way, I will go over a variety of guidelines and tips for achieving optimal performance in a DB2 for z/OS environment.
What better use can you make of an hour out of your day to learn techniques for developing, monitoring and tuning DB2 applications, databases, and systems with performance in mind?
See you there!
The “ORA-12154: TNS:could not resolve the connect identifier specified” Oracle error is a commonly seen message for database administrators.
Our database experts explain how to recover and restore a table from an Oracle 12c RMAN Backup with this step-by-step blog. Read more.
This blog reviews how you can generate scripts for SQL server logins, role assignments, and server permissions for a smooth migration.