Login Failed – Error: 18456, Severity: 14, State: 38

Reason: Failed to Open the Explicitly Specified Database

Fix Error “Failed to Open the Explicitly Specified Database”

The error log is saying “Failed to Open the Explicitly Specified Database“, it means either your have specified wrong database in your connection string or your login does not have access to the specified database. You can validate below options to isolate this issue.

• Check whether you have specified correct database in your connection string or not
• If you are using correct database then whether the login you are using to establish database connection has access to this specified database or not.
• Correct if you find something in any of the above two options.
• Check login properties whether it is using correct database as default database configuration or not. If correct database is defined then login has access to that database or not. I will explain about this step in below section as well.
• You should also check whether number of connections to the database is exhausted or not. Review your maximum number of connections setting.
• Ensure your database is not set to AUTO CLOSE setting or not inaccessible. Database should be online and healthy state to accept connections.
• Make sure you have a trust between both machines, database server and the machine from where you are trying to connect. I would suggest you to read below article as well where i have explained various steps to troubleshoot SQL Server connection issues.

Read more articles on SQL error 18456 and connection issues:

• How to Fix SQL Server Error 18456: A Comprehensive Guide
• How to fix SQL Server error 53 – Not able to open database connection
• Fix SQL Server error 18456 – Login failed for user

Let’s learn how to check default database settings for a SQL Server login and a user mapping for any database to the login.

Check Login Properties

The solution to fix this issue can also come by reviewing the properties of this login. Launch its properties window and change the default database to the correct one if this setting is showing wrong database. Sometimes, we drop the databases from the SQL Server instances but never update other objects. If this login is not showing any database and it is showing blank then click at its drop-down to choose your desired database as the default database for this login. Click on Ok button to apply that change. You will stop getting this issue after making this change.

You can open login properties windows by right click at the identified login and then choose properties from dropdown options.

Sometimes, you have chosen the default database as “master” but your login doesn’t have connect permission on master database so ensure you have at least connect permission on the database which you are choosing as the default database for your login. You can click at “User Mapping” tab from left side pane of the login properties window. You will get all databases in top side of right side pane and level of access in bottom side pane. Click at your database from right side pane along with its level of permission which you want to assign. Click at Ok button to apply this change.

Have a look at below screenshot to understand default database of a login and from where you can access User Mapping tab to provide appropriate access to your database. Your login should have access to both databases, the one mentioned as default database for your login and the specified database in connection strings.

You can fix SQL error “Failed to Open the Explicitly Specified Database” by following above steps. Write your feedback if you have fixed this issue by other way. I will update this article accordingly with credits.

The post Fix SQL Error 18456: failed to open the explicitly specified database appeared first on Techyaz.com.

A transport-level error has occured when receiving results from the server. (provider: TCP Provider, error: 0 – The semaphore timeout period has expired.) (Microsoft SQL Server, Error:121)

This was an intermittent issue and when we were executing the script from other server it was not throwing any issue. I did some research on this and found out that this error came because of unstable network connectivity.

SQL Server Error 121 The Semaphore Timeout Period Has Expired – Root Cause

There are various parameters that can affect network connectivity like network adaptors, packet drop, configured packet size etc. So i would suggest first you should connect to your network team and ask them to look into this issue. If network team has not found anything then you need to check application level network configurations at your level.

You should ask some questions to your network resource like whether any network packet drop being observed or not, or is there any NIC card issue etc. Let’s assume you have already reached out to network team and they haven’t found anything. I would suggest you to look into below options at your level to make sure everything is in place and not misconfigured.

• Check TCP\IP settings
• Ensure you have appropriate network packet size configured in SQL Server
• Make sure you have properly configured TCP Chimney Offload
• Validate you don’t have Network Interface Card (NIC) driver issue, you can get it checked with your network team

Solution

I have already described high level areas where you need to look in in above section. Let’s discuss them further here.

Check TCP\IP settings

You should open SQL Server configuration manager and check whether TCP configuration is properly done or not. Make sure to review all settings in SQL Server Network configuration settings. You should also read below article about this settings which causes a network error.

• Fix: SQL Network Interfaces Error 28 – Server doesn’t support requested protocol

Review Network Packet Size

You should also review network packet size configuration in SQL Server. This could be one of the possible reason for this issue. Ideally we should not change the default value of this setting and keep it as it is until you have a specific requirement to change network packet size. Read below article to understand and learn network packet size in SQL Server and also step by step process about how to change the network packet size to your desired value.

• How to Change Network Packet Size Configuration in SQL Server

TCP Chimney Offload

This settings is very important if we have network related connectivity issue. TCP Chimney Offload is a networking technology that helps transfer the workload from the CPU to a network adapter during network data transfer. It can be enabled or disabled in the following two locations:

• The operating system
• The advanced properties page of the network adapter

TCP Chimney Offload will work only if it is enabled in both locations. By default, TCP Chimney Offload is disabled in both these locations. However, OEM installations may enable TCP Chimney Offload in the operating system, in the network adapter, or in both the operating system and the network adapter.

Validate Network related Driver Issues

You should speak to your network resource and Windows OS platform resource and validate all drivers at OS layer and network layer should be up to date and they should not have any issue. Make sure to update the drivers if you found any issue any of these layer.

I hope you can fix your issue by following above steps mentioned in this article. Comment us how you have fixed this issue, the semaphore timeout period has expired.) (Microsoft SQL Server, Error:121)

Related Articles

• SQL Server Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server.
• Fix Error 1418: The server network address cannot be reached or does not exist.
• Fix: SQL Network Interfaces Error 28 – Server doesn’t support requested protocol
• SQL Server Native Client Error 50000: A network error occurred while attempting to read from the file

The post Fix SQL Server Error 121 – The Semaphore Timeout Period Has Expired appeared first on Techyaz.com.

SQLServer Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

SQL Server Error 802 – Insufficient Memory Available in the Buffer Pool

The main reason behind getting SQL Server error 802 is your SQL Server instance is under memory pressure and there is not enough memory available to allocate further to buffer pool or buffer pool is restricted to not use memory beyond a certain limit. This might be because of various reasons as i have stated in below section. One of the very easy and straight forward approach to fix this error is to increase more memory to SQL Server system and modify max server memory in SQL Server accordingly.

Analysis & Solution

I would suggest to go deeper in this issue before taking any decision to allocate more memory to the system where SQL Server is running. There could be multiple temporary reasons as well which can cause SQL Server to generate below error log:

SQL Server Error: 802, There is insufficient memory available in the buffer pool. [SQLSTATE 42000]

Let’s discuss this issue further and ensure to not forget below points before taking any decisions.

Please comment us about your issue experience and let me know how you have fixed your issue.

Related Articles:

• How to Fix SQL Server Error 701: There is insufficient system memory to run this query
• Understanding Hybrid Buffer Pool in SQL Server
• SQL Server Interview Questions & Answers

The post Fix SQL Server Error 802: There is insufficient memory available in the buffer pool. appeared first on Techyaz.com.

VIEW SERVER STATE Permission

This is high level server-level privilege which must not be granted to everybody. Only administrators must have privilege to use view server state permission but we can assign this permission to some users who want to see server level state of your SQL Server instance. Once you will grant this access to any login, he can see result of all DMVs.

Solution – ( Microsoft SQL Server, Error 300 )

We got SQL Server error 300 ( VIEW SERVER STATE permission was denied ) because the login you are using to execute the script doesn’t have this permission. To fix this issue we will grant view server state permission to the login name. This section will explain how to grant view server state permission to a login.

Grant VIEW SERVER STATE Permission

We can assign this permission either using GUI in SQL Server Management Studio or we can simply execute a T-SQL command to get this done. I will explain both ways to assign this permission.

Using GUI in SQL Server Management Studio

Follow below steps to do it using GUI.

1. Launch SQL Server Management Studio.
2. Connect to the SQL Server Instance.
3. Navigate to Security folder then expand Logins
4. Right Click at your login name and choose Properties
5. Click at Securables tab from left side pane.
6. In the bottom pane, scroll to the bottom and click at Grant option for View Server State value.
7. Now click on apply to close the window. You can now ask your user to test the script again. This time it will work.

Using T-SQL statement in SQL Server Management Studio

1. Launch SQL Server Management Studio. Connect to the SQL Server Instance.
2. Open New Query window
3. Run below T-SQL statement

USE master
GO
GRANT VIEW SERVER STATE TO "LoginName"

Once you execute above command, you will have view server state permission on your login name. You can resolve SQL Server error 300 VIEW SERVER STATE permission was denied on object ‘server’, database ‘master issue by following above steps given in this article.

Revoke VIEW SERVER STATE Permission

If you have identified anyone who must not have this permission then you can go ahead and revoke his access post getting proper approvals. Make sure that identified login does not have any business justification before revoking his access. Once you have decided to go ahead to remove view server state permission then you should run below T-SQL statement to get this done. Below steps will tell you how to revoke view server state permission of any login.

USE master

REVOKE VIEW SERVER STATE TO “LoginName”

GO

View SERVER STATE permission has been revoked for identified login post successful execution of above statement.

I hope you like this article. Please follow our facebook page and Twitter handle to get latest updates.

Read More:

• SQL Server AlwaysON Interview Questions & Answers
• SQL Server DBA Interview Questions & Answers
• Understanding Enhanced Database Failover in Always on Availability Group
• SQL Server Replication Interview Questions & Answers

The post Fix:VIEW SERVER STATE permission was denied on object ‘server’, database ‘master’ appeared first on Techyaz.com.

SQL Server Native Client Error 50000

Before explaining about SQL native client error 50000, i would like to describe about what is SQL Server native client. As per MSDN “SQL Server Native Client, is a term that has been used interchangeably to refer to ODBC and OLE DB drivers for SQL Server.” 

SQL Server Native Client is a technology that we can use to access data in a SQL Server database. There are several factors you should consider while deciding whether to use SQL Server Native client or some other data access technology. You can read attached article about when to use SQL Server Native Client.

Generally, we get SQL Server native client error 50000 while installing or updating native client software or a software component that uses SQL Server Native Client and your target machine already have this installed previously using some msi file.

You can also get this issue if SQL Server native client file sqlncli.msi has been renamed after its installation and later today when you are trying to update it, you will end up with this SQL error 50000 . If somehow native client installation file has been renamed on your machine, setup will not find its file to update SQL Server native client and through below error.

A network error occurred while attempting to read from the file <Filename>.”

Solution

To fix this error, you should uninstall installed version of SQL Server native client from add/remove program and then you can try to install SQL Server or its component again. This time you will not get any error and your software or native client will be installed. To avoid further issue, you can reboot the machine post uninstalling the native client tool.

If you are installing only SQL Server native client and not SQL Server then you can download it from Microsoft website and then reinstall it again.

You can also prevent this error to not generate in future by not installing it using its msi file sqlncli.msi. If you had installed it using this file, make sure to never rename it as well.

Here, I have shown you how to fix SQL Server Native Client Error 50000, “A network error occurred while attempting to read from the file <Filename>.”  I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix SQL Server Error 5009: One or more files listed in the statement could not be found or could not be initialized
• Fix SQL Server Installation Error: Attributes do not match
• How to Fix SQL Server Installation Error 1639?
• SQL Server DBA Interview Questions & Answers

The post SQL Server Native Client Error 50000: A network error occurred while attempting to read from the file appeared first on Techyaz.com.

Microsoft SQL Server Error 5009 While Adding Database File

I was working on a migration project where we had to load huge data in a SQL Server database on the target server. To optimize data load performance, we had decided to create database with the final size on the destination server. The final size of database post data import was around 800 GB. We made some configurational changes to reduce data import time. Extending database files size was one of the step to reduce data load time. If you want to learn how to speed up data import then I would suggest reading attached article.

We decided to add one more log file on separate drive considering extensive log growth during data load. While adding the log file, we got error 5009. Full error details are given below.

One or more files listed in the statement could not be found or could not be initialized. CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file ‘T:\Techyaz_log3.ldf’.(Microsoft SQL Server, Error: 5009)

As error suggests, I don’t had enough permission to create this file on given location where i was trying to create the log file. There are two solutions to fix this issue. First solution is to set the Operating system permission on the mentioned .ldf file to full permission for your login account and SQL Server service account. While second solution is to change the location to the path where you have enough permission to create or add database files. Any of these two solutions will fix your problem. Let’s go to another version of Microsoft SQL Server Error 5009 while extending the log file.

Microsoft SQL Server Error 5009 While Extending the Size of Log File

When i changed the location to create this ldf file to a directory T:\Data\Techyaz_log3.ldf this time log file was created but we get same issue again while extending the size of this log file. Next, I was assigning bigger value to each data and log files. We had successfully increased data files size in few minutes because we had already enabled Instant File Initialization to skip zeros process on storage but we faced Microsoft SQL Server error 5009 again while increasing the size of log files. i was extending  log file with bigger values. As we know Instant File Initialization does not work for transaction log files so extending the size of log files was taking lot of time. This time access denied issue was disappeared but error 5009 issue was there only. Error description for this error is given below.

Msg 5009, Level 16, State 9, Line 1
One or more files listed in the statement could not be found or could not be initialized.

To fix this error, we had passed small value to extend the file size. Earlier we were trying to increase the log file in a slot of 40 GB in single go. It was taking time to finish but most of time log file size got extended with 40GB but sometimes we had received above Microsoft SQL Server error 5009. When we got this error, we extend the size of log file to 10Gb in place of 40GB that we were doing previously. Reducing the value while extending the log file has fixed this issue and log files had been extended to its future size successfully.

Microsoft SQL Server Error 5009 While Removing Database File

Some of the blogs have suggested that they got SQL Server error 5009 while removing a logical file in SQL Server but surprisingly I got this error while creating or increasing the size of log file. So if you are getting this error while removing any database file then you can keep reading this article to solve this issue.

Whenever we add any database file then its entry got captured in system catalog files, if you are trying to delete any database file then there might be possibility that logical name of the file that you try to remove is not unique in the system catalog tables. For example, this issue occurs if the file existed in the database earlier, and then the file was removed. When you remove the file, it will try to drop earlier file that has been removed but its metadata is not cleaned and appear like ghost file.

You should follow below steps to fix this issue.

• Create a new logical file with different name and the same data type. For example, If your file;s logical name is Techyaz_Logical_Name then create this new file with “Techyaz_Logical_Name_New”. Run below command to create this file.

ALTER DATABASE [Techyaz] 
ADD FILE ( NAME = N'Techyaz_Logical_Name_New', FILENAME = N'T:\DATA\Techyaz_file4.ndf', SIZE = 10MB, MAXSIZE = 100MB)

• Now we will remove the logical file that we have created in step 1, as in the following example:

ALTER DATABASE [Techyaz] REMOVE FILE [Techyaz_Logical_Name_New]

• Run a transaction log backup of the database.
• Now go ahead and remove the logical file that were trying to remove earlier and your received Microsoft SQL Server Error 5009.

Here, I have described multiple possibilities and fixes for Microsoft SQL Server Error 5009. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Manage Transaction Log File during Data Load
• How to get total no of virtual log files in a transaction log file
• Fix Error 3023: Shrink failed for Log file
• Understanding SQL Server Transaction Log Architecture
• Fix SQL Server Error 1105: Could Not Allocate Space for Object in Database because the Filegroup is Full
• Fix SQl Server Error 5144 and 5145 for long and failed Autogrow of data and log file

The post SQL Server Error 5009: One or more files listed in the statement could not be found or could not be initialized appeared first on Techyaz.com.

I have already explained top performance counters to detect Memory and Disk IO bottlenecks in SQL Server in my last articles. Have a look at them (attached below) to get Memory and Disk IO related performance counters and their ideal values for healthy system.

• Top 10 Performance Counters to Identify SQL Server Memory Pressure
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Generally, CPU bottleneck arises because of either your system has not enough CPUs to process current workload or your transactions or applications are poorly designed that causes the high CPU. To deal with SQL Server CPU pressure, we need to either find the high CPU intensive queries and optimize them or increase the total CPU counts of the database server to handle current workload. There can be multiple reasons for high CPU usage like high recompilations of SQL Queries, OS issues, Query design issues: Sorting Joins, Poor Indexes, Condition Clauses etc. Here, I am going to explain about top perfmon counters to identify SQL Server CPU bottleneck.

Perfmon Counters for CPU Usage

Here, I am going to describe about perfmon counters for CPU usage in SQL Server. Ideally, first we should start with looking at CPU usage in Windows Task Manager. If the CPU utilization is continuously going beyond 85%, it means your system is facing CPU bottleneck. Find the list of performance counters to identify SQL Server CPU bottleneck.

Processor: % Processor Time 

One of the very useful CPU perfmon counter for SQL Server is Processor: % Processor Time. This counter displays the percentage of time CPU spends executing a thread that is not idle. If your system is frequently reaching beyond 85% then it means your system is facing CPU bottleneck. The acceptable value for this counter should be less than 50%.

Processor: % User Time

Windows operating system has two modes of processing for any process. One is Kernel mode another one is user mode. This counter shows the percentage of time a process spends executing user processes like SQL Server. If this counter is high it means CPU pressure is because of SQL Server or because of user applications. You should focus to retrieve CPU intensive queries to get the culprit transactions that are causing high CPU pressure. There is no idle value for this counter. You should benchmark each system based on your workload.

Processor: % Privilege Time

This counter shows the percentage of time the processor spends on execution of Microsoft Windows kernel commands, such as processing of SQL Server I/O requests. This counter captures the information about kernel mode and indicates towards poor performance of disk subsystems. Monitor DISK IO related performance counters to identify DISK IO bottleneck and if possible, consider installing a faster or more efficient disk subsystem.

Processor: % Interrupt Time

This counter Processor: % Interrupt Time tells about the time a processor spends receiving and servicing hardware interruptions during specific sample intervals. This counter indicates a possible hardware issue if the value is greater than 15 percent.

System: Processor Queue Length

This is an important perfmon counter to detect CPU bottleneck. This counter gives information about the number of threads waiting for processor time. If value of this counter is greater than zero then this is a sign of CPU bottleneck. We can further check Compilations/sec and Re-Compilations/sec. A high number of compilations and recompilations usually indicates poor reuse of the query plans. This can be fixed by optimizing your queries and stored procedures.

System: Calls/sec

Any system would have either software calls or application related calls or hardware related calls. This counter System: Calls/sec metric shows the number of software calls to the operating system service routines per second. Similarly, another CPU perform counter Processor: Interrupts/Sec shows the number of hardware calls to the processor. Both perfmon counters can be used to determine the source of the performance issues. The acceptable values for System: Calls/sec are under 20,000. Higher values might indicate excessive operating system activity caused by software applications.

Context Switches/sec

Context Switches occurs when kernel switches processor from one thread to another. The acceptable Context Switches/sec value should be less than 2,000 per processor. If you are observing constant high values of Context Switches/sec and Processor: % Processor Time on your system then this would be a clear sign of processor bottlenecks. Permanent solution to reduce CPU bottleneck is to change the processor to a more powerful one, or add an additional to existing ones.

You might have seen high Context Switches/sec values for systems that are running with multiple SQL Server instances or a system that is hosted other applications along with SQL Server.

Here I have described top perfmon counters for CPU usage on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding Database Shrink Operation and Why should you Avoid it?
• Fix Error 701: There is Insufficient System Memory to Run this Query
• How to Improve Bulk Data Load Performance?

The post Top Perfmon Counters to Identify SQL Server CPU Bottleneck appeared first on Techyaz.com.

• Fix SQL Server Error 701: There is Insufficient System Memory to Run this Query

We can use Windows PerfMon utility to gather current values of all given performance counters. Just type perfmon in run prompt to launch perfmon tool to gather memory related performance counters. Although, Microsoft has also given a DMV related to performance counters that is very useful in collecting data and detecting CPU, IO or memory bottleneck in SQL Server. You can run below command to get all performance counters and their respective values using DMV sys.dm_os_performance_counters. You can also use this DMV to get performance counter values to identify memory pressure in SQL Server.

Select * from sys.dm_os_performance_counters

By default, SQL Server changes its memory requirements dynamically, on the basis of available system resources. I have explained SQL Server Memory Management and how SQL Server allocated memory to their transactions in below attached article.

• SQL Server Memory Allocation & Role of MIN/MAX Server Memory Configuration

Performance Counters to Identify SQL Server Memory Pressure

Let’s discuss top perfmon counters for memory usages to identify its bottleneck. Below is the list of top 10 performance counters to identify SQL Server Memory pressure. If you want to read CPU and Disk IO related perfmon counters then i would suggest you to read below attached articles.

• Top Perfmon Counters to Identify SQL Server CPU Bottleneck
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

Memory: Available Bytes

First thing you should look at in case of memory bottleneck in SQL Server is the available memory that can be used by processes. You can get this value by looking at the counter Available Bytes under object Memory. Low value of this counter shows the memory shortage on this server.  Now, you should focus behind the reason of this memory shortage. There might be possibility that some of your applications running on your server are not releasing memory or your system has not enough memory to perform current workload that leads to the memory bottleneck in SQL Server.

Memory: Pages/sec

This counter indicates the total number of pages that are either read from disk or written to the disk due to page fault. When a process requests a data page that is not in memory then it will be retrieved from disk to memory. This process is known is page fault. High value of this counter could indicate the excessive paging. We should further monitor Memory: Page Faults/sec counter to go indepth information. The average Pages/sec value should be below 50. A high value of Pages/sec indicates intensive memory activities like read from and write to disk. It means transactions are getting enough memory that is why they are using disk to process their requests.

Memory: Page Faults/sec

High value of counter Memory: Pages/sec could indicate the excessive paging. Next, we should monitor the Memory: Page Faults/sec counter to make sure that the disk activity is not caused by paging. If you want to determine whether SQL Server or another process is causing excessive paging then we should monitor the Process: Page Faults/sec counter for the SQL Server process instance. This will give an exact picture whether SQL Server is causing this paging issue or not.

Process: Working Set

This counter shows the amount of memory a process can use. This counter value shows whether you have set optimum value in min server memory and max server memory configuration or not. If this value shows constantly below min server memory and max server memory then you have configured too much memory for your SQL Server.

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

This is very important counter and this counter shows the number of percentage that has been satisfied using data cache. Suppose the value of buffer cache hit ratio for your server is 94 it means 94% of total requests for data have been processed using data cache.

The ideal value for this counter is more than 90. Higher the value better the memory health.

SQL Server: Buffer Manager: Page Life Expectancy

Page Life Expectancy is very important counter to measure memory pressure for your system. THis counter indicates the average number of seconds a data page to remain in cache. Ideally, we have read multiple blogs to consider 300 or more as acceptable value but this value varies depending on your system configuration.

The ideal value is more than 300 but always compare this value with your system configuration. Higher the better concept is also applying here.

SQL Server: Buffer Manager: Free List Stalls/sec

This counter also shows a sign of memory pressure or insufficient memory on your server. This displays the number of requests per second where data requests stall because there are no buffers available. Any value greater than two indicates that SQL Server needs more memory.

SQL Server: Buffer Manager: Lazy Writes/sec

This counter tells about total number of Lazy writer performed in a second.  It means total number of times Lazy Writer process moves dirty pages from the buffer to disk. A lower number is better than a higher number. If value of this counter shows higher value continuously more than 20, then we need to add more memory to the system or we should think about optimizing memory intensive operations.

SQL Server: Buffer Manager: Checkpoint Pages/sec

This counter monitors the number of dirty pages per second, which are flushed to disk when SQL Server invokes the checkpoint process. High values for this counter may indicate memory pressure or insufficient memory.

SQL Server: Memory Manager: Memory Grants Pending

This counter shows the number of processes waiting for memory grant per second. Any value higher than zero indicates a lack of memory. We can also get this information by using a DMV sys.dm_exec_query_memory_grants. Those processes who are waiting to be granted the required memory will show you waiting with RESOURCE_SEMAPHORE wait type. I have explained about resource semaphore wait type in below attached article.

• Fix RESOURCE_SEMAPHORE Wait Type in SQL Server

Here, I have described top 10 performance counters to identify SQL Server memory pressure on your database server. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 833: SQL Server has encountered 32 occurrences of I/O requests taking longer than 15 seconds to complete.
• Disk and Performance Impact of running Online Index Rebuild Operation
• Understanding ASYNC_IO_COMPLETION Wait Type

The post Top 10 Performance Counters to Identify SQL Server Memory Pressure appeared first on Techyaz.com.

Error 701, Severity: 17, State: 193.
There is insufficient system memory to run this query.

Or

Error 802, Severity: 17, State: 20
There is insufficient memory available in the buffer pool.

Error 701 or Error 802: Root Cause

If SQL Server is running out of memory and has no more memory available to allocate to its transactions then it will generate SQL Server memory error 701 or error 802. SQL Server Memory pressure or insufficient memory issue can be raised due to huge data load or other memory intensive operations.

We should check DBCC MEMORYSTATUS output to get latest snapshot of current memory status of the SQL Server. This command is very useful in troubleshooting memory issues in SQL Server. You might even have failed to run this DBCC command because system does not have enough memory. You need to reduce some memory pressure by stopping or killing some processes and then try to run this command to gather in depth information about SQL Server memory state.

The transaction that failed due to memory pressure and generates error 701 or error 802 might be or might not be the cause of this error. We should analyze the trends to reach on any conclusion.

Solution

There are mainly two reasons behind getting SQL Server memory issues for most of the SQL Server systems. Either your server has less memory to handle the current day to day workload or you are running some of the adhoc transactions that will require more memory for their execution like huge bulk data load, complex reports etc. If your SQL Server is running with insufficient memory during day to day activities then you should seriously evaluate the total workload and propose optimum memory size that can handle your current workload.

If you are planning to run any heavy ad hoc transaction then you should temporary increase the memory that can handle the transaction smoothly or you should run such transactions on a server that are built to handle such loads. You should also consider to reduce the batch size that is optimum for your system.

SQL Server is memory intensive application. We need to plan memory sizing for a server after proper evaluation of server state and overall load that will run on that SQL Server instance. But if you are facing memory issue on one of your SQL Server then first we need to troubleshoot it and find the root cause of this memory pressure. Here I am giving you step by step method to find the actual culprit that are causing the memory issue and possible solutions that can reduce some memory overheads.

First Make sure your SQL Server instance is running on dedicated server and not with other applications. If other applications are also using your database server then make sure they are not eating most of the memory. And, If most of the system memory is taken by other applications then you need to seriously think about migrating those application from this database server.

If you cannot migrate these applications to another server then workaround for such issues are to allocate the maximum memory value to your SQL Server instance. You can do it either by using sp_configure or using GUI. Read attached article to change max memory value for your SQL Server instance.

• Understanding SQL Server Memory Allocation and Role of MIN/MAX Server Memory Configuration

Next thing you should check is the server memory configuration. Check below SQL Server memory configuration parameters:

• max server memory
• min server memory
• min memory per query

Notice any unusual settings and fix them as necessary. All above three options have been covered in detain in above attached article.

Now, check the workload in terms of number of concurrent sessions, currently executing queries along with their memory grants. You should also focus on SQL Server transactions that are seeking huge memory values. Look at the transactions and gather a report for high memory intensive operations. Evaluate them and if possible optimize them so that they can take minimum memory.

• Understanding Memory Wait type Resource_SEMAPHORE and how to fix it?

You can also run below DBCC commands to free several SQL Server memory caches. This will also help you and make some relief for your current running transactions but in longer run it will not help if your system will need more memory to proceed the transactions.

• DBCC FREESYSTEMCACHE
• DBCC FREESESSIONCACHE
• DBCC FREEPROCCACHE

Another effective way to look in to memory status is by getting the output of DBCC MEMORYSTATUS command. You would get a good starting point to look in to culprit memory consumers.

We can also start collecting performance monitor counters for memory. Perfmon counters like the value of SQL Server: Buffer Manager\Buffer Cache Hit Ratio, SQL Server: Memory Manager and Page Life Expectancy will be very helpful in identifying memory pressure on SQL Server system. Analyze the trend for these counters and then decide whether issue is coming during some specific operations or system is continuously facing memory pressure.

Based on these analyses you can choose to either increase the system memory, increase the SQL Server memory allocation or reschedule some of the memory specific transactions to the off hours when load is minimum on the system. You can also reduce the batch size of the transaction to reduce the memory pressure. This will be certainly helpful in troubleshooting memory issues.

It is not necessary that your transactions are poorly designed always that is why SQL Server is taking lot of memory to process it. Sometimes even our systems on which SQL Server runs might have problem that end up with memory pressure. So you should consider all these points while fixing any performance issue.
I hope you like this article. Please follow us on our Facebook page and Twitter handle to get latest updates.

Read More:

• 4 Usages of DBCC SQLPERF in SQL Server
• Manage Transaction Log File during Bulk Data Load
• How to Improve Bulk Data Load Performance?
• Overview of SQL Server Performance Tuning
• Identify Disk Bottleneck in SQL Server using Perfmon Disk Counters

The post SQL Server Error 701: There is Insufficient System Memory to Run this Query appeared first on Techyaz.com.

• If you have changed database server name then we should change SQL Server Instance name as well.
• If you have cloned a database server from DBSERVER1 to DBSERVER2. Here, SQL Server installed on DBSERVER1 will be copied with same name to DBSERVER2. You need to change the SQL Server instance name on DBSERVER2.
• Naming convention is not met.

Please keep in mind that we cannot change complete name of SQL Server named instance. Suppose you have installed a named instance SERVERNAME\DBInstance1 on your server. If you want to rename this named instance then we can only change first part of this name i.e. SERVERNAME. You cannot change DBInstance1 so your named instance will look like DBSERVERNAME\DBInstance1 post name change.

Impact of Changing SQL Server Instance Name

We need to plan carefully before renaming any SQL Server Instance. Below is the list of possible impacts that you should go through while renaming SQL Server Instance name.

• Those domain users who are accessing or connecting to the SQL Server Instance as part of Windows group will not be able to connect to renamed instance of SQL Server. Make sure to update the Windows group to specify the new computer name to establish connectivity to the SQL Server instance.
• You would not be able to access reporting services after renaming the instance name. You should follow steps mentioned in attached article to rename SQL Server instance that is running with reporting services.
• If you have database mirroring on the SQL Server instance then you need to drop the mirroring and then reconfigure it post renaming the SQL Server Instance.
• Renaming SQL Server instance name does not support if your instance has replication, except when you use log shipping with replication.
• You can change the name of SQL Server instance on secondary server in log shipping if the primary server is permanently lost.
• If you have linked server configurations then it will be affected by the computer renaming operation. Use sp_addlinkedserveror sp_setnetname to update computer name references.

Rename SQL Server Instance

SQL Server instance name along with other system metadata stores in sys.servers system object. We need to update details in system metadata to reflect new name. Also i would suggest to not change SQL Server Instance name directly on your production server.

Suppose you have installed default instance of SQL Server in your database server. If you have changed the name of your database server then you need to update the name of default SQL Server instance as well in sys.servers system table. First, we need to drop the existing SQL Server instance name then we will add new name as per our choice. Follow below steps to change SQL Server instance name.

--Drop existing name
sp_dropserver [old_Instance_name]; 
GO 

--Update New name
sp_addserver [new_Instance_name], local; 
GO

If you have installed a named instance on your database server then you can run below command to change SQL Server Instance name.

sp_dropserver [old_name\instancename]; 
GO 

sp_addserver [new_name\instancename], local; 
GO

Note: Make sure to restart SQL Server services post running above commands to reflect these changes.

You can verify the changes by running below commands or by querying sys.servers system table. If you have not restarted SQL Server services then you might be getting older SQL Server instance name. So restart SQL Server service to apply new changes.

SELECT @@SERVERNAME

If you have remote logins on your database server then you might get error 15190 while running sp_dropserver command. Read below article to fix this issue and then proceed with the instance name change.

• Fix Error 15190: There are still remote logins for the server

I hope you like this article. Please follow our Facebook and on Twitter handle to get latest updates.

Read More:

• Configure Reporting Services After Renaming SQL Server Instance Name
• How to Find When SQL Server was Installed on your database server?
• What should be best value for fill factor in SQL Server?
• Find all trace profilers running on SQL Server Instance
• How to Move a Table to Another Filegroup?

The post How to Change SQL Server Instance Name? appeared first on Techyaz.com.

I have also described multiple impacts of renaming SQL Server Instances. One of the impact of renaming SQL Server Instance that has SQL Server reporting services is also mentioned there and impact is reporting services will stop working if you simply change SQL Server instance name of report server. We need to perform some additional steps to reconfigure report server after a computer name change.

Configure Report Server After Renaming SQL Server Instance

You should rename SQL Server instance as per steps described in above attached link. Once you have changed SQL Server instance name then you should follow below additional steps to make reporting services accessible.

• Launch SQL Server Reporting Services Configuration tool and connect to the report server that uses the report server database on the renamed server.
• Go to Database Setup page.
• Enter SQL Server name in Server Name and then click Connect. If Reporting Services is configured using the server name, you must update the database connection information whenever the server name is changed.
• Click Apply and close the SSRS Configuration tool.
• Now search and open a config file RSReportServer.config in a text editor and modify the UrlRoot setting to reflect the new server name.
• UrlRoot setting is used by delivery extensions to compose the URL used to access items stored on the report server. Changing the report server URL address requires that you update the UrlRoot setting so that subscriptions continue to deliver reports as expected.
• In the same file, if it is set, modify the ReportServerUrl setting to reflect the new server name. Note if this setting is empty then do nothing.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 15190: There are still remote logins for the server
• How to Change SQL Server Instance Name?

The post How to Configure Reporting Services after Renaming SQL Server Instance appeared first on Techyaz.com.

Server: Msg 15190, Level 16, State 1, Procedure sp_dropserver
There are still remote logins for the server ‘DBSERVER’.

Error 15190 – Root Cause

As we know we need to first drop the existing details of SQL Server instance name from metadata system table sys.servers and then add new instance name in order to change the instance name. I was doing the same and running below command to drop the old instance name.

sp_dropserver <old_Name>; 
GO

I had received this error 15190 while executing above command and that is because of some remote logins present of the SQL Server instance.

If your database server has any remote login that you use for linked servers or some other purposes then you will get such issues. We need to drop all the remote logins to fix this issue and execute above command successfully.

Solution

To fix this issue we need to identify remote logins and drop them before changing the SQL Server instance name. We will be using a system stored procedure sp_dropremotelogin to drop all remote logins from our SQL Server instance. Run below command to drop all remote logins from a default instance of SQL Server.

sp_dropremotelogin old_name; 
GO

If you have named instance running on your database server then you can run below command. Make sure to change the name of server in place of Old_DBSERVER\Instancename.

sp_dropremotelogin Old_DBSERVER\Instancename; 
GO

Once all remote logins have been dropped you can go ahead and perform your SQL Server Instance name change operation. Make sure to create remote logins for your linked servers or alias post changing the instance name.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Change SQL Server Instance Name?
• How to Rename SQL Server Instance that is running with SQL Server Reporting Services?
• Fix Error 15434: Could not drop login “domain\loginname” as the user is currently logged in
• Fix Error 15174: Login owns one or more databases. Change the owner of database before dropping the login.
• How to Change Hostname of RHEL system?

The post Fix Error 15190: There are still remote logins for the server ‘DBSERVER’. appeared first on Techyaz.com.

Error 1105, Severity 17, State 2
Could not allocate space for object ‘Object_Name’ in database ‘DB_Name’ because the ‘Primary’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Error 1105 – Root Cause

As error suggests, this issue was generated because database was not able to allocate space anymore. Whenever you get such space issue, all transactions will be stopped until you make some room in the database. All transactions will be stopped because of non availability of space because none of the transaction will get any space to proceed their transactions. There are many reasons you can get space issues. Some of them are:

• Data or Log drive is full.
• Database file/s has restricted file growth
• Database File Autogrowth is not enabled.
• Some tables are growing faster than our prediction.
• Some long running transaction is eating all space.

We generally get error 1105 when any database including tempdb or any transaction log file get full and runs out of space. File growth restriction is also a possible reason you can get error 1105. Make sure to check all database files associated with your database to make sure there is no file growth restriction is set that is causing to generate this error. Sometimes when you restrict the file growth and the file size reached its limit, you may get this error message when trying insert / updates on database. I have explained multiple solutions to overcome this issue. Have a look at below section to get the solution of such space issues.

Solution

To fix this error we need to make space in the database so that all running transactions can execute and log their operations. We have multiple solutions to fix such issue based on the nature of the issues. Some of the solutions are given below:

• First you should check if any unwanted file is not there in data or log drive. Sometimes we placed backup files in data or log drive and forgot to delete it. Make sure to remove or move such unwanted files to make space for your database.
• If any of the database files have restricted file growth then you should immediately turn on autogrow feature of the data or log file. You can read below article to understand what should be the perfect value for autogrowth of a data or log file.

How to Enable Autogrowth and What should be the Best value for File Autogrowth?

• If size of your database file is limited to some value then make sure to extend the size of that file or I would suggest going with unrestricted growth. Read above attached article to get more about this.
• If your data or log drive is running out of space then you should add more files to the file group on different drive where you have enough space. You can use below command to add any data or log file to your desired drive. Make sure to change the drive path as per your correct path.

ALTER DATABASE Techyaz
ADD FILE (
NAME = techyaz_Data3,
FILENAME = 'F:\MSSQL\DATA\techyaz_DataFile3.ndf')

• We can also free disk space by dropping index or tables that are no longer needed. You can also consider data purging for unwanted tables or indexes.
• You can also consider moving some of the database files to different drive to make some space for your database.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 1101: Could not allocate a new page for database
• Why should we Avoid Database Shrink Operation?
• Why should we always Disable Autoshrink property?

The post Fix Error 1105: Could not allocate space for object in database because the filegroup is full. appeared first on Techyaz.com.

Msg 15123, Level 16, State 1, Procedure sp_configure, Line 51
The configuration option ‘xp_cmdshell’ does not exist, or it may be an advanced option.

The screenshot of the error is given in below image.

You might get this error while changing or viewing values of any advanced server configuration option. Here I will show you how to fix this error and make such changes successfully.

Error 15123 – Root Cause

As we know, there are lot of server level configurations that we can see or change using command sp_configure. Some of the server level configuration options categorized as advanced options and that cannot be viewed or changed if the value of “show advanced options” is set to 0 or disabled.

We can view “show advanced options” value by running sp_configure command. If the run value of this command is set to 0 it means this option is disabled and you cannot see any advanced server configurations.

To see or change the advance server level configurations we need to enable “show advanced options” by setting its value to 1 using sp_configure. Run below command to check the current run value for “show advanced options”. You can also simply type sp_configure command and execute it to get its details along with all other server configuration options.

exec sp_configure ‘show advanced options’

We can see run value of parameter “show advanced option” is set as zero it means we cannot view or change any advanced server configurations using command sp_configure.

This is the main reason behind getting error 15123 and we can get this error while changing any advance server level parameters. Read below section to enable “show advanced options” and change the values of advanced server configurations.

Solution

Generally, we get error 15123 because “show advanced options” is disabled and set to zero and it’s not allow to do anything with advanced server options. As we have seen “show advanced options” is set to zero in above screenshot. Here, we will enable it and then run again same command that we have ran in first screenshot to enable xp_cmdshell extended procedure.

Let’s enable “show advanced options” option to view or change the advance server level configurations by running below command.

exec sp_configure ‘show advanced options’, 1
 RECONFIGURE WITH OVERRIDE

Above command has been executed successfully. You can see this in below screenshot.

Now we can go ahead and view any advanced options by running simply sp_configure command. If you need to make any changes on existing values of advanced server options then also you can do it using sp_configure command now. Let’s go ahead and run same command that we had ran in first image to enable xp_cmdshell.

exec sp_configure 'xp_cmdshell', 1
 reconfigure with override

We can see this command has been executed successfully this time without any error.

Whenever you get error 15123 while viewing or changing values of any advanced option you should first enable or set the value for option “show advanced options” then you can make your desired changes accordingly.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to change Network Packet size in SQL Server
• Fix Error 233: How to Set the User Connections Server Configuration option in SQL Server
• Understanding SQL Server Memory Allocation
• SQL Server DBA Interview Questions & Answer

The post Fix Error 15123: The configuration option does not exist. appeared first on Techyaz.com.

Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

You can see the screenshot of the error 18452 in below image.

Error 18452 – Root Cause

Reason behind error 18452 is because of wrong security authentication mode configuration. SQL Server is set to accept only windows logins to connect to database instance.

As we know SQL Server uses two authentication modes to accept database connections. One is Windows Authentication mode and another one is SQL Server and Windows Authentication mode. We also call it Mixed Authentication mode.

Sometimes, SQL Server authentication mode is set to SQL Server and Windows Authentication mode to accept SQL as well as windows connections but still you will face this issue. That might be because you try to connect to a server that has Always on Availability Group configuration or database mirroring configuration.

Suppose you have AOAG configuration and you are connecting to database using primary replica name not listener name using a login for which default database is set as availability database. If failover got happen during your activity or you are connecting to secondary replica using a login for which default database is set as availability database then also you will get this error 18452 along with some SSPI context error that I have given below.

Error: 17806, Severity: 20, State: 14.
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed 

SSPI handshake errors comes because of Kerberos failure, which would most likely be related to non-existent SPN or bad SPN for SQL Server.

Solution

To fix this issue first we need to check the authentication mode set for your SQL Server Instance. If your SQL Server instance is running with windows authentication mode then you must change it to Mixed mode so that windows and SQL both type of logins can be authenticated.

To check the configured authentication mode for your SQL Server Instance, we need to launch SQL Server Instance property window. Right click at the instance node and click at the properties option as shown in below screenshot.

Once you will click at Properties option, you will be getting below SQL Server instance property window. Click at Security option from left side pane. You can see current Server Authentication configuration is set to Windows Authentication mode in below screenshot.

Now we will change it to SQL Server and Windows Authentication mode. Select the radio button for SQL Server and Windows Authentication mode option and click ok button to proceed. You can see that I have selected above mode to apply the changes.

Restart SQL Server services to apply the changes.

If your SQL Server Instance is already set with SQL Server and Windows Authentication mode then you should fix this issue in separate way. As I described above that one of the probable reason to get this error 18452 is because you might use AOAG replica server name to connect to the database with the login for which default database is set as the AOAG availability database.

If failover will happen then you would not be able to access the database because it will become secondary. Error 18452 will be generated along with SSPI handshake errors because same database is set as default database for your login that has become inaccessible now because of acting secondary database in AOAG. Failover will not happen for you because you are using replica server name to make database connection.

Possible solution to fix this issue is failback the AOAG to your earlier primary replica or you should use AOAG Listener name to make database connection. Also, to avoid this error during failover you should set default database for your login to master rather than availability database.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 18456: Login failed for user “User_Name”
• Fix Error 4064: Cannot open user default database. Login failed
• Error 53: Could not open a connection on SQL Server
• AOAG Listener Error 19471: The handle is Invalid

The post Fix Error 18452: Login failed. The login is from an untrusted domain appeared first on Techyaz.com.