I want to backup my database with compression.
This is my code, which runs correctly in SQL Server 2008:
BACKUP DATABASE dbbbb
TO DISK = N'C:\\dbbb.bak'
WITH COMPRESSION;
My server has SQL Server 2005 and COMPRESSION is not a recognized BACKUP option in 2005.
How can I compress my backups in SQL Server 2005?
You compress the generated file. Backup compression was added in 2008, so - sorry, out of luck.
Following on from TomTom, if you're in the situation with not enough disk space for your backup then you can attach an external USB drive or compress the target folder using NTFS
If you are stuck on 2005 and really would benefit, check out Red Gate (www.red-gate.com) SQL Backup Pro. It is a bit pricey but is a great backup tool with compression support for 2005 databases. I have used it in various rolls for years even on SQL 2008 and beyond. Great tool if you can justify the cost.
Note: For me, compression did hit the 90% range consistently.
Related
I have a very large sql backup file (~ 22 gb). Does anyone know how can I read it from R?
(Assuming you are using SQL Server here. But if it is a backup of another database, the same option is probably available).
The best solution is probably:
Restore the backup file into a (new) Database. This is pretty simple to do: this question covers it (for SQL Server 2008). You can also get the free SQL Server Express if you don't own a version of SQL Server.
Connect to the database using RODBC. There is a quick start example here.
Note: there are some proprietary tools that read SQL server backup files directly (also mentioned in the first link above). But if you want to work with the data in R, being able to access it through the standard RODBC interface will be much more convenient.
A database that was originally from SQL Server 2008, was restored into SQL Server 2012. A backup from SQL Server 2012 was made and I am trying to restore it on my local SQL Server 2008 Express. However I get an error 'Specified cast is not valid' (SQLManagerUI).
I have generated an SQL Script from 2012 and set it so that it will generate with compatibility to SQL Server 2008. However it is a large sql file, around 700mb.
I recall before that I had tried to run a script of that size before on my local SQLExpress and also got an error.
Is there a way I can get a "large" database from SQL Server 2012 into SQL Server 2008 Express?
Thanks to Marc and Aaron for providing the answers.
The quick answer is no, it's not possible to restore a backup file from a higher version to a lower version of SQL Server.
A work around would be to generate the scripts to create the database.
You can target the script generation to a lower version.
Please see comments above for more information.
Links:
Why an SQL Server Database from a higher version cannot be restored onto a lower version of SQL Server?
Create Database in SQL Server 2012, Script and Use in 2008?
Couple things to add that might be helpful to folks
When scripting large databases using scripting wizard in SSMS it’s really important to check the execution order and be willing to re arrange it manually. Older versions of SSMS had this problem because they (probably) relied on sp_depends that has a bug.
What I’ve found really useful in such cases are tools like ApexSQL Diff that you can use to read database backups and generate scripts that are in correct execution order.
SQL Server database backup restore on lower version
One thing that none of the methods will catch is the thing Aaron mentioned about using functions specific to higher version.
A better option than using the SSMS scripting wizard is to use a similar tool available on Codeplex called SQL Database Migration Wizard - http://sqlazuremw.codeplex.com/releases/view/32334. You want the latest version v4.x to work with SQL Server 2012.
The tool is originally intended to be used for migrating databases between SQL Server and Azure. However the tool works just as well as between SQL Server and SQL Server. The trick is to set SQL Server rather than Azure as the target in the advanced options.
The reason this is a better option than the SSMS scripting wizard is that it uses BCP for the data transfer rather than TSQL and so is much more efficient.
I want to copy all my database to remote database server. I have access to server using SQL server management studio.
How can I do this? I have created script with data of old database and tried to run it on new server but it is taking too much time and returns different errors like duplicate key etc.
If this is a one time deal, you should download Redgate's SQL tools. They can handle this easily and are free to test for 14 days I believe. (http://www.red-gate.com) You might even find they are worth the purchase as I have. The tools you would use are SQL Compare (to copy structure) and SQL DAta Compare to actually copy the data.
Assuming that you can restore databases to your remote SQL server, you can use SQL Server backup and restore? They're available in SQL Server Management Studio. See http://msdn.microsoft.com/en-us/library/ms187510.aspx. It's very easy to use.
Other than that, you can try copying the database MDF and LDF files from your local database onto your remote database filesystem, then attaching to the MDF file on your remote database.
Those are probably the fastest ways that you can copy and entire database to a remote location that I can think of.
Try Database publishing wizard by Microsoft. Good enough for no very big data amounts.
We have a Sql Server 2005 Standard Edition running on a Production website. We'd like to move to a cloud hosting but they only offer Sql Server Express Edition on there.
My question is, will there be any problems in moving over? We only use tables, views, stored procedures and a few user defined functions. And we also have a Backup Maintenance Plan in place. Will any if this change?
WHat other limitations/problems (if any) can we expect to have? And is it a good idea to run on Express in Production?
And I would like to add, will it be OK if we moved from SQL server 2005 Standard to Sql Server 2008 Express - what possible problems there could be with this move?
There are limitations for SQL Server 2005 Express as listed here
These include:
- max 1GB RAM only
- max DB size of 4GB
- 1 CPU
Theses restrictions may cause you a problem. See the full list in the link.
With regrd to moving from 2005 Standard, to 2008 Express, then I expect the limitations of Express Edition may be the main factor when you consider if it really is an option. The limitations for 2008 Express are similar, see here.
Hope this helps
The migration im unsure.
Express does not support triggers (fully), nor SQL scheudling.
Its size is limited to 4GB.
You can only ever have one instance with express.
It does however support Full Text and Reporting Services (in the express advanced edition)
We have plenty of clients running SQL Express due to cost. Only small pain has been the need to write a windows service for a job that could be easily run in proper SQL scheduling in the paid for the version.
Im sure there are many more differences but these are the ones im aware of, hope this helps.
I've used SQL Server Express for simple data persistence in production with no issues.
From the looks of your situation the only feature that will not be supported is backup maintenance. However, if you're hosted on a cloud, your ISP should take care of backup for you.
The title pretty much says it all, but in SQL Server 2005 Management Studio, if I look at the database properties and pick up the size value, will that include the full-text index data?
Does it include the log file as well?
Rough values are fine, but some of our ft indexes can be large, so I want to be sure of this.
No, in SQL Server 2005, the fulltext indices are external to SQL Server in the server's file system. I don't think those are included in the database size when you look at them in SQL Server Management Studio.
This is totally changed in SQL Server 2008 where the fulltext system has been fully integrated into the database core.
Fulltext indexing in 2005 is saved on hard drive separated from .ldf and .mdf files, while file size limit you talking about is about database files themselves.