# Ensure the database design is properly normalized.
# Have the application access server objects in the same order each time.
# During transactions, don't allow any user input. Collect it before the transaction begins.
# Avoid cursors.
# Keep transactions as short as possible. One way to help accomplish this is to reduce the number of round trips between your application and SQL Server by using stored procedures or keeping transactions with a single batch. Another way of reducing the time a transaction takes to complete is to make sure you are not performing the same reads over and over again. If your application does need to read the same data more than once, cache it by storing it in a variable or an array, and then re-reading it from there, not from SQL Server.
# Reduce lock time. Try to develop your application so that it grabs locks at the latest possible time, and then releases them at the very earliest time.
# If appropriate, reduce lock escalation by using the ROWLOCK or PAGLOCK.
# Consider using the NOLOCK hint to prevent locking if the data being locked is not modified often.
# If appropriate, use as low of an isolation level as possible for the user connection running the transaction.
# Consider using bound connections.
Thursday, February 18, 2010
Wednesday, February 17, 2010
Relation Between Application Domains and Assemblies
Most development and runtime environments has a definition for the building blocks of an application. Assemblies are the building blocks of .NET framework applications. They are the fundamental unite of deployment. An assembly consists of types and resources working together to form a logical unit of the functionality of your application. You can divide your .NET application into assemblies. The assembly file can have an .EXE or a .DLL extension.
As we mentioned previously, you can run more than one application domain within your application. Each application domain will run a given piece of code. An assembly is simply the piece of code we mean here. So, each application domain can run an assembly within the entire application. This is the relation between application domains and assemblies.
As we mentioned previously, you can run more than one application domain within your application. Each application domain will run a given piece of code. An assembly is simply the piece of code we mean here. So, each application domain can run an assembly within the entire application. This is the relation between application domains and assemblies.
AppDomain and .Net Developer
You’ve created two ASP.NET applications on the same server, and have not done any special configuration. What is happening?
A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
Note again: the one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will run with full trust by default. Fully trusted code can execute native code, and native code can essentially have access to anything inside the process. You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.
A single ASP.NET worker process will host both of the ASP.NET applications. On Windows XP and Windows 2000 this process is named aspnet_wp.exe, and the process runs under the security context of the local ASPNET account. On Windows 2003 the worker process has the name w3wp.exe and runs under the NETWORK SERVICE account by default.
An object lives in one AppDomain. Each ASP.NET application will have it’s own set of global variables: Cache, Application, and Session objects are not shared. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain. If there are classes with shared or static members, and those classes exist in both applications, each AppDomain will have it’s own copy of the static fields – the data is not shared. The code and data for each application is safely isolated and inside of a boundary provided by the AppDomain
In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
Note again: the one caveat to the idea of an AppDomain as a boundary is that ASP.NET applications will run with full trust by default. Fully trusted code can execute native code, and native code can essentially have access to anything inside the process. You’ll need to run applications with partial trust to restrict access to unmanged code and verify all managed code to secure AppDomains.
Advantages of .NET AppDomain
You may ask, why should I create more than one application domain within my application?
The following advantages of application domains answer this question.
* In terms of isolation, code running in one application domain can not access code or resources running in another application domain.
* In terms of security, you can run more than one set of web controls in a single browser process. Each set of them is running in a separate application domain so each one can not access the data or resources of the other sets. You can control the permissions granted to a given piece of code by controlling the application domain inside which the code is running.
* In terms of robustness, fault in code running in one application domain can not affect other applications although they all are running inside the same process. Individual application domain can be stopped without stopping the entire process, you can simply unload the code running in a single application domain.
So, from the above advantages, you can observe that by using application domains you can create rather robust .NET applications. It increases isolation, stability, and security of your application.
The following advantages of application domains answer this question.
* In terms of isolation, code running in one application domain can not access code or resources running in another application domain.
* In terms of security, you can run more than one set of web controls in a single browser process. Each set of them is running in a separate application domain so each one can not access the data or resources of the other sets. You can control the permissions granted to a given piece of code by controlling the application domain inside which the code is running.
* In terms of robustness, fault in code running in one application domain can not affect other applications although they all are running inside the same process. Individual application domain can be stopped without stopping the entire process, you can simply unload the code running in a single application domain.
So, from the above advantages, you can observe that by using application domains you can create rather robust .NET applications. It increases isolation, stability, and security of your application.
Application Domain or AppDomain
.NET introduces the concept of an application domain, or AppDomain. Like a process, the AppDomain is both a container and a boundary. The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data. As the operating system uses a process to isolate misbehaving code, the .NET runtime uses an AppDomain to isolate code inside of a secure boundary.
Note, however, that the application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.
An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.
Note, however, that the application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.
An AppDomain belongs to only a single process, but single process can hold multiple AppDomains. An AppDomain is relatively cheap to create (compared to a process), and has relatively less overhead to maintain than a process. For these reasons, an AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.
Friday, February 12, 2010
Top 10 Mistakes on SQL SERVER
10. Unknown Scalability Requirements
9. Improperly Normalized Tables
8. Improper Indexing
7. No Baseline or Benchmarks
6. Disks — Thinking about Space but Not I/O
5. Lack of Error Notification
4. Poor or Nonexistent Backup Strategy
3. Lack of Query Tuning and Optimization
2. Ignorance of Internals
1. Overuse of Cursors
9. Improperly Normalized Tables
8. Improper Indexing
7. No Baseline or Benchmarks
6. Disks — Thinking about Space but Not I/O
5. Lack of Error Notification
4. Poor or Nonexistent Backup Strategy
3. Lack of Query Tuning and Optimization
2. Ignorance of Internals
1. Overuse of Cursors
Benefits of Stored Procedures
Modular programming :
You can write a stored procedure once, then call it from multiple places in your application.
Performance
Stored procedures provide faster code execution and reduce network traffic.
* Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
* Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.
Security
Users can execute a stored procedure without needing to execute any of the statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.
You can write a stored procedure once, then call it from multiple places in your application.
Performance
Stored procedures provide faster code execution and reduce network traffic.
* Faster execution: Stored procedures are parsed and optimized as soon as they are created and the stored procedure is stored in memory. This means that it will execute a lot faster than sending many lines of SQL code from your application to the SQL Server. Doing that requires SQL Server to compile and optimze your SQL code every time it runs.
* Reduced network traffic: If you send many lines of SQL code over the network to your SQL Server, this will impact on network performance. This is especially true if you have hundreds of lines of SQL code and/or you have lots of activity on your application. Running the code on the SQL Server (as a stored procedure) eliminates the need to send this code over the network. The only network traffic will be the parameters supplied and the results of any query.
Security
Users can execute a stored procedure without needing to execute any of the statements directly. Therefore, a stored procedure can provide advanced database functionality for users who wouldn't normally have access to these tasks, but this functionality is made available in a tightly controlled way.
Subscribe to:
Posts (Atom)