I'm at a site where they are upgrading a sql server (data warehouse) from 2005 to 2008. My understanding was always rebuild every index and update all your statistics after a restore from a previous version. Will it cause a big performance hit if they aren't rebuilt right away? Downtime is a concern so I'd have to schedule the rebuilds a bit at a time.
Thanks in advance.
SQL Server backups are an image of the database at the point in time the backup was performed. You do not need to rebuild indexes or update statistics, as the restored database's indexes will have the same fragmentation that they had when the backup was performed.
Related
Now that SSD is a standard de-facto. Can the maintenance job of rebuilding indexes and updating statistics, using Ola Hallengren https://ola.hallengren.com/ jobs for instance, be done only on demand instead of regularly such as on weekly basis with Microsoft SQL Server 2017 or lower?
If it is still required, what would be the threshold of the database size to decide when it is necessary ?
I have a couple of Databases which I need to deploy from Production Servers to Live Servers.
What I am doing is, before creating Backup, I rebuild the indexes and Update Statistics, then make backup and send it to Live.
Is that a good practice, can some one advice me in this regard
Thanks
Rebuilding indexes and update statistics, then shrinking make the database server busy, which may respond to your users as database server busy, or slow down their queries. Space is not an issue now a days so increase your database server drives.
Thanks
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.
I am using SQL Server 2008 Enterprise version. I want to know if I do not explicitly set any maintenance jobs, are there any default maintenance jobs SQL Server will perform (like backup? rebuild index? truncate transaction log?)? Where to find the current maintenance jobs?
thanks in advance,
George
No. Out of the box SQL Server will not backup automatically nor will it do any maintenance for you. As far as truncating the transaction log goes, you can do that automatically by setting the database mode to SIMPLE, but in a production environment, you do NOT want to do this, because it breaks your transasction log backup chain. In a production environment, you will need to set up a plan to back up your transaction logs and your databases, and to do index maintenance.
In SSMS, in the Object Explorer, there's a Maintenance folder. There's a "Maintenance Plans" folder under there.
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.