Customer login     
|       Buy now!      |       Download trial      |       About ORM Profiler      |       Support      |       Home      |     

Product info

Customer benefits






Change log history
Online documentation


ORM Profiler general features overview

  ORM Profiler offers a rich set of features to help you gain insight in what data-access code is doing, what could potentially be a problem and how to fix these problems. Below you'll find a quick overview of the main features of ORM Profiler. As ORM Profiler displays numeric values with the regional settings of the logged-in user, the screenshots show numeric values using the European formatting, which means the ',' you see in numbers is the decimal symbol.
  • Clever user-interface which offers multiple views on the same data. The user-interface consists of two parts, which are kept in sync when you switch between views. This way you can select a query in one view and switch to another view to see the same query in the context of that view, as each view will navigate to the query selected.

  • See database activity in real time The Real-Time View offers insight what database activity your application is performing, in real time. It offers a Chronological Connection View, which shows connections with commands / transactions in the order they're executed in real time, as well as a set of activity graphs (shown below) which show the (aggregated) real-time data in graph form

  • Production profiling. The database activity interceptor of ORM Profiler can be switched on or off with a simple method call. When the interception is switched off, no activity is logged nor sent to the client. This makes it ideal for production profiling, where you disable the interception of activity till you switch it on when needed, e.g. when a webpage suddenly became slow.

  • Result-set retrieval. For queries which returned a DbDataReader when they were executed, the GUI offers the ability to obtain the resultset of the query. This is done by re-executing the query with its parameters on the database server. The retrieved result set is retrieved together with its schema. For every resultset returned by the query, a schema is retrieved as well. The schema tables together with the resultsets returned by the query are bound to a selector which allows you to select which table to view in the associated grid.

  • See queries in context of the executing code. One of the views on the profiling data offered by the ORM Profiler client application is Queries in Context, where each query is grouped below the stack trace of the method which executed the query. This way you not only see detailed query statistics but also which code executed the query and along which code path.

  • See the database activity in chronological order. Another view on the profiling data offered by the ORM Profiler client application is the Connection in Chronological Order. For each connection, this view shows you all open and close actions, begin transaction, commit/rollback transaction as well as the queries executed over each connection and within each transaction. If a connection had multiple open / close actions, these are all shown below the connection. As the user-interface keeps views in-sync, clicking a query will navigate to the other views for that query as well.

  • Navigate to method calls in Visual Studio or other editor Execute, Open, Close and other major actions taken on ADO.NET objects are logged by ORM Profiler, including the stack trace of the originating call. ORM Profiler client views all these stack traces in full and, if applicable, lets you navigate directly to the file and line number of a method in a stack trace. If the file is open in a solution in a Visual Studio instance, it will navigate to the line in that file, otherwise it will open the file in a new instance of Visual Studio. Not using Visual Studio? No problem, if the .cs or .vb extension is registered with another editor, that editor will be opened instead.

  • Obtain query execution plans directly from the database. ORM Profiler determines the exact time the execution of a SQL statement takes. If a query occurs to be slow, it might be the schema in the RDBMS needs further tweaking or the query itself might be using less efficient SQL. To see if that's the case, ORM profiler offers the ability to obtain the exact execution plan of a SQL statement from the RDBMS itself and shows this information in detailed form with the query. This way you can check for example whether a query uses indexes or performs a full table scan or whether the query performs excessive I/O.

  • Filtering system for narrowing down focus. A profiled application can generate a lot of profiling data, which might make focusing on a specific area of the application more difficult than expected. To overcome this, ORM Profiler offers a fine-grained filtering system which allows you to specify specific aspects of the area you want to focus on, ignoring the rest. This way you can quickly focus on a specific area of your application, avoiding distraction of areas you're not interested in.

  • Multi-application profiling at the same time. The ORM Profiler client can record profiling data from multiple profiled applications at the same time. All profiling data will be grouped per application and you can view the information of all applications in a single snapshot. This gives a good overview of what activity another application might have performed on the used RDBMS and which might have caused some queries to be executed less quickly.

  • Deep analysis system. Although SQL statements which take considerable time to execute are easy to spot, most problems with data-access code are revealed only through deeper analysis of the profiling data. ORM Profiler offers many configurable analysis features which are designed to spot these problems for you. Analysis is both done in real-time in the Real-Time View and in a snapshot. See the analysis features page for more information.

  • Async / Await support. Data-Access/ORM code which utilizes ADO.NET's new async API is fully supported by ORM Profiler and every activity is intercepted and included in the data to analyze.

  • Create snapshot on the command line. Creating a snapshot is usually done by using the ORM Profiler client. However, this isn't always ideal, e.g. when you want to create a snapshot on a server where you can only run tools from the command line. ORM Profiler offers a command-line tool which quickly allows you to create a snapshot from the command line for analysis later.

  • Create snapshot in code. When running your tests, it might be you want to create a snapshot from the database activity created by your tests, to see whether you're doing things correctly or not. To make this easy, ORM Profiler offers a simple way to create a snapshot from code and start profiling right away. You can also combine this with the production profiling feature to create a snapshot from within your application when you enable profiling in production. For example, this can be done from an administrator area in your web-application.

  • Exclude sections of code from profiling. Not all sections in your application might need profiling. To avoid having these sections generate profiling data which might pollute your snapshot with profiling data you aren't interested in, you can switch off profiling for a given section of code with a single line of code.

  • Database agnostic, every ADO.NET provider with a DbProviderFactory is supported. ORM Profiler can profile any application that creates (indirectly) ADO.NET class instances using the DbProviderFactory system. When your application uses an O/R mapper or data-access layer which utilizes DbProviderFactory, ORM profiler can intercept and profile the database activity of your application. The requirements page lists some of the supported O/R mapper frameworks. Additionally, if you've written your own data-access code using DbProviderFactory, ORM Profiler can profile your application as well.

  • Multiple O/R mapper framework profiling at the same time. ORM Profiler uses a wrapping factory for the DbProviderFactories found in the .NET configuration to profile the database activity of your application. It doesn't matter whether your application uses two or more ways to execute queries through ADO.NET. E.g. if you have written most of your application with Entity Framework v4, but optimized some queries using, all queries will be profiled by ORM Profiler. Any mixture of data-access technologies used in your application is supported, as long as the data-access code uses DbProviderFactory to instantiate ADO.NET classes.