SQL Server Error 18456, also known as the “Login failed for user” error, is a common authentication error that occurs when a user fails to log in to SQL Server. The error message associated with Error 18456 usually reads:

“Login failed for user ‘<username>’. (Microsoft SQL Server, Error: 18456)”

The error occurs when SQL Server is unable to authenticate the user trying to connect to the SQL Server instance. There are several reasons why this error may occur, including incorrect login credentials, disabled user accounts, expired passwords, or issues with SQL Server authentication settings.

How to Fix SQL Server Error 18456?

Fixing SQL Error 18456 requires identifying the root cause of the error and applying the appropriate solution. Here are some common solutions to fix SQL Error 18456:

1. Verify Login Credentials: The most basic step in fixing SQL Server Error 18456 is to verify that the login credentials, including the username and password, are correct. Make sure you are entering the correct login credentials for the SQL Server instance you are trying to connect to.
2. Enable Mixed Mode Authentication: SQL Server supports two types of authentication modes – Windows Authentication mode and Mixed Mode (Windows Authentication and SQL Server Authentication) mode. If you are using SQL Server Authentication, make sure that Mixed Mode Authentication is enabled in SQL Server. You can do this through SQL Server Management Studio (SSMS) by right-clicking on the SQL Server instance, selecting Properties, and then navigating to the Security tab.
3. Check User Account Status: Ensure that the user account you are trying to log in with is not disabled or locked out. If the user account is disabled or locked out, unlock or enable the account using SQL Server Management Studio or SQL Server command-line tools.
4. Reset Password: If you suspect that the password for the SQL Server login is incorrect or has expired, reset the password. You can do this through SQL Server Management Studio or by using the ALTER LOGIN statement in SQL Server.
5. Check SQL Server Error Logs: SQL Server logs detailed information about authentication failures in its error logs. Review the SQL Server error logs to identify any specific error messages related to Error 18456. The error logs may provide additional insights into the root cause of the issue.
6. Verify SQL Server Permissions: Ensure that the user account has the necessary permissions to log in to the SQL Server instance. Check the server-level and database-level permissions for the user account and grant the appropriate permissions if necessary.
7. Check Firewall Settings: If you are connecting to a remote SQL Server instance, verify that the appropriate ports are open in the firewall to allow communication between the client and the server. Check the firewall settings on both the client and server machines to ensure that they are not blocking the required ports.
8. Check SQL Server Version: Error 18456 can also occur if there is a version mismatch between the SQL Server client and server components. Ensure that the SQL Server client version matches the server version to avoid compatibility issues.
9. Apply SQL Server Service Packs and Cumulative Updates: Microsoft regularly releases service packs and cumulative updates for SQL Server that address known issues and provide bug fixes.

You can also read the below articles to fix SQL error 18456:

• Fix SQL Error 18456: failed to open the explicitly specified database
• Fix SQL Server Error 18456: Login failed for user ‘User_Name’.
• Fix Error 18452: Login failed. The login is from an untrusted domain

The post How to Fix SQL Server Error 18456: A Comprehensive Guide appeared first on Techyaz.com.

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 connection timeout has occurred on a previously established connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

You may also receive similar issue under different alwayson error 35201. Below error will generate while attempting to establish the connection to availability group but failed because of connection timeout error 35206. The error text of this SQL error 35201 is given below.

A connection timeout has occurred while attempting to establish a connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

If you are always getting above issues and unable to establish any connection to its respective availability replica then you should immediately look in to network side whether there is poor network latency, any network packet drop issue or firewall is blocking some connections or not as suggested in error code. But if you are getting this issue on intermittent basis then you should keep reading this article to understand more about alwayson error 35206.

SQL Server Error 35206 and Error 35201 in Always on

Both errors come because of connection timeout error between their respective replicas. Microsoft has categorized these errors as product issue and released cumulative updates to fix them. You should also consider these cumulative updates as per your SQL Server version. These issues will be very problematic if you will not address them on time because of below reasons:

• Availability databases will stop synchronizing. This could be a risk of potential data loss.
• Log file will start growing on your primary replica. This could be a potential risk for an outage if we will not address this issue on time.
• Frequent repetitive alerts for your critical systems

You must fix this issue by applying the cumulative update to avoid above problematic scenarios. But if you already have applied these updates and are still facing these issues then i would recommend you to read below section to try out other options.

Fix Always on Connection Timeout SQL Error 35206

Generally, this problem encounters only on high end systems where you have more than 24 cores CPU and SQL Server is highly transactional. One very simple workaround to overcome this issue is to restart SQL Server service on your secondary replica where you are getting this issue. Don’t restart SQL Server on primary replica. Restarting SQL Server on impacted availability replica will surely fix the issue for the time being.

Additionally, you should consider below checks to review and make changes accordingly as per your system design if you are still getting this issue on frequent basis.

Use Default Network Packet Size

Review network packet size configuration in SQL Server. Microsoft suggested to keep network packet size configuration with default value but sometime we make changes as per our need and forgot to revert these changes to their original values so i would recommend to revert this change to its default value. Read below article if you want to learn how to change network packet size configuration in SQL Server.

• How to Change Network Packet Size in SQL Server?

You should also consider evaluating your network bandwidth and firewall settings to make sure and isolate the issue. I would suggest you to work with network engineer on this front to review network or firewall related configurations.

Review Connection Timeout Setting

Another option i would recommend you to evaluate and review the session or connection time out settings. Make sure that session timeout setting for your always on configuration must be more than or equal to 10 seconds. You can consider increasing session time out if you have slow network between your replicas. Although if you are running highly transactional databases on high end box i assume you already have good network bandwidth but nothing wrong in reviewing the settings. Read below article if you want to reconfigure or change session time out in always on availability group.

• How to Change Session Timeout in Always on Availability Group Configuration?

If you are running your always on availability group configuration between multi subnet environment then i would recommend you to read attached Microsoft article to fix connection timeout errors in multi subnet availability groups.

Read More:

• Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group
• SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
• Fix SQL Server Error 19471: Listener issue that came during Configuring SQL Server AlwaysOn Availability Group
• SQL Server Alwayson Interview Questions & Answers

The post Fix Always ON Connection Timeout Error 35206 in SQL Server appeared first on Techyaz.com.

The connection timeout setting in AOAG applies only to identified secondary replica and its respective primary replica. Each secondary replica has its different session timeout value which works between the given replica and its primary replica. The default value for session timeout configuration is 10 seconds. Microsoft recommends to keep this setting value to 10 seconds or more to prevent system missing pings and false failure alerts.

Change Session Timeout for Availability Replica

This section will explain how to change or modify connection or session timeout value for an AOAG availability replica. This is needed sometimes if you are frequently getting connection timeout errors for your availability replicas. I will show two ways to modify session timeout in always on availability group. One is by using SQL Server Management Studio and another one by using T-SQL statement.

Modify Alwayson Connection Timeout using SQL Server Management Studio

Make sure you have connected to your SQL Server Instance which is hosting primary replica of always on availability group configuration. Follow below steps to change session timeout or connection timeout for identified availability replica where you are facing connection timeout errors 35206 or 35201.

• Launch SQL Server Management Studio and connect to the primary replica
• Expand folders once you connected to the primary replica instance. Click at plus sign to expand Always on High Availability node followed by Availability Groups node.
• Identify and click the availability group for which you have to configure connection timeout for one of its availability replica
• Identify the availability replica for which you have to change this value. Right click at this replica and click at Properties option to launch its properties page
• You can see Session timeout (seconds) option In the Availability Replica Properties dialog box. Use Session timeout (seconds) option to change the number of seconds for the session timeout period on this replica. Always keep it 10 or more as per your specific need.

We have successfully changed alwayson connection timeout for an availability replica using SQL Server management studio in above steps. Now, i will show you T-SQL approach to get this done in below section.

Change Alwayson Connection Timeout using T-SQL Statement

Here, i will show you how to change session timeout for an availability replica using T-SQL statement.

• Launch SQL Server Management Studio and connect to the primary replica.
• Open New Query window and run below ALTER AVAILABILITY GROUP statement.

ALTER AVAILABILITY GROUP group_name

MODIFY REPLICA ON ‘instance_name‘ WITH ( SESSION_TIMEOUT =seconds )

Make sure to replace group_name with your availability group name, instance_name with your secondary replica name for which you want to change session timeout value and seconds with appropriate time in seconds.

Once you will execute above statement, connection timeout value will change as per your specified value for your availability replica. Now, you can go ahead and monitor the connection timeout errors to see whether your issue has been fixed or not.

Here, i have explained how to modify or change session timeout for an always on availability group replica.

Read More:

• SQL Server Alwayson Interview Questions & Answers
• SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
• Understanding Backup Preferences for AlwaysOn Availability Group Databases

The post How to Change Session Timeout for Availability Group Replica appeared first on Techyaz.com.

Get Values between Two Dates using SQL BETWEEN

Let’s say you have a requirement to get all values between two date ranges or specific date time ranges. You can use SQL BETWEEN operator to get this done. Here is the example to get all values between date 19th March 2021 and 20th March 2021. Below example is also an use case of how to use BETWEEN operator in WHERE clause. You can remove ‘-‘ from date ranges if you want and you can directly mention date ranges as ‘20210319’ AND ‘20210320’.

SELECT name, type_desc,create_date, modify_date
FROM sys.objects
WHERE modify_date BETWEEN ‘2021-03-19’ AND ‘2021-03-20’

Here, i have fetched all modified objects on my SQL Server between given date range. Here is the output. We can see there are more than 730 rows returned. You can compare the dates in modify_date column whether output has returned correct data or not.

Now, Next requirement could be to retrieve some data between two date time ranges like you want details between specific time of dates. I will take same above query to show case this example as well. When we don’t specify the time along with date range then it defaults to 12:00 A.M. 

SELECT name, type_desc,create_date, modify_date
FROM sys.objects
WHERE modify_date BETWEEN ‘2021-03-19 4:38:00’ AND ‘2021-03-19 4:38:30’

Here, i have retrieved all modified objects between 30 seconds of above given time (Time 4:38:00 to 4:38:30). Here is the output and it is showing only 35 rows.

You can use this SQL between two date ranges or datetime ranges to fetch your data. You can use this operator in INSERT, UPDATE or DELETE statements as well.

Get Values between Two Numbers

This section will explain about getting details between two number ranges. Let me take same table which we have taken for above section sys.objects. Now, i want to get all objects having object id between 25 to 30 or you can mention any range. This is just an example to showcase. These number ranges will change as per your need and nature of data.

SELECT name, object_id, type_desc, create_date
FROM sys.objects
WHERE object_id BETWEEN ’25’ AND ’30’

Note, above object_id is column name and not the T-SQL function. Have a look at its output in below image. We have got only rows which are assigned with these object ids.

Use BETWEEN with NOT Operator

Above all examples shows how to get data between two ranges but we can use NOT operator with BETWEEN to return all values which is not between specified two ranges. Let’s take above example where BETWEEN operator has returned only 5 rows based on their specified two ranges. Now if i will use NOT operator in above T-SQL statement then output will return all rows of table sys.objects except above 4 rows which will be prevented by NOT operator. Let me show you this example.

SELECT name, object_id, type_desc, create_date
FROM sys.objects
WHERE object_id NOT BETWEEN ’25’ AND ’30’

Have a look at below highlighted are where objects ids between 25 to 30 are missing.

Here, i have shown you few use cases of SQL Server T-SQL operator BETWEEN statement. You can go head and try this operator for your business needs. For more information on this operator, visit MSDN article.

Read More

• Fix:VIEW SERVER STATE permission was denied on object ‘server’, database ‘master’
• Difference between UNION and UNION ALL T-SQL Operators
• SQL Server Interview Questions & Answers on Indexes

The post Learn How to use SQL Server BETWEEN Operator 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.

• Mixed Mode ( Windows +SQL Server login )
• Windows Mode (Only Windows)

Mixed mode provides two ways to establish database connections. One is using SQL Server logins at SQL Server layer and another one is using Windows domain user authenticated using active directory and whose login is created and mapped on SQL Server instance.

Windows Mode has only one way to establish database connections and that is using windows domain accounts. We must map windows accounts on SQL Server first before making any database connections. This mode doesn’t provide access to SQL Server logins.

Read More to Grow:

• SQL Server Interview Questions & Answers on Indexes
• How to Prepare for a Job Interview?
• SQL Server Alwayson Interview Questions & Answers
• SQL Server Replication Interview Questions & Answers

Why Windows Authentication Mode is More Secure in SQL Server?

Windows mode is secure than Mixed mode authentication because mixed mode has SQL Server authentication which cannot use Kerberos security protocol. Windows account needs to be authenticated to domain active directory every time you establish a database connection. Also, Windows provides additional password policies that are not available for SQL Server logins and that is why Microsoft always recommends to use Windows authentication mode wherever it’s possible.

One more risk with Mixed mode is the encrypted SQL Server Authentication login password must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.

Change Authentication Mode in SQL Server

You can configure authentication mode in SQL Server during installing it to your system. SQL Server installation windows will allow you to choose any one of above given authentication modes. If you will choose mixed authentication mode then you need to provide sa password as per windows password policy. You can also change existing authentication mode setting to another one as per your business need.

Let’s assume you have installed SQL Server with Mixed authentication mode and now you have to change it to Windows Authentication mode. This section will explain step by step process to change SQL Server authentication mode.

We can set or change authentication mode in SQL Server either using SQL Server management studio or using T-SQL statements.

Using SQL Server Management Studio

1. Launch SQL Server Management Studio, connect to your target SQL Server instance.
2. In SQL Server Management Studio Object Explorer, right-click the server, and then click Properties.
3. On the Security page, under Server authentication, you can see both authentication modes. Select any as per your need and then click OK.
4. This change will require SQL Server service restart. A popup window will appear to ask you to restart the service when you will click at OK button in above step.
5. In Object Explorer, right-click your server, and then click Restart. If SQL Server Agent is running, it must also be restarted.

You have changed your authentication mode from Mixed mode to Windows using SQL Server Management Studio.

If you are changing authentication mode from Windows to Mixed mode then make sure to enable SQL Server login sa account. This account gets disabled during windows authentication mode to secure your SQL Server instance as sa is generic SQL Server login as it can be targeted by hackers to access your instance. Below are the steps to enable this account:

1. In Object Explorer, expand Security, expand Logins, right-click sa, and then click Properties.
2. On the General page, you might have to create and confirm a password for the sa login.
3. On the Status page, in the Login section, click Enabled, and then click OK.

Using T-SQL Statement

Microsoft has provided an extended stored procedure to chnage authenication mode in SQL Server using T-SQL statement. This extended stored procedure chnages windows registry entries so be careful while changing authentication mode in SQL Server using T-SQL statements. Make sure to take a backup of windows registry before executing this script.

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
N'Software\Microsoft\MSSQLServer\MSSQLServer',
N'LoginMode', REG_DWORD, 1
GO

Above command has again changed authenticating mode from mixed to windows.

If you are doing other way around then make sure to enable sa login as i suggested above. You can also use below T-SQL statement to enable sa account.

ALTER LOGIN sa ENABLE ;
GO
ALTER LOGIN sa WITH PASSWORD = 'STRONG-PASSWORD' ;
GO

Here, i have explained how to change SQL Server authentication mode from Windows to Mixed mode or vice versa. Please comment us if you have any feedback on this article.

Related Articles:

• Fix SQL Server Error 18456: Login failed for user ‘User_Name’.
• How to Change SQL Server Instance Name?
• Create a Logon Trigger to Restrict sysadmin logins to connect to SQL Server for given Time Interval
• Fix Error 18452: Login failed. The login is from an untrusted domain

The post How to Change Authentication Mode in SQL Server? 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.

We should be very careful while running any of the database maintenance activities on production databases. It becomes more crucial if your database size is very very big or some critical business application is using this database. Yesterday i had similar experience in one of our SAP system. Application team had reported performance issue while accessing one of the SAP system. DBAs were involved and identified a long running query that was causing the performance issue. This long running query was executing update statistics SQL Server operation on one of the biggest table in the database. This activity took very long time around 12 hours and never completed. Finally team has killed this transaction as advised by SAP support to improve the performance.

Understanding Update Statistics in SQL Server

SQL Server uses statistics to generate fastest query plan for any transaction so we should ensure all statistics must be up to date to get better query performance. As per MSDN “Updating statistics ensures that queries compile with up-to-date statistics. However, updating statistics causes queries to recompile. We recommend not updating statistics too frequently because there is a performance tradeoff between improving query plans and the time it takes to recompile queries. “

Here, first i will explain one of my issue as case study and then will give you SQL update statistics best practices. There are multiple things that can lead to longer duration of this execution, so first we should understand the issue before reaching on any conclusion.

After looking into SQL Server transactions, we found that SQL Server update statistics was being executed with FULLSCAN option. This was a potential reason behind taking it for longer duration. Avoid running update statistics with FULLSCAN option while running it on very big tables or databases because it scans each and every record in the table that will degrade the system performance and took more time to complete. Although, you should always rethink before making a decision to run update statistics on your database if auto update statistics has been set to ON. As it was SAP ECC database so we checked the SAP documentation as well and SAP also suggests to not run it regularly if auto update statistics is set to ON. This is SQL Server auto update statistics best practices for very large databases.

In some cases, if you still have to run the update stats then always Use it without mentioning FULLSCAN parameter or use sp_updatestats stored procedure. If you still need to run WITH FULLSCAN then do not run the UPDATE STATISTICS SQL Server command against the entire table. Identify the column or index statistic that needs the special treatment, and only update that one with FULLSCAN.

Sometimes, SQL Server update statistics command may take very long time even after following above measures. This could be because of the bug reported in attached link. This has been fixed in below CU updates. Check your SQL Server version and apply them to fix this issue if applicable.

• Cumulative Update 2 for SQL Server 2019
• Cumulative Update 18 for SQL Server 2017
• Cumulative Update 11 for SQL Server 2016 SP2

SQL Server Update Statistics Best Practices

Below is the list of best practices i have mentioned to be considered while running update statistics in SQL Server. Have a look at them.

1. Running Update Statistics on very big tables or database can increase huge IO pressure on your disk subsystem. SQL Server has very good feature to keep running it in real time by setting value auto update statistics to ON. If auto update statistics is set to ON then it is strongly recommended to not run it regularly on any databases. We can run it only on those tables where this setting is set to OFF.
2. In some cases, if you still have to run the update stats then always Use it without mentioning FULLSCAN parameter or use sp_updatestats stored procedure. If you still need to run WITH FULLSCAN then Do not run the UPDATE STATISTICS command against the entire table. Identify the column or index statistic that needs the special treatment, and only update that one with FULLSCAN.
3. Always run such database maintenance activities during maintenance windows. It is not recommended to run during business hours.
4. If you are facing performance issue during update stats execution then you should check the possibilities of potential bug reported in attached link.
5. Never run Adhoc and manual Update stats on any of the very big tables if Auto Update Statistics is set to ON because Update stats is very costly operations in terms of heavy IO activities. It does acquire schema-stability locks so it can potentially be blocked by a DDL operation (like ALTER TABLE).
6. One way to find out whether you should run update stats or not is to check if your statistics are stale in the execution plans or not. If estimated rows greatly differ from your actual rows returned in execution plan then that is a good indication of potential update stats candidate.
7. Ask Migration team (In case recently migrated) whether they have executed rebuild index or update stats after migrating data to SQL Server as part of post upgrade activity? Ideally it is recommended to run update stats after massive data load because auto update stats does not automatically update all records.
8. If you’ve got tables with millions of rows, and you’ve found that statistics aren’t updating fast enough, you can consider:
   • Turning on Trace Flag 2371 to make auto-update statistics run more frequently on tables with large amounts of rows.
   • Using a third party script to handle statistics maintenance along with your index maintenance
9. One way to find out if your statistics are stale is to look at the execution plans and if you estimated rows greatly differ from your actual rows returned then that is a good indication that the interval needs to be upped. If you want to do update Statistics manually you should first know When Statistics are updated automatically.
10. If the SQL Server query optimizer requires statistics for a particular column in a table that has undergone substantial update activity since the last time the statistics were created or updated, SQL Server automatically updates the statistics by sampling the column values (by using auto update statistics). 

Update Statistics on AlwaysON Secondary Replica

Temporary statistics are an improvement added in SQL Server 2012 for read-only databases. When a database is read-only, queries can’t create statistics in the database– because those require writes. As of SQL Server 2012, temporary statistics can be created in tempdb to help optimization of queries.

This is incredibly useful for:

• Readable secondaries in an AlwaysOn Availability Group
• Readable logshipping secondary databases
• A point in time database snapshot which is queried (whether against a database mirror or live database)
• Any other read-only database that has queries run against it

Prior to SQL Server 2012, if you use logshipping for reporting and the same workload does not run against the log shipping publisher, consider manually creating column level statistics. (Or upgrading SQL Server.)

Read More:

• Understanding Database Autogrowth in SQL Server
• Understanding Database Shrink Operation
• SQL Server AlwaysON Interview Questions & Answers

The post SQL Server Update Statistics Best Practices appeared first on Techyaz.com.

Before going ahead, you might be thinking what is Persistent Memory devices and how it is related to SQL Server. Let me first explain about persistent memory.

What is Persistent Memory?

Persistent memory generally termed as PMEM, is a solid-state high performance byte-addressable memory device that resides on the memory bus. It has many benefits over other storage devices.

The main advantages of persistent memory include: 

• It provides fast data access near real-time without any latency than flash SSDs for large data sets as well.
• PMEM increases throughput more than flash storage.
• Biggest benefit is its cost. It’s cheaper than DRAM. 
• PMEM is cacheable. This is a huge advantage over PCIe interconnect, which cannot be cached in the CPU.
• It retains Data in memory after power interruption or shut off. 

Persistent memory can be used in a variety of ways to deliver lower latency for applications where you need fast data access with enormous amount of data such as IoT applications, Cyber threat analysis, financial trading etc.

What is Hybrid Buffer Pool?

In a traditional system, SQL Server caches data pages in the buffer pool. With Hybrid Buffer Pool, SQL Server skips performing a copy of the page into the DRAM-based portion of the buffer pool, and instead references the page directly on the database file that lives on a PMEM device. Access to data files in PMEM for Hybrid Buffer Pool is performed using memory-mapped I/O, also known as enlightenment. This brings performance benefits from avoiding a copy of the page to DRAM, and from the avoidance of the I/O stack of the operating system to access the page on persistent storage.

Only clean pages can be referenced directly on a PMEM device. When a page becomes dirty it is kept in DRAM, and then eventually written back to the PMEM device.

This feature will be available in both Windows and Linux version of SQL Server 2019.

How to Enable Hybrid Buffer Pool?

We can enable Hybrid Buffer Pool for SQL Server instance by enabling trace flag during SQL Server startup. As of now, the current process is, we must enable the startup trace flag 809 in order to use Hybrid Buffer Pool.

Microsoft suggests a best practice to keep in mind while enabling
Hybrid Buffer Pool in SQL Server. We should use largest allocation size available for NTFS and ensure the device has been enabled for DAX (DirectAccess) while formatting the PMEM device on Windows.

I hope you liked this article. Please write your comments if you have any questions.

Read More:

• SQL Server 2017 New Features
• New T-SQL Functions introduced in SQL Server 2017
• SQL Server DBA Interview Questions & Answers

The post Understanding Hybrid Buffer Pool in SQL Server 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.

Msg 5184, Level 16, State 2, Line 1
Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server.
Only formatted files on which the cluster resource of the server has a dependency can be used. Either the disk resource containing the file is not present in the cluster group or the cluster resource of the Sql Server does not have a dependency on it.

Msg 1802, Level 16, State 1, Line 1
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

While troubleshooting this error we came to know that the storage or LUN on which we have placed the database files are not added to cluster group. It means disk is not visible in failover cluster manager.

Solution – Error 5184

We performed below steps to fix this issue.

1. Added the storage on which databases files are placed as shared storage in the failover cluster manager.
2. Launch SQL Server properties window in Failover Cluster Manager.
3. Added all newly added disks in Dependencies tab.
4. Attached the database again.

Here i will explain above steps in detail with screenshots.

• We were attaching a database using T-SQL statement on one of the SQL Server cluster instance. While executing the command we get error 5184. Error details are given in below screenshot.

• As error suggests that “Either the disk resource containing the file is not present in the cluster group” so I checked cluster group for the disk and found that database files storage was not showing in failover cluster manager.
• Next step was to add these storage disks to the cluster group. Launch failover cluster manager. Click at Roles tab from left side pane. You can see SQL Server as role in right side pane. Right click at the SQL Server role and click at “Add Storage” option. You can see this in below screenshot.

• Once you will click at “Add Storage” option you will get below window to add the identified disks to cluster group. You can see I have selected all required disks in below screenshot. You can choose your disks where your database files are placed.

• Once you click at OK button post selecting all respective check boxes in above step, you will see all your storage disks in failover cluster manager under storage tab.
• Now again click at the SQL Server role and then go to “Resources” tab from down side pane where you can see SQL Server and all resources that are aligned for the SQL Server role. Here, right click at SQL Server and click at Properties tab as shown in below screenshot.

• Once you get SQL Server properties windows in failover cluster manager, next you should click at dependencies tab. Here, you need to insert one row for each disk system that you have added in above steps. Once you will insert dependencies for all newly added disks then it will look like below screenshot. Now click at OK button to apply this change.

• Now again go to SQL Server query window and run the T-SQL command to  attach the database. This time you will successfully attach the database to the clustered SQL Server instance.

Let me know if this article helped you to fix your issue. You can follow our facebook page and Twitter handle to get latest updates.

Read More:

• Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• How to Prepare for a Job Interview?
• SQL Server DBA Interview Questions & Answers

The post SQL Server Error 5184: Cannot use file ‘I:\Path\Techyaz.mdf’ for clustered server appeared first on Techyaz.com.

If your drive letters or folder structures are identical on all replica servers then most of the time you will not face any issue while adding the database files but sometimes if you mount additional drive on all replicas to make it identical and then add data file in this new drive then you might face the issue. If all replica servers don’t have identical path then adding database file operation on primary replica will not successfully replicate to other replica servers because of different drive and folder structure. This, in turn, causes the secondary replica to enter the NOT SYNCHRONIZING state.

Note: Always try to keep drive and folder structure identical on all secondary replica servers to the corresponding primary replica.

If you have added a data file on primary database of Always on Availability group then you will see multiple errors logged in SQL Server error log on your secondary replica where secondary database is suspended from always on availability group and showing in “Not Synchronizing” state. You might see one of the below error codes in your log file.

Error:5123, Severity:16, State:1.
CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the physical file ‘E:\MSSQL\Data\Techyaz_Data2.ndf’.

Or

Error:5183, Severity:16, State:1.
Cannot create the file “Techyaz_Data2”. Use WITH MOVE to specify a usable physical file name. Use WITH REPLACE to overwrite an existing file.

Or

Error: 3313, Severity: 21, State: 2.
During redoing of a logged operation in database ‘Techyaz’, an error occurred at log record ID (76:659:1).

Now i will describe how to fix such issues or how to plan and add a database file to always on availability databases.

Add Data file to Availability Database

If you have already added data file on primary database and your secondary databases are suspended from availability group then we need to fix it to reestablish always on availability group. If you have not added the data file and want to add it then you can keep reading this article as i have described it later in this article. I have described how to plan database file addition to avoid any future synchronization issue.

Let’s go ahead with the first option where you have already added the data file to primary availability database and secondary database status is showing as not synchronizing due to this change. Now we need to fix this issue to reestablish the synchronization between replicas of availability group. To resolve this problem the DBAs  must complete the following steps:

1. Remove the secondary database from the availability group that is showing as “Not Synchronizing”. To do this, either you can use GUI method in SSMS or run below T-SQL statement. You can connect to secondary replica then you can expand Always On High Availability node followed by Availability Groups Now, select the availability group and then expand the Availability Databases node. To remove a single database, select it in either the Object Explorer pane or the Object Explorer Details pane. Right-click the selected database or databases, and select Remove Secondary Database in the command menu. If you want to do it using T-SQL statement then you must connect to secondary replica and execute below Alter command.

ALTER DATABASE Techyaz SET HADR OFF;  
GO 

2. Once database will be removed from AOAG, restore a full backup of the filegroup that contains the added file to the secondary database, using WITH NORECOVERY and WITH MOVE option. This option is mandatory if you don’t have any log backups. Although sometimes you can do it by only running log backup on primary replica and restore it on secondary replica in norecovery mode as mentioned in next step.
3. Now, back up the transaction log that contains the add-file operation on the primary database, and manually restore the log backup on the secondary database using WITH NORECOVERY and WITH MOVE.
4. Prepare the secondary database for re-joining the availability group, by restoring, WITH NO RECOVERY, any other outstanding log backups from the primary database.
5. Rejoin the secondary database to the availability group. Read this article to get step by step method to add a database to availability group.

If you havenot added the data file then you can plan it with following steps.

1. Remove the database from secondary replica as described in above section. Now, secondary database will be showing in to restoring state.
2. Add the data file to your availability database on primary replica.
3. Take a log backup of this availability database on primary replica.
4. Copy this log backup to secondary replica and restore it on its corresponding secondary replica using NORECOVERY and WITH MOVE option.
5. Now add the database back to always on Availability Group.

Here, I have shown you step by step process to add data file to availability database. I have also let you know how to fix the issues that might arise due to adding the database files to availability database on primary replica. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group
• Understanding Enhanced Database Failover in Always on Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• Always ON Availability Group Interview Questions & Answers

The post How to Add Data File to Availability Database? 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.

Enhanced Database Failover option is not mandatory while configuring Always on Availability Group in SQL Server 2016. It’s optional and If you have enabled Enhanced Database Failover option for any Availability Group along with automatic failover configuration then this option will trigger failover to a synchronized secondary replica in case any database participating in that availability group is no longer able to write transactions.

You cannot set this option for specific databases within availability group. Enhanced database failover or database level health detection will be enabled at availability group level. Once you configure it, all databases participating in that availability group can use this feature to trigger failover if anything goes wrong with them.

Configure Enhanced Database Failover to Availability Group

We can set this option as per our choice or requirement either by using GUI Wizard or by using Transact-SQL. As of now, you cannot configure Enhanced Database Failover option using PowerShell cmdlets. Remember, by default, enhanced database failover option is disabled. If you want to use this feature, you need to enable it. Here, I will explain how to enable Enhanced Database Failover to an Availability Group while its creation and to the existing one.

If you want to check whether an availability group has enhanced database failover enabled or not then we can use dynamic management view sys.availability_groups. You will see a column named db_failover in this DMV. If the value of any availability group is showing zero then it means this feature is disabled and if value shows 1 then it means it’s enabled. You can execute below command to get the settings for all availability group.

select name, db_failover from sys.availability_groups 

Enable Enhanced Database Failover using GUI in SSMS

We can enable this option while configuring availability group or later to the existing availability groups that was already created without enabling this option. As we know there are two ways to create an availability group using GUI in SSMS. One is by using New Availability Group dialog box and another way is by using Availability Group wizard window. Enabling this option is quite same in both ways. To enable enhanced database failover, select its checkbox next to Database Level Health Detection as shown in below image.

You can get this window by following given steps. In SQL Server Management Studio, connect to your SQL Server database engine. Right click on the AlwaysOn High Availability node, and run the New Availability Group Wizard. Check the Database Level Health Detection checkbox on the Specify Name page. Then complete the rest of the pages in the wizard.

Another way to enable this option for existing availability groups are given below. Launch Properties window of existing Availability Group in SQL Server Management Studio. Here, you can see this option as shown in below image. Check the option Database Level Health Detection, then click OK to apply the changes.

Enable Enhanced Database Failover using T-SQL

We can enable enhanced database failover using T-SQL during availability group creation or after creation by running ALTER AVAILABILITY GROUP statement. To configure it during the creation of an availability group, we must set DB_FAILOVER to ON as showing in below command. I have highlighted this in green colour.

CREATE AVAILABILITY GROUP [AG_Techyaz]
WITH (DB_FAILOVER = ON)
FOR DATABASE [Techyaz]
REPLICA ON
       'SQLInstance1' WITH (ENDPOINT_URL = 'ENDPOINT ADDRESS:PORT-Number', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
   'SQLInstance2' WITH (ENDPOINT_URL = 'ENDPOINT ADDRESS:PORT-Number', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)

If you have already created availability group without enabling this option then we have also an option to add this behavior to existing availability groups by using ALTER AVAILABILITY GROUP command as given below.

ALTER AVAILABILITY GROUP [AG_Techyaz] SET (DB_FAILOVER = ON)

Disable Enhanced Database Failover using T-SQL

We can disable this option simply by running below command. We must set DB_FAILOVER value to OFF to disable this feature.

ALTER AVAILABILITY GROUP [Techyaz] SET (DB_FAILOVER = OFF)

You will see error message 41653 logged in SQL Server error log if an availability group has failed over due to the database level health detection checks.

Cautions

It is very important to understand how enhanced database failover or database level health detection works. This option does not monitor disk uptime or database file availability to trigger failover.

Suppose your database is idle with no active transactions, and with no physical writes occurring and some of the database files become inaccessible in between then this option will not trigger automatic failover. Later, when a database checkpoint occurs, or a physical read or write occurs for fulfilling a query, then SQL Server may then notice the file issue, and react by changing the database status, and subsequently the availability group with database level health detection set on would failover due to the database health change.

As another example, when the SQL Server database engine needs to read a data page to fulfill a query, if the data page is cached in the buffer pool memory, then no disk read with physical access may be required to fulfill the query request. Therefore, a missing or unavailable data file may not immediately trigger an automatic failover even when database health option is enabled.

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

Read More:

• How to Patch SQL Server Failover Cluster Instance Running with Always on Availability Group?
• SQL Server Alwayson Interview Questions & Answers
• Understanding Backup Preferences in Alwayson Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• Fixing Application connectivity Issue after AOAG automatic failover

The post What is Enhanced Database Failover and How to Enable it for Availability Group? appeared first on Techyaz.com.