SQL Server Dababase data split

Question

Dear All,
I have a database with 235 GB Data. Now currently database is shared by two countries transnational data. Now I got the requirement to separate the data of two countries as two individual databases.
Would you please suggest the best way to do this.
I have couple of questions here:
1) It has 300 tables and how can I generate all the constrains create script?
2)How can I delete the relationship of all tables?
3) after splitting the databases how can I make sure the integrity and How can I make sure to get the as is of same production database?
Thank you in advance
Srikanth

Answer 1

Before you arrived at these questions, you probably went through a mental process that made you ask these questions. Unfortunately, since we don't know that mental process, we don't really know what you have in mind.
My general take on this, is that I use BACKUP/RESTORE and make a copy of the database, and then run a bunch of DELETE operations in both databases to get rid of the unwanted data. My first approach would be do this in reference order, so that I don't
have to drop the constraints.
But, admittedly, this can be difficult to achieve. In that case I would run:
SELECT 'ALTER TABLE ' + quotename(s.nname) + '.' + quotename(o.name) +
       ' NOCHECK CONSTRAINT ALL '
FROM   sys.objects o
JOIN   sys.schemas s ON s.schema_id = o.schema_id
WHERE  o.type = 'U'
Copy the result and run it. This disables all constraints. (foreign keys
and CHECK constraints to be precise.)
And then the same operation to disable triggers.
When the deletion operation is completed, I would run
DBCC CHECKCONSTRAINTS WITH ALL_CONSTRAINTS
to verify that that there are no constraint violations.
Finally, reenable all triggers and constraints. When doing the latter, it is important to run it as:
SELECT 'ALTER TABLE ' + quotename(s.nname) + '.' + quotename(o.name) +
       ' WITH CHECK CHECK CONSTRAINT ALL '
FROM   sys.objects o
JOIN   sys.schemas s ON s.schema_id = o.schema_id
WHERE  o.type = 'U'
If you don't add WITH CHECK, SQL Server will not check the constraints when enabling them. This will leave them as not trusted, which means that the optimizer cannot use them.
Strictly speaking, you can skip DBCC CHECKCONSTRAINTS, since reenabling the constraints also checks that they are valid. However, DBCC CHECKCONSTRAINTS gives you better error diagnostics.
One challenge that I have not touch is integrity maintained by the triggers. This is something you will have to figure out.
Erland Sommarskog, SQL Server MVP, [email protected]