Confio Ignite

Most developers and DBAs are aware of Toad to help with performance tuning and database management.  However, very few are aware of Confio Ignite.  This is an excellent tool for identifying and fixing performance issue in your Oracle, MS SQLServer, DB2, and Sybase.

It help answer questions like

1. Why is an application waiting on the database and what can be done?
2. How did the code promotion affect response times in your database?
3. Did the vendor patch really fix the problem?
4. Which bottlenecks in your database directly impact end-user service?

To try out the tool, you can use the free version called IgniteFree.

The tutorial is available here.
In addition to that you can also see

• Ignite PI for SQL Server Demo (5 minutes tutorial)
• Ignite PI for Oracle Demo (5 minutes tutorial)
• 4 minutes narrated slide show

There are also Webinars provided:

4 Oracle Performance Tips You Should Know presented 24 June 2010
Learn how to determine the best tuning approach for a SQL statement by utilizing response time analysis and visual SQL diagramming techniques. A "must see" for those who rely on OEM Performance Packs.

4 SQL Server Performance Tips You Should Know presented 25 May 2010

Learn a four-step process that will help you quickly find and correct the bad SQL code. Covering topics such as: SQL diagramming, wait type data, column selectivity, and more.

ASP.Net behavior in IIS

A friend of mine highlighted this article to me:

http://aspnetresources.com/articles/debug_code_in_production.aspx

Even though the article referred to Framework 1.1 but it looks like it is still applicable for Framework 2.0, 3.0 and 3.5.

Some of my key take aways from the article are:

1. When deploying an application, it is critical to remember to change the debug to false.
2. Frequent changes on the aspx files will also generate additional files which will only be removed when the application is restarted or the web.config is edited.
3. Too many aspx files in a folder will incur high start up time, since compilation happens to many files even though only one is accessed.
   

<compilation debug="false" />

There are a lot more information there and I believe is critical for developers too.

Side Note

On the server (hosting your application), you should always configure your antivirus not to scan your web.config, global.asax and global.asa. From my experience:

• the act of the antivirus scanning will cause IIS to detect those as changes to those files and will force a restart on the applications.
  
• And the very act of accessing any of those pages, will cause the antivirus to scan those files.

Consequently, you may end up with an application that will only allow one person to access the application.