Server: Msg 7391, Level 16, State 1, Line 2

Problem Symtomps
The operation could not be performed because the OLE DB provider 'SQLOLEDB' was unable to begin a distributed transaction. OLE/DB provider returned message: New transaction cannot enlist in the specified transaction coordinator.

Cause
The problem occurs because Microsoft Distributed Transaction Coordinator (MS DTC) is not configured for network access. By default, the network access settings of MS DTC are disabled on new installations of SQL Server 2000 on computers that are running Windows Server 2003.
Resolution

Step 1: Open Component Services Wizard using below steps
Go to -> Start -> All Programs -> Administrative Tools -> Component Services

Step 2: Expand the Componenet Service and Double Click on Computers

Step 3: Right Click on MyCompute and select properties

Step 4: Click on MSDTC Tab and then click on Security Configuration

Step 5: In the Security Configuration dialog box, check the Network DTC Access check box

Step 6: Under  Network DTC Access, click on New transaction

 Please find the below images for the same.



Figure 2



Figure 3

Error: 18456, Severity: 14, State: 16

Error: 18456, Severity: 14, State: 16

Description State=16 means that the incoming user does not have permissions to log into the target database.  This can also happen if for example the default database for user is not online (for example the database is marked suspect or it is in restoring more).

Resolution

You can try all below different solutions to resolve the issue. As SQL Server 2005/2008 is not giving the reason for the login failure.

Thanks to SQL Server 2011 where it is stating the reason as well for the login failure.

Trouble shoot the suspect database issue or bring the database online or give the appropriate permission to user.

There may be case where default database is renamed, check that login is pointing correct database as default database.

Un-checked the auto-close connection from database properties.

If login is trying to open the database explicitly, check no job is running on that database which has opened it already explicitly.

Check if the login has appropriate permission on SQL Server and database.

Make sure Login credential is not expired.

There may be case where windows login re-created, drop the login from SQL Server and create it again.

 

Insert Extended Character using OSQL Utility

Problem: OSQL utility uses ODBC to communicate with the server. User’s problem is that the ODBC driver he is using to connect to the database is performing translations on the character data in the T-SQL script. Extended characters, which are not in the standard ASCII character set, are translated by the driver based on drive settings. The character translation option is ON by default when SQL Server executes scripts through the OSQL utility. 

Below query is inserting garbage data in the table. 

CREATE TABLE #temp(col1 varchar(40) NOT NULL )

INSERT INTO #temp VALUES( 'Tëst' )

SELECT col1 FROM #temp

DROP TABLE #temp 

Solution: By using Unicode script files and converting the column to Unicode, user can avoid the character translation. For that user needs to add N against the column, which is already added. 

Save As below script file as UNICODE file 

CREATE TABLE #temp(col1 varchar(40) NOT NULL )

INSERT INTO #temp VALUES( 'Tëst' )

SELECT col1 FROM #temp

DROP TABLE #temp 

User needs to do the following with the ODBC DSN to execute the scripts successfully, without any translation:

1.    Create an ODBC system data source called MyDSN on the machine where he is executing OSQL with the "Perform translation for character data" option cleared

2.    Specify this data source name as a parameter to OSQL so that OSQL can read the DSN settings and use them upon connection to SQL Server. 

osql -S. -itest.sql –DMyDSN

OR

User needs to develop a script which can pass the ASCII value 

Select ASCII(‘ë’)

INSERT INTO #temp (Col1) Select ‘T’ + chr(233) +  'st'

Msg 15410, Level 11, State 1

Error:
Msg 15410, Level 11, State 1, Server Server\INST2, Procedure
sp_addrolemember, Line 75
User or role 'mydomain\JShah' does not exist in this database.

Cause
Login already has an account under a different user name on particular database. For example mydomain\JShah user is mapped to database as user name jshah

Solution
ALTER USER [jshah] WITH NAME=[mydomain\jshah]
execute sp_AddRoleMember 'DBRole','mydomain\jshah'

OR
We can pass the actual user name
execute sp_AddRoleMember 'DBRole','jshah'

Msg 15063, Level 16, State 1

Error:
Msg 15063, Level 16, State 1, Server DBServerName, Line 1
The login already has an account under a different user name.

Cause
Login already has an account under a different user name on particular database.

User is executing sp_GrantDBAccess.  sp_GrantDBAccess system stored procedure adds a security account in the current database for a Microsoft SQL Server login or Microsoft Windows NT user or group, and enables it to be granted permissions to perform activities in the database.
But the login already has an account under a different user name on current database. That’s why the it is throwing an error.
 
Solution
Instead of using sp_GrantDBAccess user has to execute below query
ALTER AUTHORIZATION ON SCHEMA::[db_accessadmin] TO [GMO\service-ueagle]

Troubleshoot Blocking

Troubleshooting Blocking 

What is blocking? Blocking occurs when one connection to SQL Server locks one or more records, and a second connection to SQL Server requires a conflicting lock type on the record or records locked by the first connection. This causes the second connection to wait until the first connection releases its locks. By default, a connection will wait an unlimited amount of time for the blocking lock to go away. Blocking is not the same thing as a deadlock. 

How to avoid blocking

1. Keep transaction as short as possible


2. Use locking hints


3. Follow best practices for Database Maintenance regularly


4. Improve Query performance so it executes in seconds

Note:

By default, blocking locks do not time out.You can set blocking timeout using below SET statement.

SET LOCK_TIMEOUT timeoutPeriod

 How to find blocking

1. SP_WHO2 and find the blkby column from output for blocking details


2. Use SP_Lock to find out lock acquired by blocking query


3. Select * from sysprocesses where blocked <>0


4. You can get the blocking SQL Statement using DBCC INPUTBUFFER(SPID)


5. SP_WHO2 SPID

kernel udopen: operating system error 2 in SQL Server 6.5

One of my blog reader encountered below error, I have given him the below solution which has resolved this issue.

Error: (SQL Server 6.5)

2009/07/15 19:42:26.89 spid1    Activating disk 'ITEMPRICE_DATA1'

2009/07/15 19:42:26.89 kernel   udopen: operating system error 2(The system cannot find the file specified.) during the creation/opening of physical device F:\DATA\ITEMPRICE_DATA1.DAT

2009/07/15 19:42:26.89 kernel   udactivate (primary): failed to open device F:\DATA\ITEMPRICE_DATA1.DAT for vdn 42

2009/07/15 19:42:26.89 spid1    Activating disk 'ITEMPRICE_DATA2'

2009/07/15 19:42:26.89 kernel   udopen: operating system error 2(The system cannot find the file specified.) during the creation/opening of physical device F:\DATA\ITEMPRICE_DATA2.DAT

2009/07/15 19:42:26.89 kernel   udactivate (primary): failed to open device F:\DATA\ITEMPRICE_DATA2.DAT for vdn 43

Solution

1) Rebuilding System Databases by running setup again from the SQL Server Install CD and do a rebuild master.

2) If it's a 6.5 box, you can go to the console and view the sa password in the registry. run regedit from the console:
HKEY_CURRENT_USER
Software
Microsoft
MSSQLServer
SQLEW
Registered
SQL 6.5
ServerName

3) Check for the directory whether F:\ has Data directory or not

4) Check if the drive was corrupted

4) Check the SQL Server Service running on which account, check the permission of that account

5) http://support.microsoft.com/kb/180500

6) http://support.microsoft.com/kb/236989

7) Go through BOL on SQL Server 6.5 startup parameters

8) Try to login using command prompt and execute Sp_Resetstatus, DBCC CheckDB etc

sqlservr -c -f -T3608 -T4022

9) Check all the databases status from sysdatabases

 

How to find database restore history from MSDB?

You can use the below query to get the particular database restore history. 

  



SELECT TOP 10 *

FROM restorehistory WITH (nolock)WHERE (destination_database_name = 'Database Name')ORDER BY restore_date DESC

All Databases

SELECT TOP 10 * FROM restorehistory WITH (nolock)ORDER BY restore_date DESC

How to improve communication skills & Support Service

As DBA comes under the support industry, it is extremely important for DBAs to improve communication skills. As we are working production servers and backend, it is extremely important for us to communicate properly. 

• Please take care of the below points to improve your written communication skill. 


•  When you reply all, make sure to move names from TO to CC and CC to TO list according to whom you are writing emails

• Be concise and to the point. Use simple English.


• Avoid the use of slang words/abbreviations


• Use proper spelling, grammar & punctuation


• Do not write in CAPITALS. CAPITALS indicate that we are shouting.


• Numbers should be expressed as words when the number is less than 10 or is used to start a sentence (example: Ten years ago, my brother and I…). The number 10, or anything greater than 10, should be expressed as a figure (example: My brother has 13 Matchbox cars.)


• You should just mention the name instead of Hi Jugal.As we are working as support team, use `We` instead of `I`. For example; Jugal instead of Hi Jugal


• You should change the text in the Subject line during reply emails if it is not relevant.


• If you are asking for something in the email, you should ask them first and then mention why you need that.

• Don’t write open ended email to user


• If you are not sure for any support request, please ask end user for more inputs on particular request.


• Inform your team regarding any conversation with client through chat or voice call


• Update your work log every day


• If you are not sure for any resolution steps, discuss it with your team and then provide it to client


• When sending large attachments, always "zip" or compress them before sending.


• Always include subject in your mail body.


• Don’t send email to any account using your client account


• Discuss as much as possible with your client


• Grab as much as possible knowledge of the client process/environment