I have just built a SQL Server 2022 Always on Availability group with 3 Nodes at HQ and 1 Node at DR. During our testing phase I have noticed every time I rebooted the primary without failing over or moving the cluster resources from the primary I get error 1069 and 1205 in the cluster. My cluster validation came without any error but with some warnings as it is a multi subnet cluster and there was nothing on the cluster logs or sql error logs. Before I contact Microsoft support I wanted to check if the errors were intended behavior of the cluster. The availability group always automatically failed over every time I rebooted the primary to simulate a failure. Error 1069: > Cluster resource 'ABC_LIVEDB' of type 'SQL Server Availability Group' > in clustered role 'ABC_LIVEDB' failed. Error 1205: > The Cluster service failed to bring clustered role 'ABC_LIVEDB' > completely online or offline. One or more resources may be in a failed > state. This may impact the availability of the clustered role. I greatly appreciate the guidance.

When I installed SSMS21 on windows 2022 server I noticed the extremely disruptive new feature where it will not use the open and logged in instance of SSMS when I double click a .sql file. Instead, it opens a new instance is SSMS, taking forever and eating resources. I tried lots of registry hacks posted here and there on the internet, and even enlisted the help of chatgpt and copilot to try to fix it. No success. Imagine my surprise when Brent sent me this link https://14days.brentozar.com/ssms.mp4 showing him double clicking on a sql file and it using the open instance of SSMS 21! According to Brent, the only difference here is he is using Windows 2025. Unfortunately, I do not have access to windows 2025 yet. I build a clean VM with the following specs: Windows Server 2022 Standard 21H2 OS Build 20348.3807 SSMS SQL Server Management Studio 21.3.7+3.36221.1 I launch SSMS and log in to the database. Then I use windows explorer to find my sql files and double click on one. A brand new instance is SSMS slowly launches! Grrrr! I know it can work because I see Brent's video. Anyone know the magic sauce to make it work for me?

Trying to run the RML Utilities on Windows Server 2022 & this is listed as compatible but when I run readtrace getting error 0x80040154 & the connection to the db server fails, which seems to be due to I haven't installed the extra componenents required - doh. However when I download and try and install the SQL Server native client it won't install and says it is not compatible with this OS. Has anyone else encountered this problem & knows a way past it ?

We have an instance of MySQL 8.4 running on Windows Server 2022. It ran fine for 12 days, but suddenly it is consuming a lot of memory. I've deducted this from the Windows Event log and the MySQL error log. Example: (MySQL error log) [ERROR] [MY-010934] [Server] Out of memory (Needed 1594376 bytes) and (Windows event log) The following programs consumed the most virtual memory: mysqld.exe (2944) consumed 15530082304 bytes. Here's the whole MySQL error log: https://pastebin.com/4pcwaDHJ Anyone who can help me figure out what might be going on, and perhaps tell me if the my.ini-settings are completely wrong? EDIT: I've run MySQLTuner for Windows, without finding any issue exept 533 joins performed without indexes. Here's the my.ini-file: https://pastebin.com/4bSbM5Vz The server is a VM with 24 GB RAM and runs Wordpress (PHP) under IIS. Runs between 5 and 30 sites (WP and some also WooCommerce). Thanks in advance. -Espen.

We have an instance of MySQL 8.4 running on Windows Server 2022. It ran fine for 12 days, but suddenly it is consuming a lot of memory. I've deducted this from the Windows Event log and the MySQL error log. Example: (MySQL error log) *[ERROR] [MY-010934] [Server] Out of memory (Needed 1594376 bytes)* and (Windows event log) *The following programs consumed the most virtual memory: mysqld.exe (2944) consumed 15530082304 bytes.* Here's the whole MySQL error log: https://pastebin.com/4pcwaDHJ Anyone who can help me figure out what might be going on? Here's the my.ini-file: https://pastebin.com/4bSbM5Vz The server is a VM with 24 GB RAM and runs Wordpress (PHP) under IIS. Thanks in advance. -Espen.

Not a DBA so please bear with me. I have an EC2 instance running SQL Server 2022 and I'm trying to automate database backups to S3 using the native S3 connector in this version of SQL Server. The underlying infrastructure is there - I have the buckets, the credentials, and the policies, and I've tested backups manually with basic 'BACKUP DATABASE' queries to the S3 endpoint. All of that works fine. However, I'm not clear on how to properly automate this from within SQL Server. It looks like the 'Maintenance Plan' feature does not support S3 endpoints - I only see options for Azure when I select 'URL' as the destination. Should I not be using maintenance plans? Do I need to create SQL Server Agent jobs and manually enter T-SQL queries for the backup operations? If I do things this way, are there additional clean-up requirements I'd need to account for which would have otherwise been taken care of by a maintenance plan?

A separate domain account was created for the database engine service of a SQL Server Failover Cluster Instance. Server Principal Names (SPNs) were added manually via the SetSPN.exe command line tool.

If the domain account for the database engine service is a member of Domain Admins, SQL can successfully (and automatically) register SPNs when the service starts (eg server reboot, cluster failover event, manual restart of db engine service). When the domain account for the db engine service is removed from the Domain Admins Active Directory group, SQL fails to register SPNs. The db engine service account needs certain permissions to register or modify a SPN. Microsoft has listed the permissions necessary for Automatic SPN Registration in their documentation: - Permission: Validated Write servicePrincipalName - Property: Read servicePrincipalName - Property: Write servicePrincipalName I've followed along with the documentation. I've also verified Effective Access for the domain account. But I just can't get automatic SPN registration to work without elevated permissions (in Domain Admins). Something has been missed, but I don't know what. Did I miss a step? Is anything missing from the documentation? **UPDATE**
I may have found an answer. Everything I posted above relates to the Active Directory account for the ***computer*** that hosts the SQL Server instance (or in my case, the virtual cluster name account for the SQL Server Failover Cluster Instance). The logon account for the database engine service also needs these permissions in Active Directory: - Read servicePrincipalName - Write servicePrincipalName However, it does not appear those permissions can be added in the *Active Directory Users and Computers* GUI tool. *ADSIEdit* is what I used. Special thanks to Randolph West. His answer to another similar question has all the details.

I have a number of issues in a PostgreSQL 11 database. 1. I'm very close to filling the 2TB data drive but I'm not able to "grow" the drive 2. I'm finding it very difficult to reduce the size of the database by removing old data from the two very large tables and retain only the most recent three years' worth of readings data. I'm not able to use table partitioning on these two tables as they have foreign keys 3. I want to upgrade to v14 or v15 My current plan is to replicate the data to a new, larger, second drive to buy myself time, and then switch to that drive when I'm all up-to-date. Elsewhere, I've been told the way to go is... * Stop the cluster * Move the entire top-level directory to another drive * Update the data_directory in postgresql.conf * Restart the cluster I was hoping there'd be a way to effectively run a "live" backup to this new drive, stop the service when up-to-date, point the service to the new drive and off we go. I can hold-off the incoming data but down-time needs to be less than 3 hours. I think copying nearly 2TB of data will exceed this time limit. Once I'm switched to the new drive, it's my understanding I could then carry out the upgrade in-place with far less down-time. So my question then is what configuration changes do I need to apply to kick-off the replication?

The company I work for has a File Share server running on an server that is running Windows Server 2022. Its a simple setup that just uses Workgroups rather than a domain controller. They use a CAD software called Microvellum that requires an SQL server to host all of their data. The Microvellum website recommends having a dedicated server for the SQL that is only used for Microvellum, no other applications. I know that the recommended way to setup the new workflow would be to have 2 virtual machines, 1 running the file share (and probably a domain controller in the future) and another running the SQL server. But, am I able to keep the file share server on the original install of Windows Server, and run the SQL server on a Virtual Machine? I've never seen anyone just run a single virtual machine, so I'm unsure how it affects performance.

### Introduction I'm experiencing weird behaviour on a virtualised (ESXi) Windows Server 2022 running SQL Server 2019 when the VMware conducts a snapshot of the server. It doesn't log the snapshot in the **msdb** database. On all our other SQL Server 2019 servers, when the ESXi host performs a VMware snapshot of the Windows Server with SQL Server 2019, then the **Volume Shadow Copy** service of Windows will be activated and this will trigger the **SQL Server VSS Writer** service. The SQL Server instance will duly note that a **is_copy_only** and **is_snapshot** backup was created for all databases of the instance. On the Windows Server 2022 with SQL Server 2019 instance running there are no entries in the **msdb** backup when VMware performs a snapshot. **Nothing**. This means there are no entries in the **ERRORLOG** that contain I/O is frozen on database . No user action is required. However... and I/O was resumed on database . No user action is required. messages. In order to pinpoint the issue I started looking at the Microsoft articles on the VSSADMIN and the DISKSHADOW command line tools. I supplemented my reading with the Microsoft article on VSS & SQL Writer which has some additional information on how the Volume Shadow Copies are initiated, etc. ### Applying My Acquired Knowledge I issued the following commands to create a valid, consistent Microsoft Volume Shadow Copy Snapshot of the quirky Windows Server 2022:

-dos
C:\Windows\system32>diskshadow
Microsoft DiskShadow version 1.0
Copyright (C) 2013 Microsoft Corporation
On computer:  SERVERNAME13,  22.07.2022 14:48:50


DISKSHADOW> set
Current context: VOLATILE
Current options: 
Verbose mode:    OFF
Metadata file:   

No Diskshadow aliases are currently defined in the environment.

DISKSHADOW> set verbose on

DISKSHADOW> writer verify "SqlServerWriter"

DISKSHADOW> set metadata c:\temp\diskshadow_c_e_f_g_h.cab

DISKSHADOW> begin backup

DISKSHADOW> add volume c: alias SYSTEM

DISKSHADOW> add volume e: alias SQLDATA

DISKSHADOW> add volume f: alias SQLLOGS

DISKSHADOW> add volume g: alias SQLTEMP

DISKSHADOW> add volume h: alias ADHOC

DISKSHADOW> create

This produced the following output, which shows us that the databases will be indeed included in the snapshot and be consistent: > Excluding writer "BITS Writer", because all of its components have been excluded. > Excluding writer "Shadow Copy Optimization Writer", because all of its components have been excluded. > Component "\BCD\BCD" from writer "ASR Writer" is excluded from backup, > because it requires volume which is not in the shadow copy set. > All components from writer "SqlServerWriter" are selected. > > * Including writer "Task Scheduler Writer": > + Adding component: \TasksStore > > * Including writer "VSS Metadata Store Writer": > + Adding component: \WriterMetadataStore > > * Including writer "Performance Counters Writer": > + Adding component: \PerformanceCounters > > * Including writer "System Writer": > + Adding component: \System Files > + Adding component: \Win32 Services Files > > * Including writer "SqlServerWriter": > + Adding component: \SERVERNAME13\WSUS\master > + Adding component: \SERVERNAME13\WSUS\model > + Adding component: \SERVERNAME13\WSUS\msdb > + Adding component: \SERVERNAME13\WSUS\TVDTools > + Adding component: \SERVERNAME13\WSUS\SUSDB > > * Including writer "COM+ REGDB Writer": > + Adding component: \COM+ REGDB > > * Including writer "ASR Writer": > + Adding component: \ASR\ASR > + Adding component: \Volumes\Volume{0ae0e5e3-28e7-4d48-a0cc-be0fe93cc972} > + Adding component: \Volumes\Volume{5ff0815f-0548-42b5-9ab4-695abd5ca4fb} > + Adding component: \Volumes\Volume{13593a85-0000-0000-0000-100000000000} > + Adding component: \Volumes\Volume{994f9685-3bd3-4332-9450-2fa867bfd88b} > + Adding component: \Volumes\Volume{08659769-e6dc-4806-9caa-66b472f4ff12} > + Adding component: \Volumes\Volume{4d6aa966-9c7c-4a45-b9fb-74b82d27c9ba} > + Adding component: \Volumes\Volume{604630a9-6906-4d65-b522-efa9bce54b33} > + Adding component: \Volumes\Volume{90a44505-8b5c-46b9-a93c-17d109bb1b48} > + Adding component: \Disks\harddisk6 > + Adding component: \Disks\harddisk3 > + Adding component: \Disks\harddisk0 > + Adding component: \Disks\harddisk4 > + Adding component: \Disks\harddisk1 > + Adding component: \Disks\harddisk5 > + Adding component: \Disks\harddisk2 > > * Including writer "Registry Writer": > + Adding component: \Registry > > * Including writer "WMI Writer": > + Adding component: \WMI > > Alias SYSTEM for shadow ID {d0dfc934-16f2-4545-8bed-f6ea4c39feb0} set as environment variable. > Alias SQLDATA for shadow ID {5c3890d3-fcca-4e97-bbc2-bcc0bf89e94a} set as environment variable. > Alias SQLLOGS for shadow ID {f2372742-d824-4049-8b11-6b7df6d4496c} set as environment variable. > Alias SQLTEMP for shadow ID {bd0cb807-87b3-4996-ae2c-8a37dc0b9ca7} set as environment variable. > Alias ADHOC for shadow ID {3db064ac-c8b1-4370-8d72-b4e5f567c62c} set as environment variable. > Alias VSS_SHADOW_SET for shadow set ID {80875036-e760-415e-a78f-79d61f699d4b} set as environment variable. > Inserted file Manifest.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file BCDocument.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM0.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM1.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM2.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM3.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM4.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM5.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM6.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM7.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM8.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM9.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file WM10.xml into .cab file diskshadow_c_e_f_g_h.cab > Inserted file Dis7D66.tmp into .cab file diskshadow_c_e_f_g_h.cab > > Querying all shadow copies with the shadow copy set ID {80875036-e760-415e-a78f-79d61f699d4b} > > * Shadow copy ID = {d0dfc934-16f2-4545-8bed-f6ea4c39feb0} %SYSTEM% > - Shadow copy set: {80875036-e760-415e-a78f-79d61f699d4b} %VSS_SHADOW_SET% > - Original count of shadow copies = 5 > - Original volume name: \\?\Volume{0ae0e5e3-28e7-4d48-a0cc-be0fe93cc972}\ [C:\] > - Creation time: 22.07.2022 14:50:23 > - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1 > - Originating machine: SERVERNAME13.DOMAIN.TLD > - Service machine: SERVERNAME13.DOMAIN.TLD > - Not exposed > - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5} > - Attributes: Auto_Release Differential > > * Shadow copy ID = {5c3890d3-fcca-4e97-bbc2-bcc0bf89e94a} %SQLDATA% > - Shadow copy set: {80875036-e760-415e-a78f-79d61f699d4b} %VSS_SHADOW_SET% > - Original count of shadow copies = 5 > - Original volume name: \\?\Volume{604630a9-6906-4d65-b522-efa9bce54b33}\ [E:\] > - Creation time: 22.07.2022 14:50:23 > - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2 > - Originating machine: SERVERNAME13.DOMAIN.TLD > - Service machine: SERVERNAME13.DOMAIN.TLD > - Not exposed > - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5} > - Attributes: Auto_Release Differential > > * Shadow copy ID = {f2372742-d824-4049-8b11-6b7df6d4496c} %SQLLOGS% > - Shadow copy set: {80875036-e760-415e-a78f-79d61f699d4b} %VSS_SHADOW_SET% > - Original count of shadow copies = 5 > - Original volume name: \\?\Volume{4d6aa966-9c7c-4a45-b9fb-74b82d27c9ba}\ [F:\] > - Creation time: 22.07.2022 14:50:23 > - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3 > - Originating machine: SERVERNAME13.DOMAIN.TLD > - Service machine: SERVERNAME13.DOMAIN.TLD > - Not exposed > - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5} > - Attributes: Auto_Release Differential > > * Shadow copy ID = {bd0cb807-87b3-4996-ae2c-8a37dc0b9ca7} %SQLTEMP% > - Shadow copy set: {80875036-e760-415e-a78f-79d61f699d4b} %VSS_SHADOW_SET% > - Original count of shadow copies = 5 > - Original volume name: \\?\Volume{08659769-e6dc-4806-9caa-66b472f4ff12}\ [G:\] > - Creation time: 22.07.2022 14:50:23 > - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4 > - Originating machine: SERVERNAME13.DOMAIN.TLD > - Service machine: SERVERNAME13.DOMAIN.TLD > - Not exposed > - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5} > - Attributes: Auto_Release Differential > > * Shadow copy ID = {3db064ac-c8b1-4370-8d72-b4e5f567c62c} %ADHOC% > - Shadow copy set: {80875036-e760-415e-a78f-79d61f699d4b} %VSS_SHADOW_SET% > - Original count of shadow copies = 5 > - Original volume name: \\?\Volume{994f9685-3bd3-4332-9450-2fa867bfd88b}\ [H:\] > - Creation time: 22.07.2022 14:50:23 > - Shadow copy device name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy5 > - Originating machine: SERVERNAME13.DOMAIN.TLD > - Service machine: SERVERNAME13.DOMAIN.TLD > - Not exposed > - Provider ID: {b5946137-7b9f-4925-af80-51abd60b20d5} > - Attributes: Auto_Release Differential > > Number of shadow copies listed: 5 I then ended the Volume Shadow Copy with:

-dos
DISKSHADOW> end backup

DISKSHADOW> exit

### Confirming Snapshot Backup Looking at the information in the **msdb** database, I was able to confirm that the databases had indeed been backed up: > +---------------+-------------------------+------+-------------+------------------+--------------+-------------+ > | database_name | backup_start_date | type | backup_type | device_type_desc | is_copy_only | is_snapshot | > +---------------+-------------------------+------+-------------+------------------+--------------+-------------+ > | model | 2022-07-22 14:50:21.000 | D | Full | Virtual Device | 0 | 1 | > | msdb | 2022-07-22 14:50:21.000 | D | Full | Virtual Device | 0 | 1 | > | SUSDB | 2022-07-22 14:50:21.000 | D | Full | Virtual Device | 0 | 1 | > | master | 2022-07-22 14:50:21.000 | D | Full | Virtual Device | 0 | 1 | > +---------------+-------------------------+------+-------------+------------------+--------------+-------------+ ### Problem However, the database backups created with the DISKSHADOW CLU are not marked as **is_copy_only**. This is bad because a snapshot backup shouldn't break the backup chain. The VMware snaphsot is capable of creating backups with **is_copy_only** and **is_snapshot**. Reading the SQL Server Backup Applications - Volume Shadow Copy Service (VSS) and SQL Writer article I saw that there is the possibility of setting the backups to **COPY_ONLY**: (**emphasis** mine) > During the backup discovery phase, the SQL writer will indicate its capability to do a copy-only backup by setting the supported backup schema option VSS_BS_COPY using the IVssCreateWriterMetadata::SetBackupSchema call. **The requestor (_in my case the diskshadow CLU_)** can set the backup type as a copy-only backup by setting the **VSS_BACKUP_TYPE** option as **VSS_BT_COPY** with the call IVssBackupComponents::SetBackupState. ## Questions 1. Can I set the option VSS_BACKUP_TYPE to VSS_BT_COPY in the DISKSHADOW command-line utility? 2. Is there any other way to configure the **SQL Server VSS Writer** to create **COPY_ONLY** backups when manually creating a Volume Shadow Copy as I am doing?