transactional-replication

SQL Change tracking SYS_CHANGE_COLUMNS

由 霸气de小男生 提交于 2021-02-07 20:00:22
问题 We are running SQL 2008 R2 and have started exploring change tracking as our method for identifying changes to export to our data warehouse. We are only interested in specific columns. We are identifying the changes on a replicated copy of the source database. If we query the change table on the source server, any specific column update is available and the SYS_CHANGE_COLUMNS is populated. However on the replicated copy the changes are being tracked but the SYS_CHANGE_COLUMNS field is always

SQL Change tracking SYS_CHANGE_COLUMNS

由 不羁岁月 提交于 2021-02-07 19:59:24
问题 We are running SQL 2008 R2 and have started exploring change tracking as our method for identifying changes to export to our data warehouse. We are only interested in specific columns. We are identifying the changes on a replicated copy of the source database. If we query the change table on the source server, any specific column update is available and the SYS_CHANGE_COLUMNS is populated. However on the replicated copy the changes are being tracked but the SYS_CHANGE_COLUMNS field is always

Transactional replication with no primary key (unique index)

由 百般思念 提交于 2020-02-21 13:50:11
问题 I've just come across something disturbing, I was trying to implement transactional replication from a database whose design is not under our control . This replication was in order to perform reporting without taxing the system too much. Upon trying the replication only some of the tables went across. On investigation tables were not selected to be replicated because they don't have a primary key, I thought this cannot be it is even shown as a primary key if I use ODBC and ms access but not

Transactional replication with no primary key (unique index)

由 余生长醉 提交于 2020-02-21 13:50:09
问题 I've just come across something disturbing, I was trying to implement transactional replication from a database whose design is not under our control . This replication was in order to perform reporting without taxing the system too much. Upon trying the replication only some of the tables went across. On investigation tables were not selected to be replicated because they don't have a primary key, I thought this cannot be it is even shown as a primary key if I use ODBC and ms access but not

Replicate a filtered subset of data: Merge or Transactional replication?

由 ♀尐吖头ヾ 提交于 2019-12-12 14:09:21
问题 First of all thanks for reading. I need to replicate a subset of data that is based on a join filter; filter based on a join with an other table (Microsoft:"Using join filters, you can extend a row filter from one published table to another."). This is the setting: SQL Server 2012; replication sources on a subscription of a transaction replication replication needs to be one direction sync (from publisher to subscriber); only one subscriber/subscription; small dataset with not many

Consolidate data from many different databases into one with minimum latency

由 烈酒焚心 提交于 2019-12-12 09:53:38
问题 I have 12 databases totaling roughly 1.0TB, each on a different physical server running SQL 2005 Enterprise - all with the same exact schema. I need to offload this data into a separate single database so that we can use for other purposes (reporting, web services, ect) with a maximum of 1 hour latency. It should also be noted that these servers are all in the same rack, connected by gigabit connections and that the inserts to the databases are minimal (Avg. 2500 records/hour). The current

SQL Server 2008R2 Transactional Replication - Move SubscriberDB - Push Subscription

由 穿精又带淫゛_ 提交于 2019-12-11 06:53:04
问题 SQL Server 2008R2 Transactional Replication - Move SubscriberDB - Push Subscription I have a requirement to move a subscriber database to a new server outside of a system outage i.e. I cannot stop new transaction from loading into the publisher database. So far I have attempted to stop the distribution agent and let all un-replicated commands replicate to the subscriber database at Server1. Then backup and restore the subscriber database to Server2. I have then created a new subscription from

Consolidate data from many different databases into one with minimum latency

由 筅森魡賤 提交于 2019-12-05 23:46:20
I have 12 databases totaling roughly 1.0TB, each on a different physical server running SQL 2005 Enterprise - all with the same exact schema. I need to offload this data into a separate single database so that we can use for other purposes (reporting, web services, ect) with a maximum of 1 hour latency. It should also be noted that these servers are all in the same rack, connected by gigabit connections and that the inserts to the databases are minimal (Avg. 2500 records/hour). The current method is very flakey: The data is currently being replicated (SQL Server Transactional Replication) from
订阅 transactional-replication