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.

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

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

Select * from sys.dm_os_performance_counters

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

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

Performance Counters to Identify SQL Server Memory Pressure

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

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

Memory: Available Bytes

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

Memory: Pages/sec

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

Memory: Page Faults/sec

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

Process: Working Set

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

SQL Server: Buffer Manager: Buffer Cache Hit Ratio

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

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

SQL Server: Buffer Manager: Page Life Expectancy

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

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

SQL Server: Buffer Manager: Free List Stalls/sec

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

SQL Server: Buffer Manager: Lazy Writes/sec

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

SQL Server: Buffer Manager: Checkpoint Pages/sec

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

SQL Server: Memory Manager: Memory Grants Pending

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

• Fix RESOURCE_SEMAPHORE Wait Type in SQL Server

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

Read More:

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

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

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

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

Impact of Changing SQL Server Instance Name

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

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

Rename SQL Server Instance

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

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

--Drop existing name
sp_dropserver [old_Instance_name]; 
GO 

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

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

sp_dropserver [old_name\instancename]; 
GO 

sp_addserver [new_name\instancename], local; 
GO

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

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

SELECT @@SERVERNAME

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

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

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

Read More:

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

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

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

Configure Report Server After Renaming SQL Server Instance

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

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

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

Read More:

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

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

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

Error 15190 – Root Cause

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

sp_dropserver <old_Name>; 
GO

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

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

Solution

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

sp_dropremotelogin old_name; 
GO

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

sp_dropremotelogin Old_DBSERVER\Instancename; 
GO

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

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

Read More:

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

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

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

Error 1105 – Root Cause

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

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

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

Solution

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

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

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

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

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

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

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

Read More:

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

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

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

The screenshot of the error is given in below image.

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

Error 15123 – Root Cause

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

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

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

exec sp_configure ‘show advanced options’

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

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

Solution

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

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

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

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

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

exec sp_configure 'xp_cmdshell', 1
 reconfigure with override

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

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

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

Read More:

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

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

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.

Error: 1101, Severity: 17, State: 2
Could not allocate a new page for database ‘DBNAME’ because of insufficient disk space in filegroup ‘PRIMARY’. Create the necessary space by dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

There is another error 1105 that is also very much like above error code. Error 1105 can also be fixed using same solution given in this article.

Error 1101 – Root Cause

Main reason behind error 1101 or error 1105 is the insufficient disk space in filegroup/files. You might also get this error if your database drives are running out of space. There are multiple reasons that can cause this error to generate. Some of them are given below.

• You have restricted database maximum file size or put size limits for files.
• Database file drives are running out of space.
• Autogrowth is not enabled for database files.

Solutions

To fix this issue we need to make space for database files to grow. Issue might vary depending on the nature of issue mentioned in above section. Sometimes, you might face this issue if maximum size for database files are restricted to some values so whenever database will grow to that point, SQL Server will not allow to allocate any page to that database. Sometimes you might get error 1101 because you don’t have any space on your database drives. Here, I will discuss each case individually and its solution to fix it.

Unrestrict or Increase Database File Size Limits

You might have enough space in your database drives but still you can get error 1101 because the maximum file size of database files is limited to some value and that causes not to grow your database beyond that size. You can unrestrict or increase the existing value of maximum file size to some bigger value. We have also an option to set database file size to unlimited size value that means database file will grow till the database file drive limit. Make sure to set appropriate autogrowth size for each database files.

You can set unlimited file size option or increase the value of maximum file size using GUI in SQL Server Management Studio or using ALTER statement.

• Connect to Database Instance in SQL Server Management Studio. Expand Database folder.
• Right Click on your database and choose Property window.
• Click on Files tab from left side pane in database property window.
• Here you can see all database files. Now you can click on three dots given next of database files in “Autogrowth/Maxsize” column. You can see max size is set to a limited value as shown in below screenshot. I have chosen unlimited option and clicked on Ok button.

Now we will not get any issue if our database drive has enough space.

Space in Database Drives

Another possibility for this error is, there might be possibility that your drives on which you have placed your database files are running out of space. If this is the case then you have below 4 options.

• Add additional database file to different disk where there is enough space.
• Move additional/unwanted files from your existing database drives.
• Drop/Purge or Move unwanted data (table/indexes)
• Add Additional Disk Space

Immediate fix of this issue is to add new database file to another drive where you have enough space to run your transactions. You can use below command to add addition database file to another disk.

USE [master]
GO
ALTER DATABASE [DBNAME]
ADD FILE (NAME = N'NewFileName', FILENAME = N'F:\mssql\data\newdatafile.ndf', SIZE = 100096KB, FILEGROWTH = 10240KB)
TO FILEGROUP [SECONDARY]
GO

You can also add new database file in SQL Server Management Studio by launching Database Property Window. Select Files from left side pane and Click on “Add” button showing in below screenshot. Make sure to set autogrowth value carefully for any database file. Also it is recommended to enable IFI – Instant File Initialization to speed up autogrowth process for your databases. Refer to below article to get best value for autogrowth for your database files. You can also read what are the benefits and how to enable IFI – Instant File Initialization in below article.

• What Should be the Best Value for database Autogrowth settings?
• How to Enable Instant File Initialization in SQL Server?

You can also have a look at the existing database drives whether there is any unwanted files or older backup files (*.bak) are not stored. Sometimes we run backups into database drives and forgot to delete or move them. Make sure to drop or move all unwanted files to some other location. Database drives should have only database files.

Final and long-term solution is the data purging. Identify the database objects that are not needed and then plan the data removal or data purging process to make space on your database.

We also have an option to extend the database drives as per the data growth. Make sure to plan this activity carefully before deploying it on production servers.

Enable Autogrowth

I have already written an article on Database autogrowth property setting. Read attached article to find out best value for Autogrowth settings.

You might get error 1101 if you have not enabled authogrowth setting for your database files. You need to enable it by launching database property window. You can click on three dots next to each database files in column “Authogrowth/Maxsize” and click at the enable authogrowth checkbox as showing in below screenshot.

You can also use ALTER statement to enable database autogrowth setting for your database file. Remember, you need to run this ALTER statement for each database file separately.

Run below ALTER command to enable autogrowth for database file.

--Pass logical filename of your database file for under NAME section.
ALTER DATABASE [Techyaz] MODIFY FILE ( NAME = N'Techyaz_Data', FILEGROWTH = 10000KB )

Make sure to enable Instant File Initialization to speedup autogrowth operations. Links to enable Instant File Initialization is attached in this article.

If you are facing this issue for tempdb database then you can consider one more option apart from all of the above options. And this option is to restart SQL Server service if it’s allowed. Keep in mind, SQL Server service restart will cause an outage for few minutes but it will create new tempdb files with initial size and error 1101 will be disappeared. This is not recommended solution because of outage so you should work on long terms solutions.

You can also use above solutions to fix error 1105 that is very much similar to error 1101. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix Error 5144 and Error 5145 for Long or Failed Autogrow of Database Files
• Understanding Autogrowth Operation in SQL Server Databases
• How to Enable IFI – Instant File Initialization?
• Manage Database Files during huge Data Load

The post Fix Error 1101: Could not allocate a new page for database 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.

We had few options to overcome this issue. As we were running this database in simple recovery mode, so we didn’t have an option to run the Transaction Log backup. We tried to shrink the log file to manage transaction log file but it was not allowing us to do so. This might be due to the data load execution was in process and active transaction.

Finally, we left out with two options; either extend the log drive or add a log file to the database on a drive that has enough space to accumulate the logs. Extending the existing drive was not possible because data load was in progress and we need to fix this issue without stopping the import/data load. So, we decided to go with another option that was to add a database log file to a drive that has enough space. I have given you step by step method to add a log file to a database in below section.

Add Log File to a Database

I will show you how to add log file to a database using T-SQL statements and using GUI in SQL Server Management Studio to manage transaction log file during data load. This way you can manage if your transaction log file is growing faster.

Using T-SQL Statement

Open new query window and run below T-SQL statement to add a log file TY1_Log3.ldf to database TY1 on F drive. Have a look at below T-SQL code to get other details like sizing and growth details.

--Replace your Database Name and file details in below T-SQL Code.
ALTER DATABASE [TY1]
ADD LOG FILE (NAME = 'TY1_Log3', FILENAME = 'F:\TY1_Log3.ldf', SIZE = 20080 MB, FILEGROWTH = 5024 MB)
GO

Once you execute above T-SQL statement, your log file TY1_Log3.ldf will be added on F drive to the database TY1.

Remember, add the log file in a drive where you have enough space. If you will add log file to data file drive then you might face IO pressure because both data and log files will be on same drive so avoid to keep data and log file on same drive.

Using GUI in SSMS

1. Launch SQL Server Management Studio and connect to the instance of the SQL Server Database Engine. Expand Databases folder, right-click the database in which you have to add the log file, and then click Properties.
2. In the Database Properties dialog box, select the Files page from left side pane.
3. To add a transaction log file, click Add button from lower right side pane.
4. In the Database files grid, enter a logical name for the file. The file name must be unique within the database. Select the file type as log. Specify the initial size of the file. Set Autogrowth column as per your requirement.
5. Specify the path for the file location along with physical log file name. The specified path must exist before adding the file. Make sure that your drive has enough space to host this log file.
6. Click on OK button to create this add this log file to the database.

Once you performed step 6, log file will be added to your database on your identified drive name. These exercises (adding log file to database) doesn’t require any downtime or it will not interrupt any existing transactions. This way you can manage transaction log file during data load if your transaction log file is growing faster.

Read More

• How to get Total no. of Virtual Log Files in a Transaction Log file?
• Understanding Transaction Log File Architecture
• Why Should You Always Turn Off Database Auto Shrink Property?
• What is the best value for database file autogrowth?

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

The post Manage Transaction Log File during Data Load appeared first on Techyaz.com.