When debugging an application that is not performing well, finding the real issue can be very hard. Is it The LAN? The WAN? Is it the application server? Load balances? DNS? LDAP? The database server? Maybe it is the SAN or a disk storage device. We can do things to make it easier. You can arm your application and build it so that it is ready to do battle in the complete operation arena that it will be required to run in. Arming into the DB Layer Most databases have a procedural language and the ability to trigger audit transactions, and drive functionality. You can also build in debugging triggers that can track what is happening in the app. You can design your procedures and functions to do the same. If you track how long each type of transaction or call takes to complete, and what the parameters were when a function or package is called, then you have a great tool for debugging development, as well as identifying production issues. If you see that the “create new” function doesn’t take any longer to complete than it did before the slowdown, then the database is not the issue; it must be further upstream. If they are taking substantially longer, then it must be downstream (disk, server, DB configuration, DSS queries in an OLTP database, etc.). Read (http://tech.lds.org/forum/showthread.php?p=27109#post27109) what others are saying about this article. Read more (http://tech.lds.org/index.php?option=com_content task=view id=403 Itemid=5).
Continue reading at the original source →