In reality, this DMV (Dynamic Management View) won't be very helpful for a DBA or Developer and is geared to SQL server Product Support and Product Group. You can ignore this DMV.
Hash tables work well when there are a small number of items that fit into a bucket and this is an example of a DMV that support might use to check certain internal structures ...
The short answer is no, there is not a DMV that contains this information. It would be a significant amount of overhead for SQL Server to track what table was associated with each log record that had been received but not committed.
As you can read in Reading the transaction log in SQL Server – from hacks to solutions, you can read the log records with a ...
Converted from comments:
According to Replication Backward Compatibility, Transactional Replication will not work between a 2016 Publisher and a 2008 Subscriber, but Merge Replication would be supported. Check out Merge Replication to see if that will suit your needs. – Scott Hodgin
Or Upgrade to 2014 and it will be backward compatible to 2008 for ...
I am wondering is it possible to enable replication (or alternatives?)
and have all transactions/merges be in sync on 2008 Instance so both
databases are up to date in case I need to switch to old one?
It's a bit complex, but you could introduce a SQL Server 2014 server to serve as Transactional Replication Subscriber and Republisher.
But the only ...
Sure. The simplest thing is to just make sure the reporting users using Row Versioning, either in SNAPSHOT ISOLATION, or by setting the database to READ_COMMITTED_SNAPSHOT. See eg, Snapshot Isolation in SQL Server.
Then just make your updates in a transaction. Reporting users will not be blocked, and will continue to see the "old" version of every row ...
Your option 1, pg_dump | psql does have the limitations you describe.
Your option 2 doesn't make much sense. You need to start out with a clone in order to set up streaming, and by the time you have the clone then you don't need the streaming, as you already have the clone. Also, you don't have to "reconfigure both to disable replication again". When you ...
You can us the below T-SQL command to query the registry and confirm is Replication Components are installed:
DECLARE @installed int;
EXEC @installed = sys.sp_MS_replication_installed;
if @installed = 0 then replication is not installed. That stored procedure actually reads the registry using the below command, ...
So a number of things here... (e.g. this will be a long answer and may go through a number of iterations):
First and foremost did this AG experience a failover? If not, then checking the ERRORLOGs on the Primary node is where I suggest you start your troubleshooting process; if a failover did occur, check the ERRORLOGs on the node formally known as the ...
The SQL Server error log only captures errors having a significant severity (generally 19-25, with exceptions). See the documentation here:
Imagine if all divide by zero, ambiguous column, or syntax errors flooded the error log? That log would quickly ...
Separate from your Replication solution, could use a Failover Cluster Instance or Basic Availability Group for HA of your publisher.
Or, if you have a stomach for obscure replication solutions, you could implement Bidirectional Transactional Replication, which is similar to Peer-to-Peer replciation, but older and available on Standard Edition.
Is there a reason, other than tradition, that you need SQL01 to return to being the "primary"? You could do just a single flip, and skip the confusing mess of short-term log shipping:
Original state: Primary database on SQL01, set up to replicate all tables to SQL02.
When you do maintenance on SQL02, replication will queue up changes in the distribution ...
The way to go is a plain format pg_basebackup.
Just make sure that --wal-method=stream, and the backup will contain all required WAL files.
Then start the server on the backup directory, and it will perform recovery and come up.
There is no need to mess with pg_receivewal.
The client inserts data to the primary database (replication cannot be done because of disconnection) that committed.
That can only happen if you configure the replica to be in Asynchronous-commit mode;
Asynchronous-commit mode is a disaster-recovery solution that works
well when the availability replicas are distributed over considerable
I also had the same issue using Mariadb 10.4 master-slave replication.
I was using the setting innodb_thread_concurrency in the config file with a non-zero value. I updated it to:
innodb_thread_concurrency = 0
And now it's working again.
It took me almost 2 days to resolve, but the following solved my issue
Even with the latest drivers installed the snapshot agent will still use the older version drivers that come with SQL Server 2019.
This has to do with the Path variable in your environment. Have a look at System Properties, Advanced System Settings, Environment Variables, System ...
Do you think this plan will work?
Without a lot of headaches, no I don't. Most times I have witnessed an attempt to use replication for DR it has failed. Every time I've witnessed an attempt to 'fail-back' from a replication 'failover' it has failed miserably.
As you've mentioned, replication is not a HA/DR technology and shouldn't be used as such. If you'...
I know by default SQL Server replication adds WITH NOCHECK and NOT FOR REPLICATION
Not quite. By default they are CHECK or NOCKECK to match the constraint on the publisher, but set to NOT FOR REPLICATION, so updates from the distribution agent do not fire the constraint.
You can choose
1) Whether or not the constraints are copied in the first place in ...
I have used a Domain Account for Snapshot Agent and Log Reader Agent,
If you check this answer:
The process could not connect to Subscriber
you will see that the SQLAgent account must have a login on your ServerB and must be a db_owner on your subscription database there.
It does not need to be a sysadmin on your ServerA.
It has ...
Yes, completely safe. The subsequent rsync performed under snapshot conditions will ensure that the data is properly aligned using the delta method.
One might want to ensure that there isn't an accumulation of irrelevant data files by using the --delete option (think carefully about what you are excluding) but this is a mostly separate issue.
Every write is performed on every machine, whether it is a Master or a Slave. The corollary to that is that there is a limit to write scaling with traditional Replication. Even Galera and Group Replication are just variants on Master(s) and Slave(s). Each server has all the data, and it is kept as up-to-date as is practical.
Hence, Sharding is the only ...
Very simplified, but when the connection between primary and the replica is lost, one of them (primary or replica) will no longer have a quorum. AlwaysOn is designed that way that you should be able to have only one quorum at the time.
Node without the quorum will become not available for connections and wait until it can belong to quorum and data are synced....
What does 'grow unmanageable' means for me?
This all depends on your environment. If you had a DB that was subject to a lot of transactions (one with a lot of CRUD operations), then this table would grow much faster and larger than one with minimal changes making it harder to manage.
Will it have very negative impact on the performance or storage in ...
You cannot use the listener name to access administrative shares on the cluster nodes. When accessing a cluster network name (which is what a listener is), shares are scoped to clustered shared folders only.
Please see Deploying a two-node clustered file server for reference.
Replication is not a DR technology in SQL Server, so you should never consider that for DR purposes. In SQL 2016 Standard Edition, you should look at Basic Availability Groups.
Setting up a Basic AG for this database will provide you with DR capabilities and will allow for failover without breaking the flow of data between your replicas.
yes, that is possible - you create 3 different publications - and in each publication you add only the respective tables you want for each server.
for example - only 2 tables for server1
The other tables will be in other publications, not this one.
Alternatively, within the merge replication you can set up filters and each subscriber would see only a ...
Can I choose which databases/collections are replicated ?
A replica set is a group of mongodb instances that maintain the same data set, so it is necessary for the entire set of data to be replicated between nodes.
Is a 2-members (a primary and a secondary) replica set eligible ?
A replica set should have an odd number of voting members. If you want ...
Your currently installed instance is at version 13.0.4466.4 (2016 SP1-CU7-GDR), and your installation media is at a lower patch level for the same major version (in your case, 2016 SP1, without the CU).
When you install an additional component (Replication, Full-text search, etc) with install media at a lower version, the installation will succeed, but ...
I posted a general question at security.stackexchange If no one knows a password, is there a reason to change it? as of this writing it has 3 answers.
The consensus is, two part
If you know that the password can not have been compromised there is no reason to change it.
But what if it was compromised and you don't know it. By not changing you leave your ...
You understood correctly. Since streaming replication keeps the replica a physical copy of the primary database cluster, you can only replicate between one primary and one replica.
There are two options:
Keep three clusters on the replica machine, one for each primary cluster.
Use logical replication.
With logical replication, you have to make sure that ...