I have a backup of a very big database.
What I want is to restore this database, but there is not enough space on my harddisk. Since I don't need the data, is there a way to restore it without the data?
I've already tried to script the schema etc. but when I run the script, it doesn't work unfortunately.
Thanks in advance
Use the Generate and Publish Scripts Wizard to create a Transact-SQL script for many objects. The wizard generates a script of all the objects in a database, or a subset of the objects that you select. The wizard has many options for your scripts, such as whether to include permissions, collation, constraints, and so on.
check here how to generate script-
SQL Server 2012 copy database without data
Do you have RedGate SQL Compare? If I only had a database backup available, I would run SQL Compare using the backup as source, and a brand new database as the target. The results of the compare should give you what you need, in the correct order of deployment.
Related
Me and my friend both have sql server 2012. I have a database where I would like to copy over most of the tables into a database on my friends laptop. I am not sure not sure how to go about doing this?
I know in sql server that I can copy over data from one table in say database A to database B using the line below.
select * into database_a.dbo.MyTable from database_a.dbo.MyTable
What is the best way to connect the two laptops?
You could take a full backup and give it to him to restore. Or you could give him a copy of the *.mdf file and let him attach it to his DB.
There are two main options, one is to back up the database and send it to your friend. To do this right click on the database, Tasks and Backup. The problem with this approach is that if you're running even slightly different versions you may have issues.
The alternative is to script the database. To do this right on the database, click Tasks and Generate Scripts. Make sure you choose to script data and schema from the advanced options.
The latter is my preferred approach (as it's much more editable and human readable).
Is there a way to backup/track changes to SQL stored procedures in SVN or any other method for tracking changes to SQL? I am using SQL 2008 and am not a DBA but am in charge of a small companies database.
TIA,
Brian Enderle
You might try Red Gate's SQL Source Control and SQL Compare to track changes.
We write procs and save them in Subversion as scripts. You check in each version of the script and then you can easily see previos versions or do a diff between them. If youwant to reduce unnecessary diffs from formatting, get a SQL formatting tool and have everyone format the same way before check in.
All SQL code should be handled this way not just procs. We store table strutures, views etc in Subversion. Of course with tables you havea create script and then alter table table scripts for each change in order, so that you don't wipe our tables with existing data by doing a drop and recreate. We also script out inserts to lookup tables to make them easier to port to other servers as well.
You can store it in svn, but it will have difficulty tracking exact changes if members of your team use different tools to write sql: postgresql seems to be particularly bad at formatting sql. You could consider using a free formatter: Eddie Awad lists some here:
http://awads.net/wp/2005/12/12/format-your-sql-the-easy-way/
Committing your code to source control depends on how you arrange your projects: your scripts could exist in a "misc" folder in an eclipse/visual studio project, or directly committed to svn via TortoiseSVN.
I have two suggestions for you (which I have both used myself):
you can use ScriptDB in order to extract the database schema to your file system and then commit it to svn. I actually set up a scheduled task which invokes ScriptDB every night and then commits the folder to svn (which only commits actually modified files) automatically.
If you are using VS2010 you can open a database project and synchronize it periodically with your database via the schema compare option from the data menu. After that you can commit your changes via tortoiseSVN or Ankh directly from VS.
I'm trying to head this one off at the pass. I've got two database servers (DEV and PRD) and I have my database on the DEV server. I am looking to deploy v1 of my application to PRD server.
The question is this: Say in two months, I am ready to ship v1.1 of my application, which introduces two new VIEWS, six new fields (three fields in two tables, each), and an updated version of my sproc that creates records in the tables with new fields. My DEV database has the new schema, but my PRD database has the real data, so I can't simply copy the .mdf file, since I want to keep my PRD data, but include my new schema.
I understand doing the initial creation of tables, views, sprocs via saved .sql files; but what I'm wondering is, is it possible to use SSMS to create the appripriate "alter table" scripts or do I need to manually do this?
I have handled this with a release update SQL script that applies the changes to the previous version.
You either need to code this yourself or use one of the many DBA tools to do database compares and generate a diff script.
There are tools that will do this for you SQL Compare is one of them and one I like the best
Otherwise you have to code these yourself and don't forget to also script the permissions if you recreate the proc (unless you use ALTER PROC in that case permissions are preserved)
Since your database changes should be in scripts that are under source control, you just load them with the version that you are moving to prod just like any other code associated with that version. One you you never under any circumstances do is make changes to the dev (or any other) datbase, using the User interface.
Try the patching engine found in DBSourceTools.
http://dbsourcetools.codeplex.com
DBSourceTools is a utility to help developers get their databases under source control.
Simply point it at a Source Database, and it will script all database objects, incuding data to disk.
Once you have a Target database (v1), you can then place your patch scripts int the patches directory, and DBSourceTools will run these patches in order after re-creating your database.
This is a very effective means of thoroughly testing your change scripts.
I'm using SQL 2005. I can right click on a database and create scripts for the database that will recreate the structure (tables, views, stored procedures) elsewhere. Or just as a backup, version, etc.
But, is there a way I can schedule it to do this? And output to a folder I choose?
I really appreciate the help.
Don
You could schedule this using SMO probably, though it may take some work to get up and running.
However, a more elegant approach might be to schedule a full backup to a new file (with today's timestamp), and archive it. This way retrieving the scripts is as simple as restoring that version of the database somewhere, and extracting manually.
An even better approach: if you store your change scripts in source control, you should always be able to pull any version of the database.
I've used both SMO's predecessor (SQL-DMO) from VB as well as ApexSQLScript from the command line to do scheduled scripting of objects.
This is fine for very large databases where you do not have ability to quickly restore a database just to look at schema versioning information for small tables/views/procs which happen to live in the same database.
In fact, this is a good argument for separating out small fast-changing schemas into separate databases from large-slowly changing schemas.
I'm trying to find out if this is possible, but so far I haven't found out any good solutions. What I would like to achieve is write a stored procedure that can clone a database but without the stored data. That means all tables, views, constraints, keys and indexes should be included but without any data. Can it be done?
Sure - your stored proc would have to read the system catalog views to find out what objects are in the database, determine their potential dependencies, and then create a single or a collection of SQL scripts which re-create the database, and execute those.
It's possible - not very nice and easy to do. Especially the dependencies between objects might cause more headaches than first meets the eye....
You could also:
use something like SQL Server Management Studio (if you're on SQL Server - you didn't specify) and create the scripts manually, and just re-execute them on a separate server
use a "diff" tool like Redgate SQL Compare to compare two servers and have the second one brought up to date
I've successfully used the Microsoft SQL Server Database Publishing Wizard for this purpose. It's pretty straightforward, no coding needed. Here's a sample call:
sqlpubwiz script -d DatabaseName -S ServerName -schemaonly C:\Projects2\Junk\ DatabaseName.sql
I believe the default is to create both data and schema, but you can use the schemaonly parameter.
Download it here
In SQL Server you can roll through the system tables (sys.tables, sys.columns, etc.) and construct things one at a time. It's going to be very manual and error prone at the beginning, but it should become systematic pretty quickly.
Another way to do it is to write something in .Net using SMO. Check out this link:
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated