This time there should not be any SQL Components which you removed. If you see the components that means even msiinv.exe did not work. What is next?
You need to use Windows Installer CleanUp Utility. It is developed by Microsoft for Windows OS to resolve uninstallation problems of programs that use the Windows Installer technology. It wipes Invalid or corrupted entries from registry for the component.
There are many links available in the internet to download the tool. You can directly get it from here as well Windows CleanUp Utility
The utility displays a list of all the Windows Installer-based applications on the system as shown below:
Select the component you want to uninstall and click on Remove:
Note: Never Ever click on Select All. Tools are good until you make a mistake.
In this article I am going to show you how to Completely Uninstall SQL Server Components which are left behind. In other words what to do if the regular uninstall process from Control Panel fails.
Even more, sometimes the control panel shows that the SQL component has been uninstalled. But when you try to reinstall, it fails again. And this is because of the left behind components.
There are many articles in the internet suggests to change registry entry. Modifying registry is always associated with risk. For me it didn’t work, may be because the registry was corrupted.
You need to use the MSI inventory tools to check and uninstall the components. I have made it available for you in the following link Download msiinv.zip
Once downloaded open Powershell and run the below command. In the below example I have downloaded the msiinv in D drive under msiinv folder. Please put valid paths and then run the command. This will create the out put file with all the GUID of the SQL Components.
After reading this article you’ll be able to fix if standard method of uninstall OLE DB Provider for DB2 does not work. The requirement was to upgrade OLE DB provider for DB2 from version 3.0 to version 5.0. As per Microsoft Document you cannot upgrade OLE DB Provider for DB2 without uninstall of prior versions.
The following instructions are listed in Microsoft Document named “Microsoft OLE DB Provider for DB2 Version 5.0
Upgrade from Previous Version
Microsoft OLE DB Provider for DB2 V 5.0 does not upgrade previous releases. If you have the following previous versions installed, then you must remove them prior to installing the Microsoft OLE DB Provider for DB2 V 5.0.”
To uninstall the product
You can use Windows Programs and Features to remove the product.
Click Control Panel, click Programs, and then click Programs and Features. The Uninstall or change a program dialog appears.
In the Name list, double click Microsoft OLE DB Provider for DB2 Version 5.0. The Data Provider Installation Wizard appears.
Click Next to get started.
On the Program Maintenance dialog, click Remove.
On the Remove the Program dialog, click Remove.
When prompted by Windows User Account Control, click Yes.
On the Completion page, click Finish
This works in ideal condition. Uninstall of OLE DB Provider for DB2 does not always go well and throw weird error messages. The Uninstall may fail due to different reasons like existing DB2 version was not properly installed, someone deleted some of the MSI files or the registry corruption etc.
One of the error message looks like as follows:
MSI (s) (78:64) [21:44:40:923]: Note: 1: 1725
MSI (s) (78:64) [21:44:40:923]: Product: Microsoft OLE DB Provider for DB2 -- Removal failed.
MSI (s) (78:64) [21:44:40:923]: Windows Installer removed the product; Product Name: Microsoft OLE DB Provider for DB2 Product Version: 8.0.4294.0. Product Language: 1033. Manufacturer:Microsoft.Removal success or error status: 1603
As I mentioned earlier the error messages are strange and generic and googling did not help to resolve this particular issue. After this article it may help though 😉
In our case what worked was voiding the existing version of DB2 by changing the registry settings.
Please be careful and make sure to take a backup of your registry settings before following the below mentioned steps.
Steps to Rename The Registry Settings For Existing Version of DB2:
Go to the path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Sna Server and rename “Sna Server” to “_Sna Server” as shown in the following screen shot:
Similarly make the following changes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\_Host Integration Server
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ _Sna Server
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\ _Host Integration Server
Than go to the Program Files Directory and for the Microsoft OLEDB Driver for DB2 and just put an (Underscore) in front of the directory name.
You may be thinking why only (Underscore), you can put anything meaningful like “DB2V3_Old”. It’ll work, but if you put symbol it’ll appear at the top and easy to identify what you have changed or for future reference.
I am leaving that decision up to you. The below screen shot shows how it looks in the registry after renaming:
Once you are done with all the changes your new install should work.
Programs and features looks like both the versions stays happily:
This article is about how to download OLE DB Provider for DB2. This is a Microsoft Data Provider which offers tools and technologies using which SQL Server can access DB2 Databases.
The requirement was just to install DB2 driver and so change time was kept minimal. But I had to spend more than an hour just to find the required file in Microsoft Site. So this five minutes read can save your lot of time.
You may give it a try to search it yourself before reading this article and will get you know why simple things are not always easy.
If you are in the middle of change like me and your search engine lands you here then you can directly go to the end of this article where I have provided direct links to download. Later you can come back and continue to read.
The following instructions are listed in Microsoft Document. This example shows the download of OLE DB Provider for DB2 Version 5.
To Install the Product:
Go to the Microsoft Download Center.
Download either the x86 (32-bit) or the x64 (64-bit) version of DB2OLEDB5_x64.msi installation program.
Double-click the .msi file to start the Installation Wizard
Click Next to get started.
License Agreement page, review the license terms, click the I accept the terms in the license agreement option, and then click Next.
Registration Information page, enter your Name and Company, and then click Next.
Feature Selection page, optionally click Browse to change the Folder name in which to install the product, optionally click Disk Cost to space required to install the product, and then click Next.
Ready to Install the Program page, click Install.
When prompted by Windows User Account Control, click Yes.
On the Installing page, view the status of the installation process.
On the Completion page, click Finish.
Install looks like a cakewalk until you pass the very 1st step.
Once you go to Microsoft Download Center:
Wow! Now what? Which option to choose or what should you search for?
Right here I wasted a lot of time. What you should search for is Feature Packs of SQL Server Version for which you want to install the OLE DB provider for DB2.
Choose the link showing Feature Pack as shown below:
You will get the download option as shown:
Click on Download and you get the options of DB2OLEDB5_x64.msi file to choose from:
Select the checkbox for DB2 and click on Next and the download process should start.
For SQL Server 2012 and prior versions you need to expand Install Instructions:
Then search for DB2 keyword and you will get the option to download:
Hope this is useful and please let me know by your valuable comments.
First of all let me explain you why you need to know the user defined profiler template location.
In situations you may need to define a template and share it with other DBAs to run or vice versa. You have saved the profiler and request the other person to run by providing the name of the profiler. The other person called you (when you are not in shift) since he/she is not able to find the profiler you created, but that is hard for you to believe as you are quite sure you did it right.
Once you go through this article you will get to know:
How to create a user defined template?
Why others are not able to see the template?
How to resolve this?
You can watch the following video demo which shows the stuffs I am going to explain here:
1. How to create a user defined template?
Launch SQL Server Management Studio (SSMS) and open SQL Server profiler:
Open a new Template:
Provide a template name and choose a base template from the drop down menu. In the below example I have chosen Standard (default) template. Then click on Events Selection tab.
In the above example I have not selected the check box for “Use as a default template for selected server type”. You can choose this option if you want your template to be default template.
Choose the Events as per your requirement. Click on “Show all events” and “Show all columns” to view all the events and columns to choose from. Then click on “Column Filters” to put filter for the trace.
In the below example I have put a filter for database id since I wanted to capture the transactions only for one database. The filter may differ for your requirement.
Once you are done with the filter selection click on OK and then Save the template.
Now if you go back and check the drop down list of templates you will find your custom template.
Go to File > New Trace and then connect to any SQL Instance
The following screen shot shows the newly created template “Demo Template (user)” in the drop down list.
2. Why others can’t see this template under the same drop down?
Here is the physical location of the user defined template file:
The main point to note here is the template gets created under the user profile folder of the login id, used to login to the server and that is why it is not visible to others.
AppData is a hidden folder and 11.0 and 110 will change depending upon the SQL Server version.
3. How to resolve this?
Let’s see the location of SQL Server Provided profiler templates.
You guessed it right! You just need to copy the user defined template from
C:\Users\UserName\AppData\Roaming\Microsoft\SQL Profiler\11.0\Templates\Microsoft SQL Server\110
C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Profiler\Templates\Microsoft SQL Server\110
Hope you enjoyed this article and feel free to share if you think it is helpful. Please let me know if you have any questions on this.
You may have come across situations where SQL Server cluster instance has failed over from one node to other and you were asked to find the SQL Cluster Instance failover time and node name prior to failover.
Who can ask this question? Your approver, manager or colleague anyone can ask you for different reasons, to know since when the instance is running on wrong/passive node, what alert system you have and it worked properly or not etc.
Whatever may be the reason, you want to find it quickly. In this article I am going to explain how to find the required information from SQL error log.
You need to search for the messages containing the text NETBIOS in the error log files.
Launch SSMS (SQL Server Management Studio) and start with the first error log to view as shown below:
Click on Filter and type in “netbios” against the field “Message Contains Text”. Mark the check box for Apply filter and click on OK as shown below. The message you are searching for, can be typed in Capital/Lower case.
Start checking each error logs until you find the required information as shown in the following screen shot.
The Message is like:
“The NETBIOS name of the local node that is running the server is ‘NodeName’. This is an informational message only. No user action is required.”
The message provides the information about the current Node, hosting the SQL Server Instance and the time it came up on the Node. Hence you need to keep checking the prior error logs which will show a different Node name and time in case it failed over from other node.
In the above example it shows the particular SQL Instance was running on Node “N02” prior to the failover.
The following information you can find using the NETBIOS filter:
What is the current node? (N01)
Is failover happened? Yes, as it shows a different node (N02) in prior error log file.
Which node it was running prior to failover?(N02)
What time failover started (Between 9/9/2017 11:28:10 PM the instance was on N02 and 9/9/2017 11:47:07 PM the instance started on No1. Check the error log around the time removing the filter and you will be able to find the exact time as shown in the below screen shot.)
You can also find what time SQL Instance came online/ what is the last SQL restart time. Of course you can find it from tempdb creation time? (Date 9/9/2017 11:47:07 PM the instance started on No1).
Hope this helps and I would like to hear from you if you have any other ways to find the same information quickly.
I got a call in the middle of the night about all the logins in SQL Server has been disabled. Logon failed due to trigger execution. The situation is quite scary, isn’t it? Well if you know what to do, then it is not except from the fact that you have to login in odd hours.
At first try to connect to the SQL Instance to find out the error:
The error message says “Logon failed for Login ‘sa’ due to trigger execution”. The second and third line of the error is little misleading.
It indicates that there must be a server level trigger someone has created due to which all the logins got disabled. The solution would be, find out the problem trigger and disable it. But you need to find out a way to get in to SQL Instance first.
You guessed it right! You need to use DAC (Dedicated Admin Connection) to connect in this situation. If you have not read the article where I have explained different ways to enable and connect using DAC click the following link.
Here I am going to show using command prompt. In the video link given at the end of the article, I have demonstrated using SSMS.
Open command prompt and use DAC to connect to the instance. In the below screen shot I am connecting to default instance using windows authentication and then run the below query:
SELECT name, create_date FROM MASTER.sys.server_triggers ORDER BY create_date DESC
As shown in the above example the trigger name is “TestLogin” and if you have observed I have used order by create_date desc, this is because after the latest trigger creation, nobody is able to login.
Now you can disable the trigger using the below query:
disable TRIGGER [TestLogin] ON ALL server
Once the trigger is disabled you will be able to connect to your SQL Instance. You can script out the trigger to check and rectify it.
If you can play sound, go ahead and watch the demo to fix the issue using SSMS:
I hope this helps. I would love to hear from you about any other similar issue or if you have any questions.
You may want to delete that extra Tempdb data file which someone created by mistake or to accommodate a query. Whatever may be the reason, today I am going to show you how to do it and what issues you may face.
You can run the below query to remove the data file:
ALTER DATABASE tempdb REMOVE FILE LogicalFileName; GO
Or you can use GUI:
SQL Server throws the following error:
The error message says that it cannot remove the file because it is not empty.
If you just add a file and there is no ongoing activity in the file then it would allow to remove the file this way.
For each file you want to remove, you need to run the following command to empty the file and then run the above query to remove the file:
USE [tempdb]; GO DBCC SHRINKFILE (LogicalName, EMPTYFILE); GO
But what if it throws the below error:
The error message is about a work table page which can not be removed. Work table is related to cached information, which indicates that you need to clear the cache.
Execute the below queries one by one and after clearing each, try to empty the file again:
DBCC DROPCLEANBUFFERS GO DBCC FREEPROCCACHE GO DBCC FREESESSIONCACHE GO DBCC FREESYSTEMCACHE ('ALL') GO
The successful run shows as below:
Please keep in mind that whenever you are clearing cache, it can cause performance issues. I am leaving the decision up to you to handle the risk factor according to the environment.
If your environment allows you to restart SQL Service you can just restart which will empty the tempdb files and you can run the remove command: