I have a huge database in production environment which I need to take a copy off, but the problem is that the data is over 100Gb's and downloading a backup off it is out of the question. I need to get a "skeleton" image of the database. What I mean by "skeleton" is, I need to get the database outline so that I can recreate the database locally by running SQL scripts.
Is there a quick and easy way to retrieve the SQL for recreating the database structure and tables?
Or will I have to write something in order to do this programmatically?
If you are using MS SQL Server then it's very easy to get your "skeleton". In the Object Explorer Right Click on the database node and then "Script Database as" and then "Create to". If the Database is in Oracle or something else sure there is a way also.
Managed to find this from Google.
I remember that if you can connect to the db from visual studio, visual studio have a publish tool, which can generate the script for you....
Hope this helps
Use the DDL Generate Scripts within SSMS :)
I need to get the database outline so that I can recreate the database locally by running SQL scripts.
Ask the guys who developed this application/database to provide you with the SQL scripts they used to create (and upgrade) the database. Hint: All these scripts should be in the project's source control repository, along with the rest of your source code. Yes, that's right, the SQL/DDL scripts are source code, too.
If the SQL/DDL scripts are not under source control, be very afraid, and run away from this project as fast as possible.
Related
I just lost some stored procedures in a test database. So I don't have to go through this again is there a way I can generate a script that I could use to recreate ALL my database objects. I am using the SSMS so I am hoping there's some option with that which will allow me to get a script for recreation of everything.
Right Click (the database in object explorer)
Tasks
Generate Scripts
or use a version control tool or documentation tool from some one like redgate
finally you could simply take regular backups
As suggested, you can generate scripts using management studio for any views or functions but
The ideal way is to keep a repository of every object in SVN , TFS or something similar.
We do it for our dev, test (and off course for prod). We do not treat non-prod environments as non-important.
We have an existing SQL Server database, and I'd like to create a Visual Studio database project for it and put some of the scripts for the stored procedures in that database in source control. So, I thought I would create a new database project. Is there a way I can wire up this database project to the database? I thought it might be "Add Database Reference", but that only gives me options to use some other database project in the current solution, not set up the current project to be connected to an actual database.
Ideally, I'd like to be able to right-click on my project and do a "Publish" and have all my database info prefilled. I realize that I might be thinking of this wrong, but searching around on the web is of little help. It is surprising how poorly these concepts are documented.
EDIT: After the first answer, maybe my question really is: How can I have only a part of a database managed in a database project? I had assumed this was an ordinary thing that people did all the time with database projects, but maybe not. In my case, I would like to have only some of the stored procedures in source control.
After further reasearch, it seems the answer is, "no, there is no way" to have only a part of a database managed in a database project.
I'm using vs 2013 but i think this is valid back VS 2008
Right click database project.
Then choose -> import -> database.
Setup a connection to your target database.
When you import select the import setting Folder structure Schema\Object type
And run the wizard.
This builds a folder structure containing sql script for your schema objects.
Alternatively if you have sql data tools you could run the schema compare against a blank project.
We've got a SQL Server instance with some 15-20 databases, which we check in TFS with the help of RedGate. I'm working on a script to be able to replicate the instance (so a developer could run a local instance when needed, for example) with the help of these scripts. What I'm worried about is the dependencies between these scripts.
In TFS, RedGate has created these folders with .sql files for each database:
Functions
Security
Stored Procedures
Tables
Triggers
Types
Views
I did a quick test with Powershell, just looping over these folders to execute the sql, but I think that might not always work. Is there a strict ordering which I can follow? Or is there some simpler way to do this? To clarify, I want to be able to start with an completly empty SQL Server instance, and end up with a fully configured one according to what is in the TFS (without data, but that is ok). Using Powershell is not a requirement, so if it is simpler to do some other way, that is preferrable.
If you're already using RedGate they have a ton of articles on how to move changes from source control to database. Here's one which describes moving database code from TFS using sqcompare command-line:
http://www.codeproject.com/Articles/168595/Continuous-Integration-for-Database-Development
If you compare to any empty database it will create the script you are looking for.
The only reliable way to deploy the database from scripts folders would be to use Red Gate SQL Compare. If you run the .sql files using PowerShell, the objects may not be created in the right order. Even if you run them in an order that makes sense (functions, then tables, then views...), you still may have dependency issues.
SQL Compare reads all of the scripts and uses them to construct a "virtual" database in memory, then it calculates a dependency matrix for it so when the deployment script is created, things are done in the correct order. That will prevent SQL Server from throwing dependency-related errors.
If you are using Visual Studio with the database option it includes a Schema Compare that will allow you to compare what is in the database project in TFS to the local instance. It will create a script for you to have those objects created in the local instance. I have not tried doing this for a complete instance.
You might have to at most create the databases in the local instance and then let Visual Studio see that the tables and other objects are not there.
You could also just take the last backup of each database and let the developer restore them to their local instance. However this can vary on each environment depending on security policy and what type of data is in the database.
I tend to just use PowerShell to build the scripts for me. I have more control over what is scripted out when so when I rerun the scripts on the local instance I can do it in the order it needs to be done in. May take a little more time but I get better functioning scripts for me to work with, and PS is just my preference. There are some good scripts already written in the SQL Community that can help you on this. Jen McCown did a blog post of all the post her husband has written for doing just this, right here.
I've blogged about how to build a database from a set of .sql files using the SQL Compare command line.
http://geekswithblogs.net/SQLDev/archive/2012/04/16/how-to-build-a-database-from-source-control.aspx
The post is more from the point of view of setting up continuous integration, but the principles are the same.
I'm planning to use source control for SQL Server database. I have different versions of SQL Server (2005 and 2008) running on different machines (Windows 2003 and 2008). I looked up about source control and found out 2 options.
http://nobhillsoft.com/Randolph.aspx
http://www.red-gate.com/products/sql-development/sql-source-control/
So I was just wondering if someone have experience with them and suggest me which one would be good out of these or any other better option?
Thanks!
In my opinion, you may be approaching something here from the wrong angle. If you try to revert a change to the table structure, but the table has been populated with data fitting the new table structure, what happens? It's more complex than maintaining plaintext diffs. I encourage you to really look at the idea and see if you can accomplish this another way, and document your database design as completely as possible every time you need to change it.
That being said, here are some more ideas.
http://www.sqlservercentral.com/Forums/Topic753558-361-1.aspx
http://www.sqlservercentral.com/Forums/Topic635185-145-1.aspx
I compare all these options and going with Red-gate source control and data source solution. Thanks for all suggestions!
You can use your current version control system if it's suitable for you to store only installation SQL script of a database.
Use SSMS to produce installation script: right-click on desired databased, select Tasks -> Generate Scripts... Script Wizard will start and help you to script any objects you need in the database including data. Save this script under your version control system since it's text file.
Use this database installation script to reproduce the database at desired location and environment.
I need to create an entirely new Sql Server 2008 database and want to use a Database Project in Visual Studio 2010 (Ultimate). I've created the project and added a table under the dbo schema.
The table .sql is shown only as plain text, though with colors. It has no designer, no Add Column, and no autocomplete. Existing column's properties are grayed out.
Usually, I use DB Project for nothing more than storing .sql files for source control purposes, but I'm assuming it can help me with designing the DB. Currently, it offers no such help and I think it's because I'm doing something wrong. Perhaps I need to deploy the DB to server first, or something of the such. I've looked for a Getting Started guide, but all guides I found start from importing an existing database.
Please help my understand what a DB Project can do for me and how.
Thanks,
Asaf
The whole idea of the VSTS DB is to get you set on the right path, ie. store database object definitions as .sql files, not as some fancy diagram. Any modification you do to the objects you do it by modifying the SQL definition. This way you get to do any modification to the objects, as permitted by the DDL syntax, as opposed to whatever the visual-designer-du-jour thinks you can and can't do. Not to mention the plethora of SQL code generation bugs associated with all designers out there.
The closes to a visual view is the Schema View, which shows tables, columns, indexes etc in a tree view and you can see the properties from there.
By focusing the development process and the Visual Studio project on the .sql source files, teams can cooperate on the database design using tried and tested source control methods (check-out/check-in, lock file, conflict detection and merge integration, branching etc).
the deliverable of a VSTS DB project is a the .dbschema file, which can be deployed on any server via the vsdbcmd tool. This is an intelligent deployment that does a a schema synchronization (merge of new object, modifies existing ones) and can detect and prevent data loss during deployment. By contrast, the 'classical' way of doing it (from VS Server eExplorer, or from SSMS) the deliverable was the MDF file itself, the database. This poses huge problems at deployment. The deployment of v1 is really smooth (just copy the MDF, done), but as soon as you want to release v1.1 you're stuck: you have a new MDF, but the production is running on its own MDF and does not want to replace it with yours, since it means data loss. Now you turn around and wish you have some sort of database schema version deployment story, and this is what VSTS DB does for you from day 0.
You might be better off downloading the SQL Server Management Studio for SQL Server 2008 Express - http://www.microsoft.com/downloads/details.aspx?FamilyId=C243A5AE-4BD1-4E3D-94B8-5A0F62BF7796
Using this tool you can create your database using the visual tools provided by that software. You can run your .sql script to build up the database and then visually adjust columns settings, table relationships, etc.
Once you have your database designed open up Visual Studio and open a connection to this database using the Server Explorer.
Visual Studio is ok for simple tweaks and changes to an existing database structure but for anything serious like making the database from scratch I would recommend using the Management Studio. It's free and built for that exact purpose :)