I have a transactional SQL Server replication set up. Currently everything I have review seems to show that the replication is working. I have reviewed the Replication Monitoring and Sync State and both show that transactions are being pushed across correctly.
The problem I am having is that some of the replicated tables aren't even coming across while other are. Is there a better way to look deeper into Replication to find out why things aren't coming across?
Are you sure the tables are selected as articles in the publication properties? If so you may want to try validate subscriptions. As a last and most manual resort you can use tablediff.exe to compare two tables. The EXE will be located on your SQL server and will need to be run from the command line. Here's the syntax that worked for me. Replace the all caps items with names for your environment.
tablediff -sourceserver INSTANCE1 -sourcedatabase DATABASE1 -sourcetable TABLE1 -destinationserver INSTANCE2 -destinationdatabase DATABASE2 -destinationtable TABLE2
Related
I have set up an Azure database instance which supposedly replicates into a 'read only' secondary database using standard geo-replication. In the Azure portal I can see the status of the replication is 'online' and 'Secondary type' is 'Offline', which appears to be normal.
My question is, is there a way for me to see the actual contents of the secondary database, to ensure the replication is actually working as planned?
I cannot 'Manage' the database in the portal. I can connect to the instance in SQL Management Studio, where I can see the database but expanding tables / stored procedures shows nothing (a bit like connecting to a secure database using the non-secure connection string). I am also not able to run any queries against it as it gives me 'Connection to an offline secondary database is not allowed.'
I've searched this site an did a web search for an answer but can't seem to find one. Am I supposed to blindly rely on the fact that Azure is perfoming the replication correctly (with no way to double-check), or am I missing something here?
Many thanks in advance for any light you are able to shed on this.
Standard Geo-Replicated Secondary DBs are offline copies that do not accept client connections (so there is no way to query the data directly). If you need a readable Geo-Replicated Secondary then you must use the Active Geo-Replication available for Premium DBs.
Even though you can't query Standard Geo-Replicated DBs directly, you can use the DMVs in the Master to determine if the continuous copy is working correctly.
On the Master try the following:
SELECT * FROM sys.dm_database_copies
SELECT * FROM sys.dm_Continuous_copy_status
I hope this helps!
For more information about Standard Geo-Replication, Active Geo-Replication Or Checking the activity of continuous copy use the following links.
Standard Geo-Replication: https://msdn.microsoft.com/en-us/library/azure/Dn758204.aspx
Active Geo-Replication: https://msdn.microsoft.com/en-us/library/azure/dn741339.aspx
Continuous Copy DMV Blog: http://www.sqlservercentral.com/blogs/pie-in-the-sky/2014/12/25/monitoring-geo-replication-in-sql-azure-using-dmvs/
I tried to repro your situation and I think I understand the confusion.
When the Secondary Type = "Offline" then it is a standard Geo-Replicated Secondary. The Primary Databases page is confusing, but when you click on the link to the secondary should show that it is offline.
As far as understanding if the continuous copy is working, run the script below against the Primary (I was mistaken last time, Sorry).
SELECT * FROM sys.dm_Continuous_copy_status
You should see the linked server, database, and Replication State.
As before if you need to read from your secondary, you will have to created a premium active-Geo Replicated Secondary.
Hope This helps!
I need suggestions on how i could accomplish this...
i have 3 employee solutions
Every solutions with its own DB
what im trying to do is to unify all these three DB into one. i would also like to be flexible enough to add some other employee solution in the future.
i would also like to use SSIS.
what i've been thinking is, creating a SSIS package where opens a DB and import all data, this SSIS package would use "something" where it says the column mapping of certain DB so the SSIS knows what clumns import...
I tried to be as clear as possible... Any ideas?
thanks in advance
So if you add a new employee to the central DB it should be pushed out to the other three. If the other 3 have different schemas and different platforms then when you add an employee you need to work out which db it is going to, and you need custom insertion code for each db. Also you need to think about what happens if the same person is accidentally added to the central and remote db with slightly different information. You'll end up with a duplicate in the remote db. This is more of a master data application than a reporting application if I understand your requirement correctly.
Your first step is to come up with a schema for your central db, and this has to accomodate all of the information in the three remote db's. Then you need to think about rules ffor merging information accross all these DB's. i.e. if one DB has 'Eye Colour' and the other two don't, and you then create an employee with eye colour into your central db, but the target db doesn't have that field, is that OK? What happens if someone changes the DOB in a source DB, is that meant to update the central DB. What if you do it in both DB's at the same time - who is the winner?
What is the business problem that you are trying to solve?
We currently have merge replication set up to merge certain tables between two databases. I need to programmatically start one of the publications to make sure data has been synchronized prior to starting a certain job. SQL Server Books Online has not been too helpful.
So far, the only thing I have come up with is to use sp_start_job to start the merge replication sql job. Is it ok to do this?
Are there any other ways to programmatically start synchronizing a publication?
We ended up using the sp_start_job with the name of the merge replication publication. The only downside that we found was that the name of the sql job is dynamically generated when the publication is created so if the publication is drop and recreated, then the name will change. Other than that using sp_start_job has worked beautifully.
Couple other things:
The sql user was added to SQLAgentOperatorRole to allow the call to sp_start_job
sp_help_job was used to indicate if the job completed successfully before proceeding
I am having a problem with one database on my SQL Server 2005 production server.
A number of databases are already set up for mirroring, however when I right click and go to properties in SSMS, on one particular database there is no "Mirroring" property page available.
I have done the normal tasks, such as setting Full Recovery model, running a full backup of the database and backing up the logs.
I can't see that this is a server specific issue as other databases are happily mirroring.
I've looked around and I can't see that I'm missing a setting, any help would be appreciated.
Thanks.
EDIT: This is nothing to do with the Mirror Database yet, I can't get as far as specifying the Mirror Database , I cannot see the "Mirroring" page on the principle.
EDIT: I have managed to setup mirroring using t-sql commands. However I am still unable to see the "Mirroring Page".
UPDATE: This applies to the Transaction Log Shipping option as well. I can successfully set it up in SQL but not through SSMS.
Check theese items:
2 . The mirror database has to be created from a full backup of the principal server and should be restored in "Restore with Norecovery" model. It is followed by a restore of transaction log backup of the principal database so that the log sequence numbers of the mirror and the principal database are in synch with each other.
3 . The mirror database must have the same name as the principal database.
...
8 . DB Mirroring is available in Enterprise, Developer and Standard Editions, however, please refer to Microsoft website for a comparison chart as some features are not available in the Standard Edition. SQL Server Workgroup and Express Editions can only be used as witness servers.
Database Mirroring in Microsoft SQL Server 2005
Test monitoring with sp_dbmmonitorresults (Transact-SQL)
I don't have the answer, but I ran across the same symptom yesterday, and I remembered your question here, hahaha. My problem was that I set up database mirroring using the wizards, but one of the systems had a firewall blocking the mirroring port. The wizard setup went all the way to the final part of enabling database mirroring, and then errored out - but at that point, mirroring was already set up. Mirroring worked great, but there was something in the database metadata that wasn't set quite right. Even when I removed the firewall, parts of SSMS acted as if mirroring wasn't set up for that particular database, even though it was.
I then set up additional databases for mirroring (with the firewall off) and they worked great. My solution was to remove mirroring on that database and then add it again, and it worked fine. Doesn't sound like that's worked for you, though.
I ended up having to have a Microsoft Support call for the problem I was facing. Anyway after sometime and a number of support sessions they worked out that the database with the problem had an ID of 4 in sys.databases. IDs 1-4 are usually reserved for the system databases and if a database has any of these ids the T-log or Mirroring properties are not displayed. So somehow our database got the ID 3 and now I better get on and detach and reattach some databases to reassign IDs.
We've got a product which utilizes multiple SQL Server 2005 databases with triggers. We're looking for a sustainable solution for deploying and upgrading the database schemas on customer servers.
Currently, we're using Red Gate's SQL Packager, which appears to be the wrong tool for this particular job. Not only does SQL Packager appear to be geared toward individual databases, but the particular (old) version we own has some issues with SQL Server 2005. (Our version of SQL Packager worked fine with SQL Server 2000, even though we had to do a lot of workarounds to make it handle multiple databases with triggers.)
Can someone suggest a product which can create an EXE or a .NET project to do the following things?
* Create a main database with some default data.
* Create an audit trail database.
* Put triggers on the main database so audit data will automatically be inserted into the audit trail database.
* Create a secondary database that has nothing to do with the main database and audit trail database.
And then, when a customer needs to update their database schema, the product can look at the changes between the original set of databases and the updated set of databases on our server. Then the product can create an EXE or .NET project which can, on the customer's server...
* Temporarily drop triggers on the main database so alterations can be made.
* Alter database schemas, triggers, stored procedures, etc. on any of the original databases, while leaving the customer's data alone.
* Put the triggers back on the main database.
Basically, we're looking for a product similar to SQL Packager, but one which will handle multiple databases easily. If no such product exists, we'll have to make our own.
Thanks in advance for your suggestions!
I was looking for this product myself, knowing that RedGate solution worked fine for "one" DB; unfortunately I have been unable to find such tool :(
In the end, I had to roll my own solution to do something "similar". It was a pain in the… but it worked.
My scenario was way simpler than yours, as we didn't have triggers and T-SQL.
Later, I decided to take a different approach:
Every DB change had a SCRIPT. Numbered. 001_Create_Table_xXX.SQL, 002_AlterTable_whatever.SQL, etc.
No matter how small the change is, there's got to be a script. The new version of the updater does this:
Makes a BKP of the customerDB (just in case)
Starts executing scripts in Alphabetical order. (001, 002...)
If a script fails, it drops the BD. Logs the Script error, Script Number, etc. and restores the customer's DB.
If it finishes, it makes another backup of the customer's DB (after the "migration") and updates a table where we store the DB version; this table is checked by the app to make sure that the DB and the app are in sync.
Shows a nice success msg.
This turned out to be a little bit more "manual" but it has been really working with little effort for three years now.
The secret lies in keeping a few testing DBs to test the "upgrade" before deploying. But apart from a few isolated Dbs where some scripts failed because of data inconsistency, this worked fine.
Since your scenario is a bit more complex, I don't know if this kind of approach can be ok with you.
As of this writing (June 2009) there's still no product on the market that'll do all this for multiple databases. I work for Quest Software, makers of Change Director for SQL Server, another database change automation system. Ours doesn't handle multiple databases like you're after, and I've seen the others out there. No dice.
I wouldn't hold out hope for it either, given the directions I've seen in SQL Server management. Things are going more toward packaged applications being contained in a single database, and most of the code is focusing on that.