Friday, July 3, 2020

Wait Types in SQL Server

Often we we get in a scenario where Application team knocks our door complaining slow processing of data causing delay to the scheduled processes and first reaction a DBA provides is checking running processes and blocking if any on the server. Many a times blocking is a culprit which keeps system busy and processes halted but many a time there is another thing which we need to check and that is checking wait types on the server.

There are many wait types which and we need to know their meaning so I would like to focus on that point today.

Common Wait Types in SQL Server

ASYNC_NETWORK_IO—This wait types points towards a possible network-related issue and most-often caused by a client application not consuming and processing results efficiently from the SQL Server and causing delays. In this wait type SQL is helpless as nothing can be done from SQL Server point of view. We have to escalate and engage the network team if there’s a long distance between servers or the application team to check on application/server resources.

CXPACKETCXPACKET wait type is one of the most misinterpreted wait stats. The CXPACKET means Class Exchange Packet and in its essence, this can be described as data rows exchanged among two parallel threads that are the part of a single process. One thread is the “producer thread” and another thread is the “consumer thread”. This wait type is directly related to parallelism and it occurs in SQL Server whenever SQL Server executes a query using parallel plan.

This CXPACKET wait type is normal for SQL Server and it is an indicator that SQL Server is using a parallel plan in executing a query, which is generally faster comparing to a query executed in a serialized process. When the parallel plan is used, the query is executed in multiple threads and the query can continue only when all parallel threads are completed. This mean that query will be as fast as the slowest thread. Look at researching and changing Maximum Degree of Parallelism (MAXDOP).

DTC—This wait type is not on the local system. When using Microsoft Distributed Transaction Coordinator (MS-DTC), a single transaction is opened on multiple systems at the same time, and the transaction cannot be concluded until it’s been completed on all of the systems. This wait type accumulates while SQL Server is waiting for the Distributed Transaction Co-Ordinator (DTC) to access the internal service global state object. Distributed transactions run across multiple database instances and sometimes other platforms like Oracle. This wait type is uncommon and if values are excessive then further investigation is required

LCK_M*—This wait type happens when a query locks an object while another query is waiting to lock the same object. A common scenario is when a query is trying to modify a row while another query is trying to read the same row. Review the day and time the locking occurred and which SQL statements were being executed. This wait occurs when a request is waiting to acquire a shared lock. This typically happens when read requests are blocked by write transactions (implicit or explicit) that have been kept open for extended periods of time. Tuning these statements will reduce the session holds on the locks.

NETWORKIOThis wait indicates that one of two scenarios are happening. The first scenario is that the session (i.e., SPID) is waiting for the client application to process the result set and send a signal back to SQL Server that it is ready to process more data. The second is that there may be a network performance issue.

OLEDB—This wait type indicates that a SPID has made a function call to an OLE DB provider and is waiting for the function to return the required data. This wait type may also indicate the SPID is waiting for remote procedure calls, linked server queries, BULK INSERT commands, or full-search queries.

PAGEIOLATCH_*— This wait type occurs when a task is waiting on a latch for a buffer that is in an I/O request. The latch request is in Shared mode. Long waits may indicate problems with the disk subsystem. Buffer latches, including the PAGEIOLATCH_EX wait type, are used to synchronize access to BUF structures and associated pages in the SQL Server database. The most frequently occurring buffer latching situation is when SQL Server is waiting to read a data file page or workload from storage. These pages and workloads were not cached in memory and need to be retrieved from the disk. Additional memory will help prevent pages from getting pushed out.

SOS_SCHEDULER_YIELD—SQL Server instances with high CPU usage often show the SOS_SCHEDULER_YIELD wait type. This doesn’t mean the server is underpowered; it means further research is needed to find which individual task in a query needs more CPU time. Check the Max Degree of Parallelism (MAXDOP) to ensure proper core usage. Ensure high CPU performance from both within Windows and the system BIOS.

WRITELOG—When a SQL Server session waits on the WRITELOG wait type, it’s waiting to write the contents of the log cache (user delete/update/inserts operations) to the disk where the transaction log is stored and before telling the end user his or her transactions have been committed. Disabling unused indexes will help, but the disk is the bottleneck here, and the transition log should be moved to more appropriate storage.

Tuesday, June 30, 2020

SSIS package fails from sql job but succeeds from development studio

Recently I was debugging a issue which many of you might have faced and even may have fixed but still I thought to share it on an open portal so in case if someone is still looking for solution or yet stuck in this then he can get benefited from this piece.

Issue observed was that the a SSIS package was working fine in business development studio but the same package was not working via SQL agent job and throwing misleading message pointing towards connection issue. In case if package has connection to other databases like DB2, Oracle or MYSQL then the situation becomes more worse and confusing.

Below is the sample of the error message,

******************************************************************
Description: Failed to decrypt protected XML node "DTS:Password" with error 0x8009000B "Key not valid for use in specified state.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available.
End Error

An OLE DB record is available.  Source: "Microsoft DB2 OLE DB Provider"  Hresult: 0x80040E14  Description: "An internal network library error has occurred. A network level syntax error has occurred.".

Description: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.  The AcquireConnection method call to the connection manager "XXXXXXXX" failed with error code 0xC0202009.  There may be error messages posted before this with more information on why the AcquireConnection method call failed.
******************************************************************

Here in this error message SQL is trying to point that there is some issue with connection but unable to tell exactly where to check and even none of the blogs I visited were even roaming around this. Many blogs suggested that I should change executing user to SQL proxy with appropriate permission etc etc but no exact help or fix provided.

While debugging with my colleague we started digging this up and after the long hunt we found a solution which made my day. Basically when we define a connection via connection manager in package and SSIS package would use it for execution but when we point the same SSIS package through SQL jobs it shows us multiple tabs in job step among which we have to click on the "Data Sources" tab and put the correct password in our desired connection string and save the changes. 

In case if you again wish to make even a small change to same job without touching SSIS package step, again put the password and save it because once you edit the step and save it SQL agent hides the password and remains invisible to users. If we again click on save even without making any changes to job step or package, password disappears and users have to put that password manually.


This sounds something strange but this is for the security so any random user having access to sql jobs does not see password easily and password remains safe.

Hope this fixes your issues. 


Please try this and share the feedback whether this fixed your issue or not of if something else needs to be added in this to make it more easy to understand.

Thursday, April 23, 2020

The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine


Hello Techies,

While working on SQL import wizard using excel with (.xlsx) extension my client started experiencing issues with the below mentioned issue. Surprisingly he was not encountering any issue while working with .xls or .csv file 

---------------------------------------------------------------------
TITLE: SQL Server Import and Export Wizard
---------------------------------------------------------------------

The operation could not be completed.

---------------------------------------------------------------------
ADDITIONAL INFORMATION:

The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. (System.Data)
---------------------------------------------------------------------


While working on this to find solution I found many websites claiming many solutions which provided and their own experiences but again digging this more I came to know that Excel 2010 driver is 64 bit but by default SSMS import export wizard is 32 therefore the error message appears.

To fix this issue you can import using the Import Export Data (64 bit) tool for trial.

Depending on SQL Binary location

You can find your binary location doing below steps,

Right click on Instance name --> Root Directory

This value shown on the right hand side shows your SQL installation folder so access the "DTSWizard.exe" application.

“C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTSWizard.exe” 


I hope you were able to proceed with the import export wizard 😊 and to fix this permanently you should copy the “DTSWizard.exe” 64 bit file from the below location to x86 folder with replace option.

Note: Its always good to copy the file to be replaced to be on safer side to some other location.

Source
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\DTSWizard.exe

Destination
C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTSWizard.exe



Hope this fixed your issue so please help me with your feedback to encourage me writing further sharing my experience.