Why wouldn’t someone read the manual on how to care for a car to know how it works? Because everyone wants to have the satisfaction that they got in the car, ran it, and never had to look at the manual! Yet, you didn’t know you had to do maintenance, where that maintenance should take place and at what intervals. Well, this is where best practices come in. Don’t try and drive your car and let the engine churn without knowing how to best care for it.

http://technet.microsoft.com/en-us/sqlserver/bb671430.aspx

DECLARE @Number1 numeric(14,2)
DECLARE @Number2 numeric(14,2)
DECLARE @Number3 numeric(14,2)
DECLARE @Total numeric(14,2)

-- Step 2: then, add the numbers together traditionally.
SELECT @Total = @Number1 + @Number2 + @Number3
SELECT [Total] = @Total

In a recent project it was necessary to grab a lot of numbers from multiple tables, perform calculations with them, and then return the results. The trick to assign multiple variables at once as indicated above yields the results of the simple trick. Instead of adding all the numbers in separate lines, do it all in one SELECT statement. Fast efficient results.

SELECT @Number1 = 15
, @Number2 = 25
, @Number3 = 50
, @Total = @Number1 + @Number2 + @Number3

SELECT [Total] = @Total

It’s great that I can reference previous variables without having to write individual SELECT or SET statements. Makes for very slick code. Just make sure that if you move the variables around, they stay in the descending order of dependency or your numbers will be off.

There are many situations where you can come out with the same results in a set based query as opposed to using a cursor. Again, not all the time, but yes for the most part. Why is it something that I strongly feel you should avoid. It’s the same reason that temporary tables, a-typical parameters (parameter sniffing), and other performance problem situations should be avoided.

In a nutshell, when cursors are used, the stored procedure must be recompiled every so often and there is a ton of overhead involved with that. So don’t use them at all costs. Cursors are great for needing to identify other fields and data per row. Where a set based query can’t accomplish that. Use them sparingly.

Last Resort
Speaking of cursor overhead, if you have to use a cursor, then make sure you have applied the right attributes by asking yourself these questions.
1) Do you need to performan an update on the cursor data? If not, then add the READONLY attribute.
2) Do you need to traverse backwards on the cursor? If not, then add the FAST_FORWARD attribute.

By adding these attributes, you have greatly reduced the overhead of the cursor and make it a much more streamlined stored procedure. I would advise that you add these as a rule because it’s not very often that you would have to do these tasks.

Another option if you have to use Cursors … do not create or try to use temporary tables within the cursor loop. For the same reasons that you’ll want to minimize using temporary tables only because you must understand that the stored procedure will request a recompile every six (6) updates to a temporary table. That can hurt performance a lot.

Another option is to declare variables outside of the cursor loop and then use them in the loop. This helps with compiling and doing extra DECLARE work. It might be small, but it’s happening.

• Reducing blocking by compile locks
• Reducing Stored Procedure recompiles
• Algorithm for Auto-Update stats and recompile determination)

Following these suggestion can reduce CPU activity, needless recompiles, and prevent extra procedure cache examinations, which reduces the profiler SP:CacheMiss activity and subsequent contention.

The first article is where the infamous Note is that describes calling procedures without adhering to case-sensitive names. Here is the excerpt (bold added for emphasis):

Note If an owner-qualified procedure is executed with a different case than what the owner-qualified procedure was created as, the owner-qualified procedure can get a CacheMiss or request a COMPILE lock, but eventually use the cached plan. Therefore, this would not actually recompile the procedure and should not cause much of an overhead. But in certain situations the request for a COMPILE lock can get into a “blocking chain” situation if there are many SPIDs trying to execute the same procedure with a different case than what the procedure was created as. This is true regardless of the sort of order or collation being used on the server or on the database. The reason for this behavior is that the algorithm being used to find the procedure in cache is based on hash values (for performance reasons) which can change if the case is different. The workaround is to drop and create the procedure with the same case as it is executed by the application. You can also make sure that the procedure is executed from all applications that use the same case.

Could not load file or assembly ‘Microsoft.SqlServer.BatchParser, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. An attempt was made to load a program with an incorrect format.

I found an MSDN article that recommends downloading the 64 bit SMO assembly.

Here is the Microsoft MSDN article that talks about SQL Server connectivity for both 2005 and backward compatibility.

• Feature Pack for Microsoft SQL Server 2005

I had to close all applications, especially Visual Studio and then installed the following application.

• X64 Package (SQLServer2005_XMO_x64.msi) – 14675 KB

My system info is:

• OS Name – Microsoft® Windows Vista™ Home Premium
• Version – 6.0.6001 Service Pack 1 Build 6001
• System Type – x64-based PC
• Processor – AMD Turion(tm) X2 Dual-Core Mobile RM-70, 2000 Mhz, 2 Core(s), 2 Logical Processor(s)

The installation took care of updating and using the latest SMO objects in the project. No removing of Assemblies or references was needed. Worked like a charm.

In order to support this, we had to make adjustments to the times on the servers. Update the database data, and more. For this little bug, I wanted to let you know that when I updated the schedule for all my SQL Server Agent Jobs, the schedule did not take effect.

• Issue: Old job schedules were still active (as visible by the Job Activity Monitor) even though the schedule says otherwise
• Takeaway: Run through all changed jobs in the Job Activity Monitor to make sure the Next Run Time reflects the new date/time.
• How to Fix: Go through each job schedule, disable the schedule, commit all dialogs, go back in and re-enable each schedule. This updates to the new date/time.

Let me describe what we did and didn’t do and how to watch out for it. Our environment is setup as such, some details are irrelevant, so I will keep them basic:

• Windows Server 2008
• SQL Server Enterprise Edition 2005
• Lots of RAM and HDD (SAN)
• Window and SQL Clustered

We also have the following environments:

• Prod – Production (detailed above)
• QA – Quality Assurance (same as above minus clustering)
• Dev – Development (same as above minus clustering)

Well, we made all the changes in Dev, rolled out to QA and all tests (eventually) succeeded. Then came time for rollout. We knew that clustering was the missing element in Dev/QA so we had to modify our rollout procedures to take that into account and make sure proper testing and checks were in place to compensate.

Here’s the kicker. We had some jobs that were running at 3:00 AM (MDT) and needed to be adjusted to 9:00 (UTC). Well, we followed these steps to rollout (which was from 12:00 AM (MDT) to 5:00 AM (MDT):

1. Ran Full backups in the morning hours of the rollout day
2. Run Diffs right before rollout
3. Turn off the SQL Agent so any jobs that capture snapshots and do adjustments are all disabled
4. Make all adjustments to server times, schema, and data
5. Update the SQL Agent schedules to run on the adjusted times so that resources are available in our off-peak hours according to UTC and not the former MDT.
6. Test
7. Complete

Alright, step 3 and 4 is what bit us in the butt. In QA and DEV on non-clustered servers, the SQL Agent service being disabled made the SQL Agent completely unavailable from Enterprise Manager. We couldn’t update schedules or anything else. We had to turn the SQL Agent back on, and then update everything. However, in production where there is a clustered server. Turning off the SQL Agent in the Cluster Administrator doesn’t completely shutdown the SQL Agent. It was still accessible from the Enterprise Manager.

We recognized this and took advantage of the opportunity to update the schedules while we were waiting for data to update (hours of time). This would make it so we didn’t lose any precious minutes running through 30 job schedules and getting them all updated before any of them ran.

Well, we recognized later that some of the jobs were still running on the old scheduled time. Looking in the Job Activity Monitor, the Next Run date/time reflected the old schedule!

So for example, a query to remove old historical records that was scheduled to run at 2:00 AM (MDT) was now supposed to run at 8:00 AM (UTC). The Next Run column in the Job Activity Monitor stated 2:00 AM. So I took offline the SQL Agent in the Cluster Administrator and put it back online thinking that the schedules were being cached. No go. Same old schedules.

I then decided to Disable and Enable the schedule on a job, refreshed the Job Activity Monitor and it now reflected the new time. Finally, the work around. The funny thing is though that some of the jobs reflected the new scheduled and the majority of them didn’t. I can’t recall if there were any tweaks I did that would make a difference, but …

What a nasty little bug. It was all because the SQL Agent was still “online” and available in my production Cluster environment. What I would do different? It is to not update the schedules until the SQL Agent is back online (in the clustered environment).

1. Install the Oracle Client from Oracle (10.2.x client version) on the SQL Server box
2. Setup the TNS to the Oracle box through the Oracle Net Manager application
   1. Click the ADD (+) icon under Local | Service Naming
   2. Type in the Service Name, which is used to find in the Service Naming list and the reference to the Service Name in SQL Developer, for example
   3. Choose the Protocol, which is usually TCP/IP
   4. Type in the Host Name, which is the Name or IP Address of the Oracle server.
   5. Type in the Service Name, which is the name of the service or the Global Database Name. It can get confusing between this one and the Service Name above (#1). The difference is that this one (#5) is used to identify the Oracle Name. TNS is a go between. Use (#1) in your app, which then goes through the TNS, which then points to the Service Name (#5) at the database. Another way to look at it is, from your Webserver or SQL Server, directly to Oracle, you go through the TNS using (#1) as the hard coded reference
   6. Specify the Connection Type, which is either Default or Dedicated Server
3. First, turn on the Allow InProcess option
   1. In SQL Server enterprise manager, expand Server Objects node, and then expand the Providers node.
   2. Right-click on the OraOLEDB.Oracle provider and click Properties
   3. Check the Allow Inprocess option (at least this has to be done on my machines)
4. Second, create the Oracle linked server
   1. Right-click on Linked Servers node and click New Linked Server
   2. Type in the name of the linked server as it would appear in the Linked Server list and as it would be referenced by SQL scripts
   3. Choose “Other data source” and select the Oracle Provider for Ole DB. If this is not an option, then follow instructions to install the Oracle Client.
   4. Type in the Product Name, which is the Service Name in #2 of #2 above.
   5. Type in the Data Source, which is the Service Name in #2 of #2 above.
   6. In the Security tab, type in the Remote Login and Password under the last option “Be made using this security context:”
   7. Click OK to commit the changes
5. Write the sql query using the following example
   1. select * from openquery(oraclels, ‘select * from <dbname>.<tablename> where <clause>’)

This doesn’t give the fastest results that we have been able to achieve. There is NOT an easy way to build the query on the fly with variable parameters and have it work quickly. You could create an EXECUTE @SQL statement that has been built around the same query above, but not one that is then in the same batch. The query has to be static and then supply any variable clauses. For example…

select field1, field2
from (select * from openquery (oraclels, ‘select * from db.table where <static clause>’)
where <variable clause>

Hope this helps.