• 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.

One thing we should always keep in mind that if we change database default path in SQL Server then it will not change or move the database file locations for your existing databases. If you want to move all existing databases or you want to change database files path to the new location then you need to manually do it for each database.

Once you will change default database file locations then all databases you will create on that SQL Server Instance will be created on new location. Suppose your existing SQL Server default database location is set in C drive and now you have decided to change it to D drive for data files and F drive for Log files then all databases you will create post this change will be created in these both drives. If you will mention any other specific drive during database creation then SQL Server uses that drive and not these database default locations. The SQL Server data file will be created in D drive and log file will be created in F drive but all the existing databases that were created earlier in C drive will not move to new SQL server database file location. If you want to move these databases or want to change database files location then you need to manually do it either by detach-attach method or by ALTER statement.

Change Database Default Locations in SQL Server

It’s very simple method to change default log file location or default data file location in SQL Server. Let’s start to change default database path in SQL Server.

• Launch SQL Server Management Studio and connect to your SQL Server Instance for which you must change default log file location or default data file location in SQL Server.
• Now right click at SQL Server Instance node and choose Properties option.
• You will get server properties window on your screen. Click at “Database Settings” from left side pane. You will get all server level details for SQL Server databases in right side pane. Look at the database default locations option given bottom of the right-side pane. Here you can see separate default location for data files, Log file and backup files.

• You can see database default locations for each file are showing in C drive. It means every database that will be created without mentioning their data or log file location will go to above given SQL Server database default locations.
• To change database default path, you need to browse current database default locations for each file to new the new location. Click at three dots showing next to data file or log file locations and then select the new path.
• Repeat same exercise for each file. To change default data file location, click at three dots next to data path and select new path here. Similarly, click at three dots next to log file location to change default log file location. If you want to change default backup file location then do the same for backup location as well.
• Click ak Ok button once you made changes for desired database file locations.
• Last step is to restart SQL Server services to apply this change and bring it into effect.

Once you will restart SQL Server services, your SQL Server default database location will be changed to the new path. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Get Total Number of Virtual Log Files in SQL Server Transaction Log File
• SQL Server Error 1105: Could Not Allocate Space for Object in Database because the filegroup is full
• How to Change SQL Server Instance Name?
• Why Should You Always Turn Off Database Auto Shrink Property?

The post How to Change Database Default Locations in SQL Server? 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.

• 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.

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.

There are many ways to check SQL Server installation date on your machine. Here i am going to discuss two popular methods that we can use easily to get install date of SQL Server. Let’s go one by one in step by step process.

Method 1

As we know whenever we install SQL Server, a SQL Server Agent job named “syspolicy_purge_history” got created. The install date of SQL Server instance will be same as the create date of this job because this job was created during SQL Server installation. So, if you need to find when SQL Server was installed on your database server then you can get it by create date info of above job. Follow below steps to get the details.

You can expand SQL Server Agent folder in SSMS and then Jobs folder. Here you can see this job. We can launch Properties window of job “syspolicy_purge_history” or you can query msdb database to get the details of this job. Here, I have launched Properties windows of this job and we can see the create date of this job is below screenshot. It means this SQL Server Instance was installed on 27^th July 2017 as showing as create date of below job.

Method 2

Another method to get SQL Server install date on your database server is by using SQL Server system logins. These system logins get created when we install SQL Server. Some of the system logins are NT SERVICE\SQLWriter, NT Service\MSSQLSERVER, NT AUTHORITY\SYSTEM and NT AUTHORITY\NETWORK SERVICE. You can also see some of the system logins that starts with hash # like ##MS_Policy***** etc. As I said these logins get created during SQL Server installation so to get SQL Server installation date we can check the create date of any such logins.

You can run below commands to check the create date of any of system logins. I have executed below commands to check create date of three system logins.

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT SERVICE\SQLWriter'
GO

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT Service\MSSQLSERVER'
GO

SELECT name, create_date
FROM sys.server_principals
WHERE name='NT AUTHORITY\SYSTEM'
GO

We can see create date of all above SQL Server system logins are same as the create date of system job “syspolicy_purge_history” that is described in method 1. So, SQL Server install date on this database server was 27^th July 2017 as shown in below image.

You can also get SQL Server install date by getting update date of system account sa. As we have disabled sa account as part of SQL Server hardening so last update was captured when we disabled this account. But this does not show correct info always because if anybody has enabled this account and again disabled it then this will give you inaccurate information but you can use this information to compare the update date information with the create date of other logins and jobs. This will help you in identifying the install date of SQL Server in more accurate manner.

SELECT *
FROM syslogins
WHERE name='sa'
GO

SELECT *
FROM sys.server_principals
WHERE name='NT AUTHORITY\SYSTEM'
GO

You can see the update date of sa account and create date of the another system login shows same date that is also the SQL Server Installation date.

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

Read More:

• SQL Server Evaluation Period has Expired and How to Upgrade it?
• Create a Logon Trigger to Restrict sysadmin logins to Connect to SQL Server during a given time Interval
• SQL Server Interview Questions & Answers

The post How to Find When SQL Server was Installed? 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.

Let’s start with the basics. MSDN says “Trace flags are used to temporarily set specific server characteristics or to switch off a particular behavior. Trace flags are frequently used to diagnose performance issues or to debug stored procedures or complex computer systems.”

There are two types of trace flags in SQL Server.

• Session
• Global

We can enable trace flag for the context of a specific query that we can run under a session. Session trace flags can be enabled for a connection and are visible only to that connection. This type of trace flag never affects another session running on your database server and the effect of the trace flag is lost when that connection logs out.

Global trace flags are set at the server level and must be enabled globally. If you will try to enable global trace flag for a particular session then there will not be any impact of this trace flag. Let’s go ahead and understand how we can check the status of trace flags running on your SQL Server instance.

Check Trace Flag Status

We use DBCC TRACESTATUS command to check all running or active trace flags on database system. We can also check the status of a specific trace flag using this DBCC command. The output of this DBCC command has four columns. First column is the trace flag number, second column shows the status of trace flag, third and fourth columns are showing whether the trace flag is enabled at the global level or session level.

The status column of this DBCC command has two values. The value shows whether the trace flag is ON (1) or OFF (0). You can see the below screenshot to understand the trace flags and their status.

DBCC TRACESTATUS

We can run above DBCC command in different ways to get distinct outputs about trace flags status. Here, I am giving you few examples to use DBCC TRACESTATUS command.

Run below command to display the status of all trace flags that are currently enabled globally.

DBCC TRACESTATUS(-1);  
GO

We can even get status of multiple specific trace flags by executing below command. Run below command to get the status of trace flags 8690 and 1118.

DBCC TRACESTATUS (8690, 1118);  
GO

If you want to list all the trace flags that are enabled for the current session then you can get it by running below command.

DBCC TRACESTATUS();  
GO

If you want to check whether trace flag status for specific trace is enabled globally or not then you can run below command.

DBCC TRACESTATUS(8690, -1)

Enable Trace Flag

We enable trace flags to gather more information about certain logs during some transactions. We use DBCC TRACEON command to enable SQL Server trace flags. Here, I will show you different uses of DBCC TRACEON command to enable trace flags.

Remember, all trace flags enabled using DBCC TRACEON command will be disabled once you restart the SQL Server service. If you want to enable any trace flag permanently then we recommend that you should enable them at startup, by using the -T command line option. This ensures the trace flag remains active after a server restart. You can launch SQL Server Configuration Manager and open the Properties window of SQL Server service. Here you can click on Startup Parameters tab. Here you can add your trace flag number along with -T and then click on Ok button to close the window.

If we need to enable a trace flag globally then we need to run below command with -1 option as shown in below screenshot.

DBCC TRACEON (8690, -1)

Now we can check the trace flag status whether it’s been enabled globally on our database system or not.

If you want this trace to be enabled for current connection only then you should run below command. You can remove -1 from above command.

DBCC TRACEON (8690);  
GO

Even you can enable multiple trace flags by running single command. You can run below command to enable trace flag 8690 and 1117 globally. If you want to enable it for current connection only then you can remove -1 from below command.

DBCC TRACEON (8690, 1117, -1);  
GO

Run below DBCC command to check the status of the trace flag that we have enabled by running above command.

DBCC TRACESTATUS

You can see trace flag 8690 is showing along with its value set as 1 for session as well as global in below screenshot.

If you want to check trace flag status for specific trace number then you can run below command. Below command will let you know whether trace flag 8690 is enabled globally or not.

DBCC TRACESTATUS(8690, -1)

Disable Trace Flag

Similarly, we can disable trace flag 8690 that we have enabled in above section by executing another DBCC command known as DBCC TRACEOFF. Run below command to disable trace flag. If we will use -1 value along with DBCC TRACEOFF command that means it will disable this trace flag globally.

DBCC TRACEOFF(8690, -1)

If you want to disable it for current connection only then we will remove -1 from above command and run below command.

DBCC TRACEOFF(8690);   
GO

Now we can again check the status of trace flag 8690 whether this trace is still active or it has been deactivated by above command.

DBCC TRACESTATUS

We can see trace 8690 is disabled now and this trace flag cannot be active in below image.

If you want to check trace flag status for a individual trace then you can run below command.

DBCC TRACESTATUS(8690, -1)

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

Read More:

• Find Total no of Running Traces files on your Database Server
• Understanding Database Shrink Operation
• How to Avoid Page Split in SQL Server?

The post How to Enable, Disable or Check SQL Server Trace Flags? appeared first on Techyaz.com.

The server network address “TCP://ServerName.abc.local:5022″ cannot be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (Microsoft SQL Server, Error: 1418)

Reason behind Error 1418

Main reason behind database mirroring error 1418 is because the specified server network address cannot be reached or does not exist. The server network address cannot be reached because of multiple reasons. Some of them are given below.

• Principal, Mirror and Witness servers are not talking to each other.
• Wrong network address name, mirror server instance name or port number.
• Mirror database is not ready for mirroring.
• Principal or mirror server instance is behind a firewall.
• You are using local system account to run SQL Server services and not using certificates for authentication.
• SQL Server services are running with different domain accounts on Principal and Mirror server and service accounts don’t have enough permission on endpoints.
• Different endpoint encryption value set on Principal, Mirror and Witness server.
• Endpoints are not started on the partner servers.
• Principal server instance is not listening on the port assigned to its database mirroring endpoint.

We need to verify each option mentioned above carefully to fix this error.

Solution

The solution of this issue may vary case to case depending on the nature of issue. To fix this issue we need to find out the main root cause behind error 1418. The root cause may be anything that is given in above section. Here I will describe each probable reason given above and its solution to fix this issue. Make sure to go through with each point given in this article.

Principal, Mirror and Witness Servers Should be Accessible

Make sure that SQL Server Instances installed on Principal, Mirror & Witness servers are accessible to each other. If remote login for any SQL Server instance is not enabled then you might get this issue. You can enable remote connectivity by enabling TCP/IP and Named Pipes protocols in SQL Server Configuration Manager. Each system must access the ports of the other SQL Server instances over TCP. You can try telnet the SQL Server ports of other partners.

Verify Correct System Details 

Sometimes we entered wrong details that end up with throwing errors. Make sure to verify the network address name, mirror server instance name and its port numbers are correct. You can recheck all the details whether you have entered them correctly or not.

Mirror Database Preparation

Verify that the mirror database is ready for database mirroring. We should prepare mirror database before configuring or during configuring database mirroring. It is suggested to keep identical drive path for mirror database files. Below are the steps you should take care for preparing your mirroring database.

• Run full backup and subsequent transactional log backup of the Principal database and copy it to the Mirror server.
• Restore database with same name in norecovery state on Mirror server with the copied backup files from above step. You must ensure that restored database on mirror server should be in restoring mode before starting database mirroring configuration.

Firewall/Ports

One of the probable reason to get error 1418 is partner servers are behind firewall. Make sure that the principal server instance and destination mirror server instance is not behind a firewall and they should talk to each other. Principal server, Mirror server and witness server should be accessible to each other.

Verify that SQL Server port and endpoint ports are enabled and accessible via telnet. If not or you are not able to telnet any of the partner instance from any server participating in mirroring then you should ask your network admins to open these ports to establish the connectivity over given port.

Endpoints

Make sure that endpoint has been created on principal, mirror and witness servers. Verify that the endpoints are started on each partner server instances. You can check endpoint status by running below T-SQL query on each instance.

SELECT state_desc FROM sys.database_mirroring_endpoints

If either endpoint is not started, execute below ALTER ENDPOINT statement to start it.

#Change the name of your endpoints. Here endpoint name is Mirroring
ALTER ENDPOINT Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT = <port_number>)
FOR database_mirroring (ROLE = ALL);
GO

Recheck that the principal server instance is listening on the port assigned to its database mirroring endpoint and the mirror server instance is listening on its port. If a partner is not listening on its assigned port, modify the database mirroring endpoint to listen on a different port.

Sometimes this issue got fixed by dropping the existing endpoint and recreate it again on partner servers.

Service Accounts

Do not use local system account to run SQL Server services. If you don’t have any choice and want to use local system then ensure to use certificates for authentications.

Make sure that service accounts that you are using to run SQL Server services must have CONNECT permission to mirroring endpoints. Also, if you are configuring database mirroring between two domains then the login of one account must be created in master database on the other computer, and that login must be granted CONNECT permissions on the endpoint.

It’s always advisable to use same service accounts to run SQL Server services on all three Instances on Principal, Mirror and Witness server.

You can comment us your experience about fixing this issue. We will update this article with your solution that you have used to fix this issue.

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

Read More:

• Fix Error 15141: The server principal owns one or more endpoints and cannot be dropped
• Fix AOAG Error 35250: Joining database on Secondary Replica resulted in an error
• How to Upgrade or Patch Availability Group Instances?
• SQL Server Always On Interview Questions and Answers

The post Fix Error 1418: The server network address cannot be reached or does not exist. appeared first on Techyaz.com.

There are two ways to perform shrink operation on your SQL Server databases.

Automatic Shrinking

Automatic Shrinking can be enabled by setting Auto_Shrink database property to ON. SQL Server database engine will automatically perform shrink database operation on your database whenever required. Unless we have a specific requirement, we should not set the AUTO_SHRINK database option to ON because it degrades your database performance. SQL Server shrink database files also increases IO overhead that leads to poor performance. Read below article where I have explained how this option degrades database performance and why we should not set Auto_Shrink database option to ON.

• Why Should You Always Turn Off Database Auto Shrink Property?

Manual Shrinking

We can use DBCC SHRINKDATABASE or DBCC SHRINKFILE statement to manually shrink database log file or data file within a database. Shrink database operation runs at file level. When you use DBCC SHRINKDATABASE, it also shrink the size of data or log files. We can stop the execution of DBCC SHRINKDATABASE and DBCC SHRINKFILE operations at any point in the process, and any completed work is retained.

One question most of the DBA ask that should we shrink database or should we shrink database log file or data file in SQL Server?The answer of this question is simple, we should not perform shrink operation regularly. Database Shrink operation is resource intensive operations because data pages are moved from the end of the file to unoccupied space closer to the front of the file. This process put pressure on system IO and CPU and also causes high fragmentation. You might also face some blocking issues during the shrink operation. That’s the reason it’s not recommended to shrink data file or log file on frequent or routine basis. SQL Server shrink database files should be avoided.

We should generally perform shrink operation if we truncate or drop table or tables from the database. If we remove or purge bigger chunk of data from your database then also we can perform shrink operation to reclaim the unused space to the disk. Always leave some space to the database to perform its routine operations. Most databases require some free space for regular day-to-day operations. Do Not Shrink such databases and their database files because databases will again allocate required space for their operation. Make sure to rebuild your indexes post database shrink operation if you need to perform it.

Also you should keep this in mind that we cannot shrink a database while the database is being backed up. Similarly, you cannot backup a database while a shrink operation on the database is in process. Here you have learnt about SQL Server shrink database files.
I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the best value for database file autogrowth?
• Fix SQL Server Error 5144 and 5145: Failed Data or Log file Autogrow Operation
• Fix Error 3023: Shrink failed for Log file

The post Understanding Database Shrink Operation and Why Should We Avoid It? appeared first on Techyaz.com.

Recently, one of the SQL Server Instance suddenly stopped working and shutdown automatically. We failed to bring its services online. Even we were not able to launch SQL Server Management studio. When we checked windows event viewer, we had seen multiple event ids for SQL Server like Event ID 7024, Event ID 17051 etc. We got this error because SQL Server evaluation period has expired for this instance.

As I said, SQL Server was down and I tried starting it from SQL Server Configuration Manager. It never come online so I decided to check Windows event viewer. I saw event id 7024 that says something wrong with application SQL Server. You can see the screenshot of event id 7024.

We can see error 17051 is captured for SQL Server in above screenshot. When I scrolled next error details I saw below details with event id 17051 that says “SQL Server evaluation period has expired”. When you look into SQL Server error log, you will get below details.

Error: 17051, Severity: 16, State: 1.
SQL Server evaluation period has expired.

Then I decided to check the installed version of SQL Server that clearly says that we had installed SQL Server Evaluation version on this database server. You can get it by launching property window of SQL Server service in SQL Server Configuration Manager. You can see this in below screenshot.

Now we had to upgrade SQL Server evaluation edition to bring it online and make it work as it was working before. To start this, we need SQL Server setup files to perform this upgrade. Follow below steps to activate your expired SQL Server evaluation version to either standard, enterprise or developer edition.

Upgrade SQL Server Evaluation Edition to Enterprise Edition

First decide on which edition you want to upgrade your expired SQL Server evaluation edition instance. Copy identified edition of SQL Server setup files to the target or impacted SQL Server machine. Now we will launch SQL Server Installation Center to run this upgrade. Make sure to run this whole process using sysadmin account.

Double click on Setup.exe file to start the upgrade. You will get SQL Server Installation Center once you run setup.exe file of SQL Server setup. Click at “Maintenance” tab from left side pane as shown in below image and then click on “Edition Upgrade” option from right side pane.

Once you click at Edition upgrade, below image will come to proceed. This screen will come to enter the product key of SQL Server. Verify the correct product key and click on next button to proceed.

Once you click at next button you will get below pop up “Evaluation period has expired”. Click on Ok button to proceed.

Next screen will come to accept the License Terms. Click at Next button after selecting “I accept license terms” checkbox option.

Here, you will get installed components of SQL Server. Verify the SQL Server instance and click on next button to proceed. You can see edition is showing as Evaluation in below screenshot.

Once you will click at Next button, rules will be checked by the setup and you can see the progress bar in below image.

Now it’s time for final window of this upgrade process where you need to recheck and verify the details and if everything looks good then click at “Upgrade” button to start the upgrade process.

Setup will process and end up with new upgraded edition. You have been activated SQL Server to run it on your server and it has been upgraded to your identified edition of SQL Server i.e Enterprise edition.

You can check the upgraded edition by launching property window of SQL Server service in SQL Server Configuration window. We can see now edition is showing as Enterprise Edition. Here, we have upgraded SQL Server evaluation version to Enterprise edition of SQL Server 2014.

Now you can go ahead and launch SQL Server Management Studio and establish database connection to check and verify all details to make sure everything is ok on your database server.
I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to update License Key or Product Key of SQL Server?
• Fix SQL Server Installation Error 1639
• SQL Server Interview Questions & Answers

The post SQL Server Evaluation Period has Expired and How to Upgrade it? appeared first on Techyaz.com.

A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 – No process is on the other end of the pipe) (Microsoft SQL Server, Error: 233)

You can see the screenshot of this error that I had received while making a database connection.

SQL Server Error 233 No process is on the other end of the pipe – Root Cause

Above SQL error 233 suggests the provider name as Shared Memory Provider. We know Shared Memory is a protocol used in SQL Server along with TCP/IP and Named pipe. We decided to check the settings and values for all protocols in SQL Server Configuration Manager.

I launched SQL Server Configuration manager and expanded SQL Server Network Protocols from left side pane. Here, you can see an option “Protocols for MSSQLSERVER”.  MSSQLSERVER is the name of SQL Server Instance as default instance has been installed there. If you have named instance installed on your machine then you might get “Protocols for <INSTANCENAME>.

Now click on this option “Protocols for MSSQLSERVER”, you can see all three protocols used in SQL Server in right side pane as shown in below image.

Here we can see Shared Memory protocol is set as Enabled but Named Pipes is set as Disabled that should be enabled to make successful database connection. This was the main reason for getting this error. Keep reading this article to fix this issue in next section.

I have also written another aspect of SQL Server Error 233 in below article. You might get this error if your SQL Server Instance has exceeded the total number of user connections set in server configurations. Have a look at this article as well.

• Fix SQL Server Error 233: User Connections Server Configuration option in SQL Server

Solution

We get error 233 ( SQL Server no process is on the other end of the pipe )because SQL Server client cannot connect to the server. This error could occur because the server is not configured to accept remote connections. To fix this issue, we will use the SQL Server Configuration Manager tool to allow SQL Server to accept remote connections. Here, in our case one of the protocol Named Pipe was disabled that’s why we were getting error. We will go ahead and fix this issue by enable the Named Pipe protocol. You might get this issue due to any protocol being disabled.

Make sure to enable Shared Memory, TCP/IP and Named Pipe protocols. Launch SQL Server Configuration Manager. Expand SQL Server Network Configuration from left side pane and click on Protocols for MSSQLSERVER. MSSQLSERVER is SQL Server Instance name. Now you will see all protocols in to right side pane. Right click on given protocols that is disabled and select Enable button to enable that protocols.

Named Pipe protocol was disabled in my case so I have launched Properties window of this protocol and selected Enabled option as Yes from dropdown as shown in below screenshot. Now click on Apply and Ok button to apply this change on SQL Server. It will ask you to restart the SQL Server service to apply these changes in to effect. Restart SQL Server services from SQL Server Configuration manager. Once services will come online, try to connect to your SQL Server instance, this time you will not face error 233 and you will be able to make successful database connection.

If you are still facing same issue ( no process is on the other end of the pipe )then you can also check “Allow Remote Connections” settings for this SQL Server instance. This setting must be enabled to connect to databases remotely. Connect to SQL Server Instance in SSMS locally on database server. Right click on SQL Server instance name in SSMS and choose Properties. You will get Server properties window. Click on Connections from left side pane and tick the check box on Allow remote connections to this server option from right side pane.

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

Read More Articles on SQL Server Connection Issues:

• Fix SQL Server Network Interfaces Error 28: Server doesn’t support requested protocol
• Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server
• Fix Error 53: Could not open a connection on SQL Server
• Fix Error 4064: Cannot open user default database
• Error 233: How to set the user connections server configuration option in SQL Server

The post Fix SQL Server Error 233: No process is on the other end of the pipe appeared first on Techyaz.com.