I have a MS SQL Server 2005. It is very easy to backup individual databases, just right click on database then Tasks->Backup. My question is how to back up SQL server database objects outside the databases?
For example, under the Security->Logins, there are list of login users; under the SQL Server Agent->Jobs, there are list of jobs, and under the Server Objects->Linked Servers; ans so on.
Is there any way to do full-backup of SQL server? in TSQL? I tried to find out from SQL Server Management Studio but I could not find any.
Those items are stored in the system databases -- mostly master and msdb (under databases | System Databases). You can either back those up individually (like you do other databases) or, better yet, create a Maintenance plan (Management | Maintenance Plans) to do so on a regular schedule.
I recommend using this script. I spent much time looking after maint plan failures before it.
http://blog.ola.hallengren.com/
http://msdn.microsoft.com/en-us/library/ms187048.aspx
has more info on the standard procedure.
If you're responsible for these databases, I recommend to practice restoring the system databases on a new server, so when the time comes you are confident. The restore is not as simple as rightclicking restore.
database logins are stored in the user database, server logins are stored in master. msdb stores sql jobs and history. the simplest full backup you can do in T-SQL is:
BACKUP DATABASE dbname
TO DISK='C:\backupfile.bak' WITH INIT
WITH INIT means that it will overwrite the file.
Restoring the master database requires restart sql server in single user mode. You do this from the command line in the sql server directory with: sqlservr.exe -c - m
then connecting with SSMS or sqlcmd and run a restore.
Related
I want to migrate my all databases from SQL Server 2012 to SQL Server 2014. Is there any way to do all in one short instead of one by one?
you can simply do in-place upgrade in the same server, instead of migration, if possible. It will one-shot operation.
You can do side by side migration, by taking backup in source environment(MSSQL 2012) and restore databases in target environment(MSSQL 2014).
This is a very important operation and many things have to be planned. You have to have migration plan for this.
You can use upgrade advisor tool for this. It will tell you whether everything is fine on your instance for initial analysis: https://msdn.microsoft.com/en-us/library/dn236457(v=sql.120).aspx
Also, read below articles.
https://thomaslarock.com/2014/06/upgrading-to-sql-server-2014-a-dozen-things-to-check/
https://blogs.technet.microsoft.com/meamcs/2013/12/14/what-to-consider-when-creating-sql-server-database-migration-plan/
There are lots of guides available online. Just search internet. you will find many guides.
You can do it in 2 ways:
1.Create a backup of your database and restore it in new server.From Management Studio you can Right-click on your database then select Tasks -> Back up.
2.Generate script, create the database in the new server and run the script.From Management Studio you can Right-click on your database then select Tasks -> Generate Scripts.
We currently have a SQL Server Standard 2014 database on one of our servers that is backed up daily to Azure Blob Storage. Those backups are working well and have restored beautifully to the original server in manual tests.
However, to ensure that our backups continue to be valid, I want to put in place some sort of automated restore testing. Due to performance/disk constraints, I'd rather not do this automated testing on our primary database server. But we can't spend the money to buy more SQL Server Standard licenses to set up another server. And we can't use SQL Server Express, because our database is too large (about 20 GB).
Given that our backups are stored in Azure, I thought the best way to test backup restoration would be to restore the backup directly into an Azure SQL database. I could do this roughly once per week, run some quick checks on the restored data, and then automatically delete the database, and pay for less than 1 hour of service/week. This would result in minimal expense. However, I'm not sure it's possible. Google searches for instructions on how to restore a SQL Server backup directly to Azure SQL haven't turned up anything so far. Is it possible for me to restore my SQL Server backups directly to Azure Managed SQL like this?
If it isn't possible, my next thought is that I could just create an SQL Server VM in Azure and activate/deactivate it as needed for my automated restore tests. That'd be a bit more complicated though, so I'm saving that approach for plan B.
Not Directly. You can only directly import a bacpac file into SQL Azure.
What you can do is use SQL Server on an Azure VM to test your backup files.
Pretty sure you can write a script to automatically pull down the latest .bak file and restore it to the SQL Server Instance on the VM.
I am looking for a way to backup a SQL Server database with T-SQL. I do no have root access to this server through the console, as my only access comes through SQL Server Management Studio.
Could someone please show me the SQL that I could use to export the raw SQL for my entire database?
BACKUP DATABASE #strDB TO DISK =#BackupFile WITH RETAINDAYS = 10, NAME = N'MyDataBase_DATA-Full Database Backup', STATS = 10
You must define #BackupFile and #strDB as the database name.
All of this is free in Books Online which you can find online.
If you only have access to the server through Management Studio, where do you expect it to stream your backup? Getting the T-SQL to work is one thing - getting SQL Server to be able to write the backup to a place where you can access it is quite another. You may want to look at Red-Gate's SQL Azure Backup:
http://www.red-gate.com/products/dba/sql-azure-backup/
I am trying to copy a database with huge data from SQL Server 2005 to SQL Server 2008. I tried using the Copy Database Wizard but could not use the wizard because they are two different server 2005 and 2008. So I copied all the tables using Import data wizard from SQL Server 2008.
I had about 1120 stored procedures to be copied, so on SQL Server 2005 I used the Generate Script wizard and created script(for SP) which I could run on SQL Server 2008. I ran that script on SQL Server 2008, but only 1082 procedures were created, most of them didn't get created because of dependency issues. Now I am not sure out of 1120 SP's which were not created.
Can you suggest anything on how to fix this situation?
SQL Server 2008 can restore from a SQL Server 2005 backup file. Why don't you just do a quick backup and restore operation? If you don't want the whole thing, just backup and restore to a temporary SQL 2008 database and then copy the objects you need from there.
In order to find out which stored procedures are missing and need to be re-created, you should use a SQL diff tools, something like:
Red-Gate SQL Compare
ApexSQL SQL Diff
Those do cost a bit of money to license, but they're well worth their purchase price and can save you countless hours of work trying to figure out what needs to be done.
Both those tools can compare two databases (even different versions) against one another, and they can create either update scripts to make them have the same objects, or you can even do the synchronisation directly in those tools, if you wish to do so.
What kind of dependency issues?
Most of the time it will just complain about dependency issues, for example if you try to execute a SP from a SP that is not yet created. But it will still be created.
It might be logins or such?
Why dont you just make a backup and restore the database?
Would it not be simpler to just Detach the SQL 2005 DB, copy the .mdf and .ldf files for the DB to the SQL 2008 Data folder, and then Attach the DB?
Is it possible to restore a backup of a SQL Server 2005 database onto an instance of SQL Server 2008?
I need to rebuild a server as it's getting rather crufty, so I plan to take this opportunity to upgrade to SQL 2008 and wondered if I'll be able to restore my backups OK.
Upgrading from 2005 to 2008 is OK, moving back might require more work
N.B. You might have a problem with your database the logins (as they will not exist in the new server master db) but that's something which would happen regardless of the server version. Just re-create them and re-associate with your database.
Yes, but make sure that ALL of your servers are SQL 2008. If you have development, test, QA or disaster recovery servers, all of them will need to be 2008, since 2005 servers won't be able to restore a 2008 backup.
To prevent the lost-login problem that Ilya mentioned, follow the steps in this knowledge base article. SP_Help_Revlogin will script out your logins, and you can apply that script on the new server. Presto, all your logins are back with the same SIDs and everything.
http://support.microsoft.com/kb/246133
(And just for future reference, this is how we upgraded StackOverflow last night, heh.)
http://twitter.com/SuperDalgas/status/976719756
You can restore the 2005 backup with 2008 without any problems. The compatibility from this point of view is nice.
Backward is not possible only with backup files.
In any case you can also recreate the database structure and use SSIS to transfer data from one server to another.
You can also do a detach/attach with the database files (leastways you could going from 2000 to 2005), but there are more caveats with this approach (requires explicit rebuild indexes afterwards IRRC)