Are there any SQL Server Replication Best Practices? Are there any links I can read up on?
I’m using 2012 and 2014. I want to know, in general, what type of database objects typically people replicate
from the source instance (publication) to the target instance (subscription)? Table is definitely one of them.
If there are a lot of views associated with the source database and probably not being used in the replicated
database (target/subscription), should I include them in the replication process? What about stored
procedures? In both cases, would it be better just to replicate the data and manually deploy the views and
stored procedures? I’d like to get some ideas/suggestions? Thanks
Here are some resources that cover replication best practices and improving performance:
Best Practices for Replication Administration
Enhance General Replication Performance
You can find a list of database objects that can be published using Replication here:
Publish Data and Database Objects
If the objects are being used at the replicated database (subscriber) then yes, you should replicate the objects. If not, feel free to exclude them from the publication.
The benefit of including them in the publication, rather than manually deploying them, is that replication supports schema changes to published objects and when you make schema changes on appropriate published objects at the Publisher, those changes are propagated by default to all Subscribers. This is covered in Make Schema Changes on Publication Databases.
We have a requirement where we will have to move data between different database instance on regular basis. (For e.g. some customers willing to pay more for the better performance). So this is not going to be one off.
The database tables has referential integrity. Is there a way in which this can be done without rewriting sql script (or some other method) every time we migrate customers data?
I came across this How to move data between multiple database's table while maintaining foreign-key relationships/referential integrity?. However it appears that we have write script every time we migrate data (please correct me if I misunderstood the answer on this thread).
Thanks
Edit:
Both servers are using SQL Server 2012 (same version). Its an Azure SQL Server database.
They are not necessarily linked (no firewall between them)
We are only transferring some data, not the whole database. This is only for certain customers who opted pay more.
The schema are exactly same in both databases.
Preyash - please see the documentation on the Split-Merge tool. The Split-Merge tool enables you do move data between databases, as you have described, based on a sharding key (e.g., customer ID). One modification that you will need for your application is to add a shard map (i.e., a database that understand the global state of which customers resides in which databases).
Have a look into Azure Data Sync. It is much more aligned with your requirements. But you may end up in having another SQL Azure DB to maintain a Hub. Azure data Sync follows hub-spoke pattern and will let you do all flexible directional syncs with a few minutes of syncing gap. It is more simple and can set it up very fast without any scripts and all as you wanted.
Can I store any custom tables in SharePoint's own database?
Is this supported behavior or not?
(I mean tables in MS SQL database, not SharePoint lists.)
If I can, how well does this play with backup/restore functionality?
What are possible caveats?
For anyone wondering why I'm asking: there's an app which is bound to SharePoint server and needs to store some purely relational internal information that doesn't make sense apart from that SharePoint instance. I would like to narrow down data storage to one place but I'm not sure if SharePoint likes its database being used for other purposes.
I'm using SharePoint 2007.
Is it possible? Sure. Should you? Nope.
The SharePoint content/configuration databases are subject to change with any update Microsoft releases, and any changes you make will very likely be destroyed, and if your farm depends on them, be left non-functional.
If you want to store purely relational data in a set of tables, just create another database. There's nothing stopping you from using the same SQL Server instance that houses your SharePoint content and/or configuration databases to store other relational databases as well.
Not a good idea: Support for changes to the databases used by Windows Sharepoint Services
...
Making any modification to the database schema
Adding tables to any of the databases
...
If an unsupported database modification is discovered during a support call, the customer must perform one of the following procedures at a minimum:
Perform a database restoration from the last known good backup that did not include the database modifications
Roll back all the database modifications
It is even worse than the above. It is likely that future upgrades will notice your changes to the content database schema and refuse to upgrade the database period.
Little background: I'm working in a large company with a lot of branches. We have several applications with separated databases sometimes on different servers. But every database contains a table with a list of branches and their relationships. I want to automatically synchronize these tables when one of them changed.
My question is: what are the best practices of automatic synchronization of tables in different databases (Microsoft SQL Server 2008)?
Are there sql server features for that purpose? Or external tool is a good way? Or it's better to write a small application and run it as a service or use the scheduler?
You can use replication (a SQL server built-in feature) to synchronize different databases.
You can also use triggers or log shipping to sync your tables as records are added ,updated or deleted:
Here are some links about replication.
Here are some links about log shipping.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We all have our favourite database. If you look objectively at your chosen database, what drawbacks does it have and what could be improved?
The rules:
One reply per drawback with;
a short description of the limitation, followed by;
a more detailed description, an explanation of how it could be done better or an example of another technology that does not have the same limitation.
Do not diss any database that you haven't used extensively. It is easy to take potshots at other technologies but we want to learn form your experience, not your prejudice.
Oracle databases are quite expensive
Oracle does what it does well but the licensing costs are horrendous. That has been improved by the release of Oracle XE but the limitations of that mean that it is a growth constraint on you solution.
Database Microsoft SQL Server 2005
Defect Lack of "INSERT OR UPDATE"
Description
Often you need to either insert or update a record in a table, depending on whether the record is present or not. Not having an atomic operation to do so leads to unnecessary transactions.
This does not happen with MySQL or SQLServer 2008.
Database PostgreSQL
Defect No SQL Profiler
We asked the developers about this at a recent conference and I understand it's now something they're looking to implement.
I love the flexibility of sequences in Oracle as compared with other databases autoincrements, but the inability to set seq.nextval as a default for a pk column is somewhat annoying, and must be trivial to fix.
Database Microsoft SQL Server
Defect Huge licensing cost
Description
SQL Server has great features and it integrates very well with .NET development. The issue is that when you have to scale up from a shared database to a dedicated database, licensing costs are really high. This, in effect, leads to databases which should really run on a dedicated server, being hosted on shared servers with performance and security issues.
This does not happen with MySQL or PostgreSQL.
Database Microsoft SQL Server 2005
Defect Badly implemented UI
Description
SQL Server management studio does not offer a great user experience:
Tabbing behaviour is weird: you are always looking for the right tab
Keeps on crashing on 64-bit versions
Missing some features of preceding version, like overview of grants of stored procedures
This does not happen with version 2000.
Database MySQL
Defect Server will start up with damaged tables
Description
If MySQL has a damaged table - from either being killed during a write or some other failure - it will quite happily start up and allow the user to carry on as if the problem does not exist. Granted it will produce some error messages in the log, but from my experience this doesn't help when you're trying to figure out why an application is behaving oddly.
Most other databases will detect and repair the error on startup or simply refuse to start with any sort of corruption.
Database MySQL 5.0.x and above
Defect Ring replication errors lead to inconsistent data on different nodes
Description
The most serious problem in production we face at the moment is that in a MySQL ring the ring itself produces an error and stops replicating.
Building a ring (or Master-Master-replication) is possible since 5.x.x: You chain the databases in a "ring" so that the replicate data to each other. Every database-node gets all the changes from all other nodes.
We assume that the error lies behind autoincrement- failures. This is known from normal replication, too, but in the new version there are no sufficinet error messages in the error log. I highly recommend not to use this feature in MySQL as long as the problems here are not fixed.
Database Oracle
Defect Did not handle long datatype well for too long
Description
Oracle only had the long datatype until 9i (I believe) at which point it was deprecated in favor of the LOBs. There is a ton of code out there, however, which still has longs and all of the related restrictions. The biggest of which was that each table could only have one long column and it had to be at the end of the columns. See here for a more exhaustive list of restricitons on the long.
Database Oracle
Problem Temp table definitions are not private
Description Many databases (eg Postgres and Sybase) allow you to create temp tables on the fly, insert into them, add indexes if you want, then query from them. Oracle has temp tables, but the temp table definitions exist in a global name space. Therefore the temp table has to be created by a DBA, you need to synchronize between the table definition they used and your code, and if two pieces of code want similar (but not identical) table definitions, they need to use different names. These differences make temp tables far less convenient for developers.
Yes, I understand the benefits for the query optimizer of having global definitions. However for me the lack of convenience makes Oracle's temp tables virtually useless for me, while I use them very intensively in Postgres.
Database: Oracle
Problem: The names of tables, procedures, columns, etc cannot exceed 30 characters. This is infuriating.
Problem: It's slapdash JDBC compliance. For example, stored procedures do not return results sets in a JDBC-compliant way, but instead of a proprietary OUT parameter type. This means you can't use higher-level JDBC abstractions.
Database MySQL
Defect Foreign Keys supported only on some table types
Description
Enough said. It has obvious maintenance implications.
From the MySQL manual
Foreign keys definitions are subject to the following conditions:
Both tables must be InnoDB tables and they must not be TEMPORARY tables.
And here:
For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it.
This does not happen with any other major DB.
PostgreSQL doesn't have a good failover solution, but I understand they're working on it.
Database : Sql Compact Edition
Drawback : Stored procedures are not supported.
Regardless of this limitation, this DB has its' uses especially as a client cache for application that can be smart client or distributed to mobile platforms.
Database Oracle
Defect Granularity of grants on packages
Description
You can only grant permissions on packages and not on stored procedures inside packages. Or alternatively, you can grant permissions on single stored procedures but then you put them outside of packages. This requires you to know up front who will use which stored procedure and it is really hard to refactor.
This does not happen with SQL Server.
Database Microsoft SQL Server 2005
Defect Lack of array type parameters
Description
Useful in searches, a lot of times you need to pass a series of values to be matched against. In SQL 2005 you can do a workaround by using CLR inside SQLServer. Given the usefulness it would make more sense to have this feature out of the box.
This does not happen with SQL Server 2008 or Oracle.
Database Postgres
Defect No analytic queries
Description
Analytic queries, introduced by Oracle, are part of the SQL 2003 standard. Unfortunately Postgres hasn't implemented them yet.
Database : PostgreSQL
**Problem : ** is that connector for C# for example are not really up-to-date and crash with advanced feature.
Database: All
Drawback - Poor design by people who didn't think it was important to know what you were doing when you designed a datbase. Far more problmes caused in all databases by bad design than from any missing feature. So I suppose they are all missing the "read my mind and figure out the best solution without me having to think" feature.
Any SQL DBMS
Defect: Duplicate rows
One of the virtues of the relational model is that it represents everything without duplicate tuples, i.e. using relations, which have keys and no duplicates. Unfortunately SQL isn't built that way. This makes the database developer's life needlessly difficult. SQL developers have to deal with tables without keys and debug queries that return duplicate rows.