Migrating only database structure having lakhs of objects

  • Jeff Moden - Tuesday, March 13, 2018 10:10 PM

    coolchaitu - Tuesday, March 13, 2018 9:47 PM

    Jeff Moden - Tuesday, March 13, 2018 6:28 PM

    I know it's not helpful but having "lakhs" of database objects usually means that there's a pretty bad database and application design going on even if it's spread across several databases, never mind just one.

    True Jeff. But, could you please help me with the solution

    Have you tried what ZZMartin suggested above?  Go ahead and select all the objects you want in the SSMS script generator but have each object create its own file.

    The trouble is going to be when you try to use those scripts because of dependencies and any dependencies within SQL Server could be incorrect.  Even if you could generate all the objects to a single file, there is no guarantee that they will be in the correct order.

    Hmmmm... I've never tried it but maybe create a totally empty new database and do a RedGate SQL Compare between your 10TB db and the empty database to gen the difference script might do it.  Pray that you don't have any circular dependencies.

    Back in the olden days, we would generate the scripts for the various types of objects in separate scripts. Tables, primary keys and unique indexes, foreign keys, indexes, defaults, constraints, triggers(ugh), views, procs, etc. 
    In order to create the database, we created the bare tables.  The data would then be inserted.  As the various constraints were applied, and errors appeared, it would expose the errors in the data, or objects being created out of order

    It was a slow, manual process, but something along those lines may work.

    Michael L John
    If you assassinate a DBA, would you pull a trigger?
    To properly post on a forum:
    http://www.sqlservercentral.com/articles/61537/

  • Michael L John - Wednesday, March 14, 2018 5:57 AM

    Jeff Moden - Tuesday, March 13, 2018 10:10 PM

    coolchaitu - Tuesday, March 13, 2018 9:47 PM

    Jeff Moden - Tuesday, March 13, 2018 6:28 PM

    I know it's not helpful but having "lakhs" of database objects usually means that there's a pretty bad database and application design going on even if it's spread across several databases, never mind just one.

    True Jeff. But, could you please help me with the solution

    Have you tried what ZZMartin suggested above?  Go ahead and select all the objects you want in the SSMS script generator but have each object create its own file.

    The trouble is going to be when you try to use those scripts because of dependencies and any dependencies within SQL Server could be incorrect.  Even if you could generate all the objects to a single file, there is no guarantee that they will be in the correct order.

    Hmmmm... I've never tried it but maybe create a totally empty new database and do a RedGate SQL Compare between your 10TB db and the empty database to gen the difference script might do it.  Pray that you don't have any circular dependencies.

    Back in the olden days, we would generate the scripts for the various types of objects in separate scripts. Tables, primary keys and unique indexes, foreign keys, indexes, defaults, constraints, triggers(ugh), views, procs, etc. 
    In order to create the database, we created the bare tables.  The data would then be inserted.  As the various constraints were applied, and errors appeared, it would expose the errors in the data, or objects being created out of order

    It was a slow, manual process, but something along those lines may work.

    Heh... I remember those days well.  Anything that got executed/created successfully was marked as "Complete" and we'll loop through a table of the objects until everything was marked as "Completed".  Actually, looking back, it was pretty darned fast.  The cool part was that we also marked the objects with a "pass" number which allowed us to do it in a single pass when we walked onto a customer site for an install.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply