We recently moved from a simple DB recovery model (with daily full database dumps) on our SQL Server 2000 Standard database to full recovery -- combined with weekly full database backups, daily incremental, and transaction dumps every 10 minutes.
Our previous reporting DB instance (SQL Server 2005) was built from the daily backups which no longer exist. I can re-build the reporting database by loading the weekly dump, leaving it in recovery mode, and then restore the incremental backups. Unfortunately, this is not easily scriptable and doing this by hand sucks.
Taking additional full backups of the 2000 production database will ruin the incrementals (which are desirable for a number of reasons).
Is there a better way to do this? We can't do log shipping since we're only SQL Server 2000 Standard (eventually we'll upgrade to 2K5).
Depending on how up-to-date your data needs to be, snapshot replication seems like the best fit for you. It's not that difficult to set up and I believe that it's fairly common in scenarios like yours.
Related
I have an Azure VM - Windows (Windows Server 2008 R2 Datacenter). It has Microsoft SQL Server 2008 R2 running on it (version v10.50.6549).
The Azure VM has backups running according to a policy - and I can see in the backups blade for the VM that they are running nightly.
If I have an issue with the SQL Server, and need to roll back to a prior version of the database, will the File Recovery option from the VM backup be adequate?
Or should I also be running SQL Server backups via a maintenance plan on the server on the VM?
If I have an issue with the SQL Server, and need to roll back to a
prior version of the database, will the File Recovery option from the
VM backup be adequate?
Maybe. VM Backups don't always give you consistent SQL backups. They usually work, but not always. If you have everything setup just right and get consistent VM backups, it might be ok-- but you are running a fairly old OS on that VM, so I'd be nervous. Very nervous. If the data is really important to you, then you should backup the data, not just the VM. Sometimes you want to restore just the data to another VM to investigate, not the entire server. I also hope you have more than just "last night's VM backup" at any given time. Sometimes bad things happen on Friday and you don't notice until Monday.
Or should I also be running SQL backups via a maintenance plan on the
server on the VM?
Yes, you should be running SQL backups if you your data is important. If your data is really important (you don't want to lose half a day of it), you should be doing full backups periodically (e.g. nightly) transaction log backups many times per hour, and keeping a few weeks worth of backups in rotation. If your data is super-important (you don't want to lose more than a few seconds), you should be mirroring it over to another database server in near-time (asynchronously). If it is critical (you don't want to lose any data), then you want to mirror to another server in real-time (synchronously).
Of course, if you are already running in Azure and don't have a DBA, managing a database is a lot easier, safer, more available, and generally cheaper if you use Azure SQL rather than trying to manage your own instance SQL Server in a VM-- oh yeah, and backups are handled for you, with millisecond point-in-time recovery for up to 45 days-- and they handle the mirroring for you to. If you want to mirror to another region across the country, you do have to pay extra for that, though.
We have developed and delivered a database-driven application about 1 and half a year ago. During this time, they have backed up database, re-installed software and restored database for a few times. Also they have sent us their database afew times to perform some update to the db structure. They have used the built-in backup and restore capability of the software. The software is using SMO (SQl Server Management Object) to perform backup/restore operations.
They now claim that some of their data has been lost during recent backup and restores.
Is such a claim possible or is just their data entry fault?
I have checked their db manually and data they have been added was not there.
Was there any report on SMO bug?
Backup and restore are critical facilities in SQL Server. They always, always, always backup the database consistently (point-in-time). You cannot backup or restore in a way that looses a part of the data or introduces other inconsistencies. SQL Server always prevents you from doing that with an error message.
(The myth that data loss might be possible comes from other RDBMSs like MySQL where backups were a challenge a few years ago).
The problem is elsewhere: In the DML executed on the database.
I have been looking into this project for a side-by-side upgrade solution. The most widely suggested/used solution is to do a full back of SQL Server 2000 database and restore on SQL Server 2008 with norecovery. Then restore the subsequent transaction log backups with norecovery. When we are ready to switch, change SQL Server 2000 to read-only mode, backup the tail-log and restore it on SQL Server 2008 with recovery. Then bring SQL Server 2008 online.
But, can't the upgrade be done with transactional replication where SQL Server 2000 is the publisher and SQL Server 2008 is the subscriber. Script all objects such as logins, indexes, etc and apply to SQL Server 2008. When we are ready to switch, we will stop replication, delete all replication jobs, and switch all apps to connect to SQL Server 2008. I haven't found anyone that suggests this method. Is there anything wrong with it?
The method of data migration you describe is possible to perform using SQL Server Replication.
There is nothing wrong with this method or any other data migration method for that matter, so long as the choice you decide upon addresses the specific requirements of your project/application platform.
That said the method you describe is certainly more technically involved in both the configuration and implementation of the actual migration steps. If you can accept downtime, a simple backup and restore process is certainly going to be much more straight forward. Log shipping would also be another simpler migration method.
So far, you know that the replication method could work in theory. Now is the time to build out a working solution in test in order to validate your data migration strategy and to practice the implementation process.
If you aren't replicating otherwise, creating a replication subscription will change your schema and a few settings.
For example, you may end up with GUIDs generated for all your rows just to facilitate the replication.
Caution - transactional replication will turn off all IDENTITY columns at the subscriber (the transactional replication SPs actually depend on this fact, as they insert into the IDENTITY columns without first specifying IDENTITY_INSERT ON). I can only confirm this is the case when the subscriber is SQL 2000 as well - perhaps the subscriber on 2008 will behave differently.
For this reason, transactional replication with SQL 2K doesn't really give you a hot standby. We had to do a fair bit of SQL tweaking (re-instating the IDENTITY columns & re-writing the replication SPs with IDENTITY_INSERT wrappers) to get ourselves a situation where the subscriber actually works as a hot standby, ready to have applications pointed at it. But it certainly wouldn't work out of the box =)
Yes, it will work, provided that you transfer the other objects over.
We're in the middle of migrating from a windows & SQL 2000 box to a Virtualised Win & SQL 2k8 box
The VMWare box is on a different site, with better hardware, connectivity etc...
The old(current) physical machine is still in constant use -
I've taken a backup of the DB on this machine, which is 21GB
Transfering this to our virtual machine took around 7+ hours - which isn't ideal when we do the "actual" switchover.
My question is -
How should I handle the migration better?
Could i set up our current machine to do log shipping to the VM machine to keep up to date? then, schedule down time out of hours to do the switch over?
Is there a better way?
You take a full backup of the database on sql2k, then restore it with norecovery on sql2k8, then continuously take log backups from sql2k and apply them to sql2k8 (again, with norecovery). So basically you do log shipping from sql2k to sql2k8. When you swithc operation, you onyl take tail of the log backup from sql2k and apply it on sql2k8, this time with recovery, which will bring the database online and run the upgrade from the sql2k format to the sql2k8 format.
SQL 2000 backup restored on SQL 2008 is supported, but you better have SQL 2000 SP4 deployed.
I need some help for executing my planned backup strategy.
My database is about 1 gig in size.
I want to perform a full backup once per week, and incremental every hour.
Is all of this built into SQL Server 2005 Express?
Is it possible to roll over the backups so I only keep 1 months of backups?
Meaning the full weekly backup has 1 for each week, on the 5th week it writes over the oldest full backup.
You can do it, it's just harder.
You don't have maintenence plans, but that doesn't matter becuase they often cause more headaches than they solve. You will want to script the backup yourself.
The other issue is you won't have the SQL Server Agent, which is used for scheduling your scripts. You can solve this by using sqlcmd and the windows scheduler.
SQL Server express does not have the ability to setup maintenance plans, therefore you must manually execute the scripts. AFAIK.
With all other editions, a simple DB Maint. plan can be setup to do all of this, and it will even walk you through the process.