I am running two Windows Servers 2012 R2 with SQL Server 2014 Standard Edition. I have strange issue on mirroring. I configured mirroring on for 15 databases, no Witness server. The Principal server show all database is Principal, Synchronized and the Mirror is Mirror, Synchronized/Restoring. When I open Database Mirror Monitor I see Role Principal is in Mirroring State Synchronized but the Mirror's Role is not connected. I have fail over in both directions and the database came up on the mirror server normally. data is replicating for troubleshooting purpose I have done below steps. 1. I have seen in error log in principle nothing is related to mirroring traced I can see most of the errors in principle are Error: 18456, Severity: 14, State: 38. 2. I have seen errors in mirroring server for all the databases are Database mirroring connection error 4 'An error occurred while receiving data: '10054(An existing connection was forcibly closed by the remote host.)'.' for 'TCP://server.company.com:5022'. Error: 1474, Severity: 16, State: 3. I have tried to resolve by stop and start the endpoint its was not resolved. 4. I have tried pause and resume it is also not resolved. 5. I have verified TCP/IP it is enabled on both the servers. 6. I have tried to configure alias it is also not resolve. 7. I have telnet from each other, it seems have no communication issues 8. I have verified connect rights to domain level same service account for both principle and mirror. 9. Earlier it is SQL server 2014 sp2 ,today I have updated with latest service sp3 even though still I can see same in mirror monitor Not connected to mirror. Please help on this issue, how to resolve this?

We're running SQL Server 2016 Standard Edition with database mirroring in synchronous mode and automatic failover enabled. Our .NET applications use connection strings with Failover Partner. Occasionally (1–4× per day), some applications try to connect to the mirror server, even though the principal is online and fully healthy. We see login failures on the mirror (Error 4060 – "Cannot open database ...") but no issues or alerts on the principal side (Redgate, Zabbix, SQL logs, etc.). This affects different databases (we have dozens mirrored) and different apps or users – it’s not tied to one specific service. Extended Events show only mirror-side errors, with various client hosts and application names. PerfMon once showed a spike in TCP hard connects around the same time, but nothing consistent. Based on online research such as [Database mirroring login failure attempts on mirror server](https://serverfault.com/questions/236163) , we suspect it may be caused by things like expired connections in the pool, network hiccups, SQL Browser issues, or connection resets (e.g. firewall/NAT dropping idle sockets). When this happens, the .NET SqlClient might believe the primary is unreachable and trigger an immediate failover attempt. So far this seems to be expected behavior, but it causes false-positive alerts in our monitoring tools. We're trying to confirm: 1) Is this behavior expected from ADO.NET when Failover Partner is used? 2) Is there any way to reduce/suppress the probing of the mirror? 3) Are there best practices for detecting/logging/tuning this (e.g., connection settings, retry logic)? 4) Should we just tune our monitoring and ignore these errors as “normal noise”?

The witness server on my environment is corrupted and the mirrored database failed over to the secondary server. I removed database from Principal server, hoping that I can set up mirroring between the Mirror and Principal. So I backed up the database on Mirror, and restored it on the Principal; Configured mirroring on the Mirror and when I click start mirroring I got the following error message > Alter failed for the database xxx , An exception occurred while > executing a Transact SQL Statement or Batch.. Database 'xxx' is not > configured for database mirroring. Error 1416 I am guessing the error happened as I didn't remove the previous mirror configuration. How can I remove my previous mirror config and setup a mirroring between these. when i execute this SELECT role_desc, state_desc FROM sys.database_mirroring_endpoints results PARTNER STARTED

The first thing I would like to say is that I'm not going to build a production on such an architecture. I am interested purely for the sake of experiments in home experiments and performance in the amount of 1-2 users. What I need: - One data storage location from SQL database - The ability to connect using different drivers and different SQL dialects - Isolation of data from the method, libraries and syntax of obtaining them What I don't need: - Replication between different databases, creating duplicate data and tables ---------- For example: I have two apps. The first uses MySQL. The second uses Postgres. It is impossible to rewrite them on one database (for one reason or another). I want them to be able to connect each with their own driver and syntax, to the same data. At the same time, the data itself is not replicated, it is stored in a single instance. Please tell me how you can achieve a similar logic? What tools or settings can be used to achieve this? Which way should I move?

I am trying to setup mirroring between two servers with separate sql server instances but every time I have received an error message with the following details: >An error occurred while starting mirroring. > >Alter failed for Database 'WC_PROD'. (Microsoft.SqlServer.Smo) > >An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo) > >The server network address "TCP://ServerName.DOMAIN.local:5022" can not be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (.Net SqlClient Data Provider) > >Server Name: ServerName,5022 Error Number: 1418 Severity: 16 State: 1 Line Number: 1 I've reviewed the documentation from the learn microsoft sites for [Specify Network Address](https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/specify-a-server-network-address-database-mirroring?view=sql-server-ver15) ; [Setting up using windows authentication](https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/example-setting-up-database-mirroring-using-windows-authentication-transact-sql?view=sql-server-ver16) ; [and the initial guide](https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-sql-server?view=sql-server-ver16) when setting up the initial attempts at mirroring and troubleshooting the above error. Several other posts [here](https://dba.stackexchange.com/questions/23878/mirroring-server-network-address-cannot-be-reached) , and [here](https://dba.stackexchange.com/questions/203508/tcp-address-of-sql-server-not-working-in-mirroring) , recommended confirming port availability with netsat, which I can confirm the ports are open and listening. I've also confirmed the user roles are configured in the sysadmin group and tried several different port and TCP address configurations. I was unable to connect to either server from the other with the Telnet command as well. If anyone has any additional advice or knows more about the error number than cannot reach server it would be greatly appreciated. I'm new to SQL server so I'm doing what I can while running in circles here and may be missing something obvious. The end goal is to have an identical backup in the event of a DR scenario so we do not have any data loss hence the mirroring. Edit: Both servers are running on Windows server 2019. Using Telnet server.domain.local:5022 from either host to the other results in "Could not open connection to the host, on port 23: Connect failed" despite a specific firewall rule to allow the servers to communicate with each other through ports 23 and 5022. Edit2: I deleted the previously created endpoints and went through from the beginning, I then ran into an error when setting the mirror endpoint to 5022, changed that to 7022 and successfully created the endpoints with no errors. Once I started the mirror session I ran into the same error. The server that it is failing to connect to is the Principal server that I am setting this up from. Edit3: Some digging into further logs found a **new error message** stating that the user failed with error, login does not have CONNECT permission on the endpoint. Working on getting that configured now although the account is the computer and not a user, and neither is the configured service account.

I have SQL 2016 **Standard** Edition to install and configure a HA/DR solution. I need automatic failover in a cluster of two nodes. I am proposing SQL FCI over database Mirroring for the following reasons: - FCI will need only two nodes for the configuration and will failover automatically - Database Mirroring is being phased out by Microsoft and moreover, in order to achieve automatic failover, we will need an extra server (for witness) in addition to the two nodes of the cluster. Hence requiring 3 difference SQL instances in 3 VMs. Would you agree with my reasoning and are there any other things I need to consider please? Automatic failover is essential in the requirements. Thank you.

I have two databases on different servers. Each one of them contains 350+ tables and users have read and write access on both databases. I want to synchronize them, but in special cases, like if a specific record is updated on both databases, I have to be able to prioritize one of updates over the other. One of the databases is always online and the other one is never online and only has access to local network of organization, synchronization happens everyday at a specific time by downloading all files from internet and uploading them on local net and reverse. I have considered merge replication and trigger-based replication, but I'm open to any other solutions. I can't choose the best solution for this task, I really appreciate your advice.

Trying to mirror an on-premise SQL Server instance to EC2 instance, but not much information is available on this topic. The closest one I managed to find is: Implement SQL Server High Availability and Disaster Recovery on Amazon EC2 - Part 4 Has any one done this? If so is there any documentation available? My intention is to make the EC2 as a backup for the HA in case my on-premise DB crashes. Please note that this is not for AWS RDS, nor EC2 SQL Server to EC2 SQL Server; but on-premise SQL Server to AWS EC2 SQL Server. The DB version is not a constraint, it can be SQL Server 2017 too.

Is there is any procedure to do MSSQL Mirroring with single master and multiple slave. [two slave X one master](https://i.sstatic.net/jy0EGoTF.png) Or this one. [One Master X One Slave for Viewing only](https://i.sstatic.net/4hpv23kL.png) I need a MS SQL server for viewing only that doesn't affect the master. To avoid row locking. I am currently using MSSQL Server 2017

Assuming SQL Server 2022 Standard Edition on Windows, I simply cannot see any benefits to using Basic Availability Groups instead of Database Mirroring. Is there anything offered by Basic Availability Groups but not Database Mirroring? In both cases: - You can only have 1 primary and 1 secondary - The secondary is not readable - Databases cannot be grouped in any way allowing them to fail over together - Replication can either be sync or async - Automatic page repair is enabled. The only differences that I've found between the two features are that Basic Availability Groups cannot be upgraded to Enterprise Edition and that Database Mirroring is officially deprecated. I appreciate that Basic Availability Groups are harder to set up than mirrors, but I am only asking about **benefits** of Basic Availability Groups over Database Mirroring.

Received an error mentioned below after failover when mirror partner is down. **Error :** > to fail over to a database which is not configured for database > mirroring. code: 22037, text: 'Invalid connection string > attributeCannot open database "DBName" requested by the login. The login > failed.Login failed for user 'domain\user'.The connection attempted to > fail over to a database which is not configured for database > mirroring.'. **Scenario :** 1. X is a Principal server and Y is a mirror partner of X 2. X is a publisher too, Z is a distributor server 3. Z is added as distributor in X and Y Server. X and Y added as publisher in Z server too 4. Configured Y as a "PublisherFailoverPartner" in replication log reader agent profile setting 5. Did failover of X 6. Thereafter Y became a principal and X became mirror partner 7. Break mirror from Y to X or X server is down and unavailable After above steps performed, replication is started to throw an error. When mirror is ON the replication is working, otherwise it raising an error mentioned. Can you please suggest me steps to resolve it?

I have two SQL servers configured with an availability group. The configurations uses a dnn for it's listener. Connection tests to the configured port are successful. When we try to make a connection with multisubnetfailover=true in the connection string, we get the following error message: >Connecting to a mirrored SQL Server instance using the multiSubnetFailover connection property is not supported. This system has never been configured with a mirror. I've ran `SELECT * FROM SYS.DATABASE_MIRRORING` The results of the command was NULL. Any suggestions what I can check to resolve this?

We have two production SQL Servers running SQL Server 2005 SP4 with cumulative update 3. Both servers run on physical machines that are identical. DELL PowerEdge R815 with 4 x 12 core CPUs and 512GB (yes GB) of ram, with 10GB iSCSI SAN connected drives for all SQL databases and logs. OS is Microsoft Windows Server 2008 R2 Enterprise edition with all SP's and windows updates. OS drive is a RAID 5 array of 3 x 72GB 2.5" 15k SAS drives. SAN is a Dell EqualLogic 6510 with 48 x 10K SAS 3.5" drives, configured in RAID 50, sliced into various LUNs for the 2 SQL Servers, and also shared with an Exchange machine and several VMWare servers. We have over 20 databases, 11 of which are mirrored with high availability using a witness server. The witness server is a lower powered machine running a SQL Server instance that is used for nothing other than providing witness services. The biggest mirrored database is 450GB and generates around 100-300 iops. Database Mirroring Monitor reports a current send rate around 100kb to 10mb per second, and a mirror commit overhead of (typically) 0 milliseconds. The mirror server has no problem keeping up with the principal. We are consistently experiencing mirroring failovers. Sometimes a single database will failover, other times almost all databases will failover simultaneously. For instance, last night, we had 10 of 11 databases failover, the remaining database stayed accessible until I manually failed it over. I have gone through several troubleshooting steps to attempt to identify the problem, but have so far not been able to resolve the issue: 1) The machine came with a Broadcom BCM5709C NetXtreme II 4 port Gigabit network adapter which we initially used as the primary network connection. We have since installed an Intel(R) PRO/1000 PT Dual Port Server Adapter on both machines to eliminate the NIC as the issue. 2) All databases have an automatic full backup nightly along with a log backup for databases involved in mirroring. Log file useage is monitored and rarely gets above 15% used. The log file for the main database is 125GB, consisting of 159 virtual log files that range in size from 511MB to 1GB. TempDB is on it's own LUN, and consists of 24 x 2GB files. 3) SQL Server log on the witness shows no errors other than: The mirroring connection to "TCP://SQL02.DOMAIN.INET:5022" has timed out for database "Data" after 30 seconds without a response. Check the service and network connections. SQL Server log on the primary and secondary servers show messages relating to mirroring: The mirroring connection to "TCP://SQL01.DOMAIN.INET:5022" has timed out for database "Data" after 30 seconds without a response. Check the service and network connections. The mirrored database "Data" is changing roles from "PRINCIPAL" to "MIRROR" due to Role Syncronization. (Synchronization is misspelled here on purpose since that is precisely how the actual message is display.) The mirrored database "Data" is changing roles from "PRINCIPAL" to "MIRROR" due to Failover. The mirrored database "Data" is changing roles from "MIRROR" to "PRINCIPAL" due to Failover from partner. The SQL Server services continue to run and network connections seem to stay up. We consistently have between 500 to 2500 sessions connected to each server (primarily robotic applications that connect to service broker queues on a single database). 4) TCP Chimney and RSS etc are disabled using NET SH syntax. 5) I have ran the SQL Server 2005 Best Practices Analyzer against both machines and find nothing other than the very occasional Application Event Log error 833, none of which are coincident with the failover events: SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\Data.MDF] in database [Data] (9). The OS file handle is 0x00000000000010A0. The offset of the latest long I/O is: 0x000007d4b10000). 6) Occasionally we see "The client was unable to reuse a session with SPID XXX, which had been reset for connection pooling. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message." generated by both servers. There appears to be no "earlier" messages that indicate any issue. 7) Occasionally database mail writes an error to the Application event log: Exception Type: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Message: There was an error on the connection. Reason: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding., connection parameters: Server Name: MGSQL02, Database Name: msdb Data: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection(Microsoft.SqlServer.Management.Common.SqlConnectionInfo) HelpLink: NULL Source: DatabaseMailEngine StackTrace Information at Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection(SqlConnectionInfo ci) at Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection(String dbServerName, String dbName, String userName, String password) at Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems(String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel) I believe the Timeouts are causing the failover; what could cause these timeouts? Obviously if there was an actual network issue such as a bad cable, or a bad switch, that might cause packet loss and therefore a timeout, however what other things could cause timeouts? Blocking? If MSDB, or some other system database had an I/O timeout could that cause the mirroring failover? Thanks for any advice! MSDN has the following to say about the timeout mechanism itself : >The Mirroring Time-Out Mechanism > >Because soft errors are not detectable directly by a server instance, a soft error could potentially cause a server instance to wait indefinitely. To prevent this, database mirroring implements its own time-out mechanism, based on each server instance in a mirroring session sending out a ping on each open connection at a fixed interval. > >To keep a connection open, a server instance must receive a ping on that connection in the time-out period defined, plus the time that is required to send one more ping. Receiving a ping during the time-out period indicates that the connection is still open and that the server instances are communicating over it. On receiving a ping, a server instance resets its time-out counter on that connection. > >If no ping is received on a connection during the time-out period, a server instance considers the connection to have timed out. The server instance closes the timed-out connection and handles the time-out event according to the state and operating mode of the session. netsh interface tcp show global shows: Receive-Side Scaling State : disabled Chimney Offload State : disabled NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : disabled Add-On Congestion Control Provider : ctcp ECN Capability : disabled RFC 1323 Timestamps : disabled netsh interface ipv4 show dynamicportrange tcp Protocol tcp Dynamic Port Range Start Port : 1025 Number of Ports : 64510 SELECT name, value_in_use FROM sys.configurations

    Ad Hoc Distributed Queries               0         
    affinity I/O mask                        0         
    affinity mask                            0         
    affinity64 I/O mask                      0         
    affinity64 mask                          0         
    Agent XPs                                1         
    allow updates                            0         
    awe enabled                              0         
    blocked process threshold                5         
    c2 audit mode                            0         
    clr enabled                              1         
    common criteria compliance enabled       0         
    cost threshold for parallelism           4         
    cross db ownership chaining              0         
    cursor threshold                         -1        
    Database Mail XPs                        1         
    default full-text language               1033      
    default language                         0         
    default trace enabled                    1         
    disallow results from triggers           0         
    fill factor (%)                          0         
    ft crawl bandwidth (max)                 100       
    ft crawl bandwidth (min)                 0         
    ft notify bandwidth (max)                100       
    ft notify bandwidth (min)                0         
    index create memory (KB)                 0         
    in-doubt xact resolution                 0         
    lightweight pooling                      0         
    locks                                    0         
    max degree of parallelism                6         
    max full-text crawl range                4         
    max server memory (MB)                   393216    
    max text repl size (B)                   65536     
    max worker threads                       0         
    media retention                          0         
    min memory per query (KB)                2048      
    min server memory (MB)                   52427     
    nested triggers                          1         
    network packet size (B)                  1400      
    Ole Automation Procedures                1         
    open objects                             0         
    PH timeout (s)                           60        
    precompute rank                          0         
    priority boost                           0         
    query governor cost limit                0         
    query wait (s)                           -1        
    recovery interval (min)                  0         
    remote access                            1         
    remote admin connections                 0         
    remote login timeout (s)                 20        
    remote proc trans                        0         
    remote query timeout (s)                 600       
    Replication XPs                          0         
    scan for startup procs                   0         
    server trigger recursion                 1         
    set working set size                     0         
    show advanced options                    1         
    SMO and DMO XPs                          1         
    SQL Mail XPs                             0         
    transform noise words                    0         
    two digit year cutoff                    2049      
    user connections                         0         
    user options                             4216      
    Web Assistant Procedures                 0         
    xp_cmdshell                              1         

A while ago, I manually modified the mirroring_connection_timeout value for all mirrored databases to 30 seconds to attempt to remediate the problem; this has simply increased the amount of time between failover events. With the mirroring_connection_timeout setting set at the default of 10 seconds, we see a *lot* more failovers. A comment had asked me to ensure IPSec is disabled, so I'm posting the contents of several netsh commands that display the IPSec configuration of the operating system:

C:\>netsh ipsec dynamic show all
No currently assigned Policy
Mainmode Policies not available.
Quickmode Policies not available.
Generic Mainmode Filters not available.
Specific Mainmode Filters not available.
Generic Quickmode Filters not available.
Specific Quickmode Filters not available.
IPsec MainMode Security Associations not available.
IPsec QuickMode Security Associations not available.

IPsec Configuration Parameters
------------------------------
StrongCRLCheck         : 1
IPsecexempt            : 3

IPsec Statistics
----------------
Active Assoc                : 0
Offload SAs                 : 0
Pending Key                 : 0
Key Adds                    : 0
Key Deletes                 : 0
ReKeys                      : 0
Active Tunnels              : 0
Bad SPI Pkts                : 0
Pkts not Decrypted          : 0
Pkts not Authenticated      : 0
Pkts with Replay Detection  : 0
Confidential Bytes Sent     : 0
Confidential Bytes Received : 0
Authenticated Bytes Sent    : 0
Authenticated Bytes Received: 0
Transport Bytes Sent        : 0
Transport Bytes Received    : 0
Bytes Sent In Tunnels       : 0
Bytes Received In Tunnels   : 0
Offloaded Bytes Sent        : 0
Offloaded Bytes Received    : 0

C:\>netsh ipsec static show all
ERR IPsec : No Policies in Policy Store

---------------------------------------------------- UPDATE: 2012-12-20 We've now moved our production systems onto SQL Server 2012. We've been running this since the morning of December 17th - so far no failovers. However, a couple of days is well within what we saw with the 2005-based systems. In an effort to document the performance of our new systems, I've been looking at sys.dm_os_wait_stats more carefully; and noticed DBMIRROR_DBM_EVENT, which is an undocumented wait type. Graham Kent at Microsoft has an interesting article regarding troubleshooting unexpected failovers and this wait type. I shall recap his findings here: >The customer was experiencing a huge blocking chain built on a high volume OLTP database where all the head blockers were waiting on DBMIRROR_DBM_EVENT. Here is the sequence of events I went through: 1. Review the blocking chain itself - ho help here as all we can see is that we're waiting on DBMIRROR_DBM_EVENT 2. Review the source for the undocumented wait type. Obviously you can't do this outside of MS, but I can say that at the time of writing this wait type represents the wait used when the principal is waiting for the mirror to harden an LSN, meaning that the transaction it's part of cannot commit. This immediately points quite specifically to the problem that the principal cannot commit transactions as it's waiting on the mirror. Now we need to investigate why the mirror is not committing transactions or why the principal doesn't know whether it is. 3. Review the msdb system tables >(a) Look at the [backupset] table to see if the size of the logs produced at the time of the problem are significantly higher then normal. If they were exceptionally large it may be that the mirror was flooded with transactions and could simply not keep up with the volume. This is why books online will tell you sometimes to disable mirroring if you need to do an exceptionally large logged operation such as an index rebuild. (reference for why this is at http://technet.microsoft.com/en-us/library/cc917681.aspx) . Here i used the following TSQL SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000 FROM [backupset] where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00' go select round((AVG(backup_size)/1000),0) FROM [backupset] where database_name = 'mydatabase' >(b) secondly I looked at the data in the tables [dbm_monitor_data]. The key here is to locate the timeframe in which we had a problem and then see if we were significant experiencing changes in any of the following: log_flush_rate send_queue_size send_rate redo_queue_size redo_rate >These are all indicators similar to part (a) in that they might show a component or piece of architecture that wasn't responding. For example if the send_queue suddenly starts to grow but the re_do queue doesn't grow, then it would imply that the the principal cannot send the log records to the mirror so you'd want to look at connectivity maybe, or the service broker queues dealing with the actual transmissions. >In this particular scenario we noted that all the counters appeared to have strange values, in that there were log backups going on of normal sizes, but there were no status changes, 0 send queue, 0 redo queue, a flat send rate and a flat redo rate. This is very strange as it implies that the DBM Monitor could not record any values from anywhere over the problem period. >4. Review the SQL Server error logs. In this case there were no errors or information messages whatsoever, but in other scenarios such as this, it’s very common for errors in the 1400 range to be reported, examples of which you can find in other places in my other mirroring blogs, such as this Error 1413 example >5. Review the default trace files – in this scenario I was not provided the default traces, however they are fantastic sources of DBM problem information, as they record state change events on all the partners.This is documented here: >Database Mirroring State Change Event Class >This often gives you a great picture of scenarios such as when network connectivity failed between one or all of the partners and then what the state of the partnership became afterwards. >CONCLUSIONS: >In this particular scenario I’m currently missing 2 key points of data, but that apart I can still make a reasonable hypothesis on the above information. We certainly can say that the blocking was caused by the fact that DBM was enabled to the due the blockers all waiting on the DBMIRROR_DBM_EVENT wait type. Since we know we didn’t flood the mirror with a large logged operation and that this deployment normally runs happily in this mode, we can exclude unusual large operations. This means that we have 2 potential candidates at this stage: 1. Hardware problems on the connectivity between some or all of the partners. 2. CPU exhaustion on the mirror server – simply unable to keep up with redos – the CPU exhaustion could itself be from a process outside of SQL Server or outside of the this mirror partnership. 3. A problem with the mirroring code itself (we’d really need some memory dumps to confirm this though). >Based upon experience I’d suspect 1 or 2, but I always keep an open mind about 3 as well, we’re trying to collect some more data now to look at this problem in more detail.

I know doing something like mirroring in SQL Server express edition is not possible, but can we do real-time db backup and restore and setup some automated task which acts like mirroring and keep them in sync.

Our database stores 200 TB of data. We've setup clustering options of two VM nodes with one storage but due to limited resources, we cannot replicate the entire database for disaster recovery (only about 100 GB can be spared at most). So, I was wondering if it's possible to mirror partial portion of the database. 1. Distinguish active data, pull them into separate database (maybe at most 20 GB worth of active data) 2. Setup database mirroring for new database Questions: * If partial database is mirrored, should I be worried about performance issue? * Are there other known solutions to prepare for DR situations? It may be hard to provide best answer without knowing the detailed specs of servers, and configurations but I'd like to know how other servers are handled with limited resources. Thank you!

I have a system with two servers and three client workstations. Servers were configured to work as principal/mirror servers (mirroring was configured with certificates). I have two databases in SQL Server - Archive - database where we store all measurements from system and Process database. There was a need to move Archive database from disk C: do disk D: because of low diskspace. I never really worked with SQL databases so I executed this by following the steps from this [link](https://www.sqlshack.com/move-sql-database-files-mdf-ldf-another-location/) . Everything seemed fine on principal server - I was getting all data from Archive database, but on the mirror server I noticed that mirroring was suspended (for both databases). I stopped mirroring and tried to set it up again with command set partner first on mirror then on principal. Command was successfully completed on mirror but on principal I got following error: >Msg 1499, Level 16, State 1, Line 1; Database mirroring error: status 1460, severity 16, state 1, string Archive.* Do you know what can cause this and how can I resolve this issue? When I moved database, I changed user for SQL Server service from NT Service/MSSQLSERVER to Local system on both servers. Second problem: When I try to access measurements in Archive database from client workstations (through SCADA application) all values are displayed as 0. But when I try to access Archive from server PC, all values are correctly displayed. I even tried moving database back to disk C: and changed SQL Server service user back to NT Service/MSSQLSERVER but the issue remained the same. Also I noticed that .mdf file did not grow in four days (not even a little bit), but I don't understand how can I get readings from server PC for those days if nothing was written to database.

MS SQL DB server 2019: Async Mirroring(High-Performance) is available only in the enterprise edition(2019). or also Available in standard edition(2019)?.

We have a Database Mirroring setup between PROD and SECONDARY and we have failed over to the secondary replica (SECONDARY) . We are now getting a number of almost constant failed logins showing in the log of the server PROD . The applications use the Failover Partner property of the connection string: Data Source=PROD;Failover Partner=SECONDARY;Initial Catalog=myDataBase; and we have confirmed that they are working as expected. It makes sense that the explicitly specified database on PROD cannot be opened as it is in a restoring state due to being failed over but the app is connecting successfully to SECONDARY. Is this error message expected behaviour on a failed over database mirroring primary replica? Below replicates the problem using a simple, ODBC based scenario Set up a Mirorred database: create a login on the primary USE Mirroring CREATE LOGIN MirrorUser WITH PASSWORD = 'MyPassHere', DEFAULT_DATABASE = 'Mirroring' CREATE USER MirrorUser ALTER ROLE db_datareader ADD MEMBER MirrorUser and the secondary: CREATE LOGIN MirrorUser WITH PASSWORD = 'MyPassHere',SID = Set up a DSN: Set up a linked table in an Access database Failover the database to the secondary: ALTER DATABASE Mirroring SET PARTNER FAILOVER Open the Access linked table and verify we can see the data after the failover: Observe the error on .\PROD

As far as i know, SQL Server standard edition supports only 1 mater and other becomes its replica, like Master---> Slave mirroring or replication, Does it also supports Circular replication? like masterMaster replication? or it only supports one way replication

Steps I followed: 1. Create DB on primary. 2. Took full backup and log backup. 3. Restored full and log on secondary in NORECOVERY mode (now tb shows restoring satus on secondary I guess this is because NORECOVERY mode). 4. Tried configuring mirror from primary. I was able to configure it successfully with windows 2012 and SQL server 2012 using SSMS 17.6 but it's giving above error with Win2k16 and SQl server 2016