We are migrating from our legacy SQL Server 2017 on Windows 2016 host to SQL Server 2019 on Windows 2019. In above migration the bigger change has been the difference in timezone between legacy and new build Windows host. Earlier we used to have mix of CST, EST and PST servers being built but now everything is standardized under UTC. Me being DBA, trying to understand possible impact with above change. Few questions here: 1. What impact if any is expected for queries querying with getdate(), will they impact DB queries as time is now in UTC? 2. AD team said they can force application to send ET at their end but how will it handle sql querying when landing to DB? 3. All the databases in question here uses partitioned tables with partition functions as date ranges and lot of ad-hoc queries are done on read replica. Will there be impact or change to partitions?

We had a set of long-time Oracle 12c Database installations (multiple instances on separate VMs) on Windows Server. Over the past year we transitioned to Oracle 19c on Windows Server 2019. We found that database links that worked in the 12c environment did not work in the 19c environment; a query referencing such a link would fail with the error ORA-12631: Username retrieval failed. SQLNET traces showed

naun5validate: SPP is NEGOTIATE 

naun5validate: SSPI: 0x8009030c error in AcceptSecurityContext

I have PostgreSQL 15 installed on a Windows Server 2019 Standard VM. I've installed pgSQL using the default configuration on the C:\ drive. I'm currently using the default data directory of C:\...\data. I also have a D:\ drive that I would like to create pgSQL DBs on. I don't want to move the default ...\data directory but only want to create new DBs in the D:\PostgreSQLData directory, which is on the same VM. I didn't see any solution in my initial search on this site. If such solutions already exist here or elsewhere, please send me the link. Otherwise, what are the steps to do this?

I have run into a scenario for a production server where **I was recommended to create a separate drive for each one of the bigger clients** (based on database sizes) whereas all other smaller clients can be placed on the same drive in Azure VM for better performance. Eg: - Client 1 has 800GB size (data file) - Client 2 has 900GB size (data file) - Client 3 has 50GB size (data file) - Client 4 has 40GB size (data file) We already have - 1 separate drive ****D:** for temp db** (both .ldf and .mdf are stored on drive D) - and 1 separate **drive E: for log files** (all .ldf file for all clients is stored here on E:) - and I was recommended to create a Drive F: for Client 3 and Client 4 (to store data files whereas their log files are already stored in E:), - Drive G: for Client 1 (to store data files whereas their log files are already stored in E:) - and Drive H: for Client 2 (to store data files whereas their log files are already stored in E:). Can this increase performance? Also, if I need to add a disk (Premium SSD) for 1 TB, would it be good if we use 256*4 or 512*2 or a single 1 TB disk? Please let me know if anyone has any experience with this.

Can I change the password of the domain account which I used to create the failover cluster? Will it affect the cluster at all? I have also created the Always On availability groups using that domain account, will it be affected? Regards.

We set up a distributed failover cluster with 2 Windows Server 2019 Datacenter nodes, each of them running SQL Server 2019 Enterprise + SSMS18. - The two nodes are located in two different sites with two different IP-Subnets. - Each Host is a ESXI VM with only one NIC (Host A in Subnet A, Host B in Subnet B). - Both sites are connected via a S2S-VPN Connection and routing possibilities for traffic between. **Problem** We double checked every possible problem, but we cannot get managed, to manual failover an AvailabilityGroup with a synchronized DB via SSMS - **Instance** -> Always On High Availability -> Availability Groups -> -> Right-Click "Failover" - SQL Server error 41131 (see attachment) **Troubleshooting** * Connection between hosts is up and the "dashboard" shows, that both hosts are communicating, up and synchronized. * Defender Firewall rules are there for the DAG-listeners, the Agent, the Browser service. On a PaloAlto Firewall at site A, traffic can be detected between both SQL hosts, but no traffic is denied. * Both hosts run via a separate service user for SQL Server Agent and SQL Server engine, so there should not be any trouble with missing rights for the NT Authority\SYSTEM. Rights to the AD-Clusterobject are there, to create and update any child objects. Two DNS entries for the listener and one for the cluster object are also there after the creation. Even the automatic seeding between both hosts is working, only the failover through SMSS18 is failing (inserted rows replicate from host A to host B). **Questions** Are there any ideas, at which point we can troubleshoot? I attached the , but was not able to find any useful information online, since the only connected solution is always to change rights for the NT Account, which we do not use for Agent or Engine.

Dynamic quorum and dynamic witness are abilities of the WSFC to dynamically adjust the vote of the nodes and witness to prevent unnecessary failovers. Where can I check whether the WSFC configuration is configured such that it performs dynamic quorum and dynamic witness?

We have a problem with the Launchpad Service shutting down and doesn't come back up. The service is has startup type "automatic", but when the server is restarted, or the sevice is stopped for some other reason, it's unable to start Launchpad Service back up. The service is ran by our own service account to get the proper rights (and not by Local Service/System). Every time this happens (which is about once a week) we have to go through the following procedure: 1. Enter the SQL Server Configuration Manager 2. Try to start Launchpad Service - which fails 3. Change the account to Local Service 4. Try again to start Launchpad Service - now it starts 5. Change the account back to our own account 6. The service is restarted and now it's working This is the system we are running: - Windows Server 2019 Standard 10.0, Version 1809 (OS Build 17763.2458) - SQL Server 2019 15.0.4178.1 This did not occur before when running on Windows Server 2016 and SQL Server 2016. So it seems to be some bug in the later Windows Server/SQL Server versions. Has anyone else experienced this? Any ideas of how to solve this? **Additional information:** When trying to start the service again this popup appears: "The request failed or the service did not respond in a timely fashion. Consult the event log or other applicable error logs for details." In the event log there's one System log containing: "The SQL Server Launchpad (MSSQLSERVER) service terminated unexpectedly. It has done this 2 time(s)." And a bunch of audit failure secutiry logs: We have tried to give the service account all the required priveliges. When the service is restarted in step 6 we also get the same Security event logs but no error popup and the service is starting and running as it should.

I have an Azure AO AG which consists of three servers (all WS-2019 & SQL-2019 CU8): - A - Subnet 1 - Principal Server (Sync) - B - Subnet 1 - Secondary Server (Sync) - C - Subnet 2 - Secondary Server (Async) I have created a DNN Listener on the resource which looks to be up an running but when I connect to the Listener it resolves to server C. I have confirmed that in the cluster and AG, server A is the principal. I have tried failing over to server B which seems to work fine but the listener still only resolves to Server C. I pulled out the Cluster Logs and I have a warning that jumped out to me that does not seem to appear on google: 2020/11/12-15:27:48.720 WARN [RES] Distributed Network Name : Configuration: Obtaining exclude networks failed with error 2.

I am trying to build a SQL Server AlwaysOn Availability Group with 2 nodes in Azure. I have created 2 SQL Server VMs and Managed to create a Cluster with both Nodes as members of that cluster.  I have followed the steps in this Article of building the Windows Clusters https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/availability-group-manually-configure-tutorial with 1 significant change, I used powershell to create the cluster.  New-Cluster -Name SQLClusterName -Node ("SQLNode1","SQLNode2") –StaticAddress 172.100.10.100 -NoStorage -ManagementPointNetworkType Singleton Because, if I used Failover Cluster Manager to build the cluster it did not created Cluster Core Resources and I did not gave me the option to select an IP for the cluster.  Anyway, once the cluster has been configured, I tried to configure AlwaysOn Availability Group, but the wizard fails to create Always on Availability Group, complains about it cannot connect to the Cluster.  I went on both Nodes and what I have realised is that I can ping to the Cluster Name or IP and get a response only from the Owner Node. From the cluster Non-owner node I could not ping the cluster name or IP. If I failover the cluster to the 2nd node the I ping behaviour will be contra versa. Has everyone else experienced this issue? Is so, how you managed to resolve it? Any help or a pointer in the right direction is much appreciated. Thanks in advance.

I have SQL Server 2019 Express Edition (CU8) on Windows Server 2019 (1809 version) and all of my queries go serial with NoParallelPlansInDesktopOrExpressEdition in NoparallelPlanReason property. Is it that Express Edition never goes parallel? I cannot find anything about this in Microsoft documentation.

Currently we have a number of Servers that are using Windows 2016 with SQL Server 2017. The support team want to do an in-place upgrade of the OS to 2019 due to 2016 Mainstream support ending in Jan 2022. I don't want to upgrade the SQL Server versions, so I am wondering if it is Ok to just upgrade the OS? I will obviously be taking backups and the like but just wanted to know if there were any gotchas I should be aware of before agreeing with the OS upgrade? Thanks

I am currently investigating on how to setup a SQL Server ***stretch*** cluster in combination with storage replication for which I want to use Windows Server Storage Replication. However, I am no sure on how to configure the storage replication exactly and maybe you can help. :-) I do not want to use Always On Availability Groups. In the end I want to use DTC and that does not seem to be supported in combination with Always On or SQL Server mirroring. The purpose of my setup is to have SQL Server highly available on site A and have a DR copy on site B, which also needs to be highly available if that is made active in case of a fail over. I configured a stretch cluster and that works fine, but I am struggling on how to configure the storage replication in combination with the CSVs. I cannot find any documentation on the complete setup. I can find docs (MS and community) on how to configure Storage Replication in combination with Scale Out File Server or Hyper-V, but that does not talk on how configure the CSVs exactly and how to fail over to the other site. Every document says regarding the storage something like 'You need manual intervention to fail over'. I have read some documentation from Dell and HPE on how they use their storage replication solution, but that does not give me those details. How and what exactly you need to do on the Windows cluster side is not described. Secondly, they use their own mechanism to make sure the storage blocks are synced in the correct order. I have 2 scenario's I tried, but these fail. I use my home lab here, so all servers are VMs and therefore use VHDs themselves. So the physical disk in scenario A, for example, is a VHD of a file server VM. All servers use Windows Server 2019. Scenario A: - Configure Storage Replication between a physical disk on iSCSI target server A and B - Create 2 iSCSI disks on that physical disk and make them CSV in the cluster In this scenario the physical disk will replicate the blocks of the iSCSI disks to the other site. This works fine, but there are several issues if I understand correctly: 1. The iSCSI disks on Site B cannot be added to the cluster, because they are read-only (not even visible) due to the Storage Replication configured. 2. In order to fail over, I cannot stop the cluster, switch the replication direction, add the iSCSI disks on Site B as CSV to the cluster. It seems that I need to remove the LUNS first and delete the iSCSI CSV disks from Site A from the cluster? Then add them again at Site B? This seems very cumbersome to me, but maybe this is how this should be done in order to fail over? Or am I missing something here? Scenario B: - Configure Storage Replication between CSVs In this scenario I create some iSCSI disks and add them as CSV to the cluster. That works fine. Then I wanted to configure replication via the Failover Cluster Manager. First add them as CSV, then right click on one and select 'Replication'. This scenario fails, because it tells me that the disks are not of the same size. However, they are exactly the same size (I use the same Powershell command to create them) and are formatted with the same NTFS Allocation Unit size. Maybe I am missing something here? So basically my question is how I can get Windows Server Storage Replication to work correctly in combination with the cluster configuration I am using?

We're running a couple SQL servers in Azure that are set up with an Always On availability group and Windows Failover Clustering. The servers are Windows 2019 and we're running SQL Server 2019. When we set up the cluster, it was set up to use a Distributed Network Name instead of a static cluster IP address. Thanks to this we shouldn't need an internal load balancer according to these notes: https://github.com/MicrosoftDocs/azure-docs/issues/34648 . I'm struggling to understand exactly how this works though. Based on what I read, it seems like our connection strings will point to the DNS name of the cluster (let's call it AgCluster). If I look in DNS, there is an A record for AgCluster pointing to sql1 and another pointing to sql2. When I use AgCluster in my connection string it seems to always connect me to the primary server, even if I have ApplicationIntent=ReadOnly set. When I query @@SERVERNAME I always get the same server. So with the Distributed Network Name setup, what should I use in my connection strings to make sure read/write queries go to the primary and read only go to a secondary? Any guides on setting this up in general would be helpful. Thanks!

I have an issue with SQL Server that is really driving me nuts so I wanted to ask if anyone has any suggestions. I have a program that does a daily backup of the SQL Server database. This has worked for two years. Now, today, we had to upgrade our server and along with this update (now Windows Server 2019 Essentials), we upgraded to SQL Server 2019 Express. Now, when I try to perform the backup, I get the error: > Cannot open backup device '\\\\SERVER\\DIRECTORY\\BACKUPDIRECTORY\\Backup_Wed.BAK'. Operating system error 5(Access is denied.). > BACKUP DATABASE is terminating abnormally. I know that this error generally means that SQL Server doesn't have read / write access, but the issue I have is that it DOES. This IS the SQL Server Instance, as you can see here: AND, if I run a backup from within SQL Server Management Studio, this does succeed... I also checked to make sure that the file and it's contents weren't set to "Read Only" and they're not. Those are the only two causes I'm aware of and all I was able to find searching online over the past several hours. There's plenty of room on the drive as well (As I said, it's brand new and there's little on it). Has anyone else seen anything like this or know what else might cause this issue? The old SQL Server version was the prior version, so I wasn't upgrading from some ancient release either. And here's my SQL that has worked for several years. I can't find anywhere where SQL Server 2019 changed the requirements here either: BACKUP DATABASE THEDATABASE TO DISK = '\\\\SERVER\\DIRECTORY\\BACKUPDIRECTORY\\Backup_Wed.BAK' WITH INIT I'm at a loss... If SQL Server has access permissions on the directly, how can it NOT have permissions on the directory? Also, just to clarify, this is a local directory. SQL Server is on the server and is attempting to backup to a directory ON the server. Is this a bug in Windows Server 2019? I really appreciate everyone's help and sincerely hope that someone knows a solution here. Thank you again.

We want to set up a second instance/server of SQL Server such that both instances will be kept in sync. The reason is we need to separate some users and processes out to a separate server for business reasons. More information (requested in comments): - Neither instance would be read-only - It does not need to be synced in realtime, but that would be nice - We have full control of the table schemas We've done a lot of research, but most potential options are part of disaster recovery features, so we're not sure if those are right for this. I'm not sure how to whittle down this list without actually trying the different options, but that would be very time consuming. If there's an option I'm missing, that would be very helpful. Always On Availability Groups
Merge Replication
Database Mirroring
Synchronize Data
Windows Server Failover Clustering with SQL Server (Is this what is normally meant by clustering?)

I am encountering an issue with the SQL Browser service where the service will start, run for around 60-90 seconds and then stop. No error is logged, the event logs show three informational entries: > The SQL Server Browser service has started. > > The SQL Server Browser is enabling SQL instance and connectivity discovery support. > > The SQL Server Browser service has shutdown. Things I've tried so far: - Removing and reinstalling SQL Browser. - Repairing the SQL installation. - Changing the logon account for SQL Browser. - If I run the browser in console mode from the command line (sqlbrowser.exe -c) then it runs fine and does not shut down. - Verified no antivirus is terminating the service. - Turned off Windows Firewall just to be sure. - Restarted machine. - Applied latest updates. I've run out of ideas. Is there a log file for the Browser service somewhere that might give some clues? Has anyone encountered this issue before? SQL: 2017 Standard Edition Windows: 2019 Core Installed Features: SQL Engine, SSRS, Integration Services, Browser