We are in a process of migrating our SQL Server 2005 to the 2012 version.
There's a significant number of SSIS (developedn in VS 2005) running on this server.
Will it be ok to just re-deploy these packages on the new SQL instance?
Or will I have to go through the Visual Studio upgrade process for each?
Any comments, advice appreciated.
Thanks in advance.
You're looking at the upgrade, for a variety of reasons.
In 2005, packages would have been stored in msdb.dbo.sysdtspackages90 From 2008 forward, that table was renamed to msdb.dbo.sysssispackages
Even if you deploy them into sysssispackages and kept a 2005 Integration Services Service installed, I don't think the 2005 dtexec would work with the 2008 version of the stored procs in msdb relative to SSIS work. The procs should be backwards compatible for the msdb SSIS "stuff" in 2012 as they poured all of their attention into the 2012 SSISDB catalog and the CLR methods there.
Depending on your Connection Managers, the SQL Server OLE DB connection strings changed from SQLNCLI01 to SQLNCLI1.0 (approximate)
The internals of how Data Flows works has also changed. The mechanism for signaling the end of rows changed between 2005 and 2008 so if you have any custom components, those will have to be reworked.
When you convert from 2005 to 2012, you can migrate to a Project Deployment model or the Package Deployment Model. As it seems you are looking for a minimum of change, stick with Package Deployment Model. The project deployment model will entail forgoing your Configurations in lieu of the fancy new Parameter methodology.
Related
Since we need to move around our database a lot (like update it with new Rows which are generated by code and then update it prod db and reverse process). SQL Server CE, being a file based system was very helpful.
We would like to upgrade to use SQL Server Local Db but at the same time, it has limitations of use with IIS (though possible with AttacheDbFile). In this regard, since LocalDb is more or less a version of SQL Server Express, would it be possible to use our SQL Server LocalDB .mdf in our development environment and then copy them in prod but use by attaching to a SQL Server Express instance?
If yes, what additional thing, we need to do make it possible?
Also, we would like the reverse process to be worked out as well, mean detach the .mdf file and use it as LocalDb in development environment. I have read the great blog articles of
Krzysztof Kozielczyk also but not have experimented much with LocalDb.
LocalDB IS SQL Server Express (introduced with SQL Server 2012 Express), and the .mdf file is identical between LocalDB and SQL Server Express (and even a "full" SQL Server edition like Web, Standard or Enterprise Edition).
The only caveat is: you need to be using the same versions of those databases, since the file format is only identical amongst same versions, and can only be used amongst the same versions (e.g. 2012) - or it can be "upgraded" to the next newer version (e.g. you could move a database from LocalDB 2012 to a SQL Server 2014 Express once it's released) - but you can never go back down to an earlier version (you cannot take a LocalDB 2012 .mdf database file and attach it to a SQL Server 2008 version).
My team needs to update an automated content process running over SQL Server 2008 servers to include the content of a SQL Server 2008 R2 database delivered by a third-party vendor.
The request to third-party to deliver us on SQL Server 2008 is NOT an option.
My common sense indicates there is no way to downgrade from 2k8 R2 to 2k8 as in most of the software products I know. However, I'm wondering if I would be able to do something like this in a script:
Restore SQL Server 2008 R2 .bak file onto our SQL Server 2008 R2 instance
Update compatiblity level to SQL Server 2008 (100). Here is the bug in my plan: I've not found any compatiblity level distinctions between 2008 versions in internet. Any clue on this?
Backup the database.
Restore the database in SQL Server 2008
There may be some other ideas you may want to share with me.
Just recall there should not be manual intervention on this database conversion since this operation needs to be incorporated to an automated process.
Any help/suggestions/comments will be welcome!
No, you cannot restore a database backwards, regardless of compatibility level. Compatibility level affects certain database engine behaviors, but does not downgrade the database version. You will never be able to restore onto 2008 a database that ever existed in a 2008 R2 instance.
For workarounds, you can:
restore the database on R2, then use the import/export data wizard (or a third party tool) to transfer schema / data to the 2008 instance (and you should be able to automate this to some extent, e.g. Red-Gate's tools have command-line interfaces)
upgrade your 2008 servers to 2008 R2 or 2012
push back on the vendor
By design, you can only restore a DB backup to the same or newer version of SQL Server. A backup created with SQL Server 2008 R2 can only be restored with SQL Server 2008 R2 or SQL Server 2012. This is regardless of the compatibility level of the database. It's a limitation of the backup and restore procedures. This has been a limitation since prior to SQL Server 2000 (i.e., every version I've ever used).
Maybe you can script out the creation of new database, instead of backing up and restoring you basically just do a data dump with script.
Try looking at this How can I get a SQL dump of a SQL Server 2008 database?
we have a local staging server running sql server 2000 and a remote public version also running sql server 2000. The remote version will be upgraded to 2005 and I am wondering if the DTS packages we have in place will continue to function between the two machines?
If not, what would be the simplest, most efficient way to sync between the two?
We will not be upgrading the local server, and the upgrade of the remote one will be taking place very soon (not in our control).
Thank you!
If your DTS packages reside on the local server, there shouldn't be an issue (aside from obvious changes to SQL itself (I.E. the old-school joins not working anymore)), and in fact, I've even seen developers save DTS packages on SQL 2005 databases though I'm sure it's not a very good idea.
EDIT: It might also be worthwhile to check out this link for the tools to design/modify DTS packages with SQL Server Management Studio.
Is there any way to import a database backup from 2005 into 2008 express edition. What I've had to resort to is doing a script the database, then import all the data through DTS. Whenever I tried to import straight from a backup file it says something about not being to import into a new version of sql server or I'll get the below error.
title: Microsoft SQL Server Management Studio
Specified cast is not valid. (SqlManagerUI)
SQL 2005 backups should be restored on 2008 without problem (have done that myself many times). What exact error message did you got about versions?
The other error (Specified cast is not valid) seems to be Management Studio error, not server error. Have you full rights on 2008 server?
Look at this question - any-reason-to-have-sql-server-2005-and-2008-installed-on-same-machine - there are talked both about restoring SQL2005 backups and about attaching SQL2005 data files.
(Of course you cannot attach production databases. To attach non-production databases just detach them, make file level copy of these and attach copies to new server. Orginal files need to attach to original server too :))
I imagine that you are in a development process where your data will have to be regularly copied to you SQL 2008 server.
You can then think of configuring a replication between the SQL 2005 server (publisher) and SQL Server Express 2008 (suscriber). Depending on your requirements, you have the choice between snapshot or merge replication. If no update is done on the suscriber side, go for snapshot.
Once you want to have your 2008 server running independantely from the publisher, just delete the replication.
A valid SQL Server 2005 Express backup file should be able to be restored to SQL Server 2008 Express. If the SQL Server 2005 backup is from the Standard or Enterprise versions, you might hit problems restoring it to Express. The user context that the backup was created from should not affect the ability to restore that backup.
One thing you can do is to try running the restore operation as a verification, without actually trying to run the restore. That will tell you if the backup file is valid or not. You can use this syntax:
RESTORE VERIFYONLY
FROM yourbackupfile.bak
If possible, I would also suggest trying to simply detach the original database from 2005 and then attaching the file at the 2008 edition.
While I have only tried this with the standard edition myself, it has worked perfectly with the compatibility mode keeping the database set to 2005.
Have you tried running the Upgrade Advisor http://www.microsoft.com/download/en/details.aspx?id=11455 - it might be able to highlight problems for upgrading the original database.
I'm setting up a new development server and want to install the latest version of SQL Server 2008 Express.
Will our existing sql2005 databases work with 2008 without modification?
If so is there any reason to install both versions on the same server?
I haven't actually tried migrating a 2005 database to 2008, but generally SQL handles this cleanly and without difficulty. The simplest way to do it would be to make a backup of your database from SQL 2005 and then restore that backup with SQL 2008.
If you want to keep the SQL 2005 copy around and online until you know that the 2008 copy is working, you might need to move the data/log files for your database when restoring the backup onto 2008, since the old data files will be in use by 2005. You can do this using the with move option of restore database, for example:
RESTORE DATABASE mydb FROM disk = 'c:\backupfile.bak'
WITH MOVE 'maindatafile' to 'c:\newdatalocation.mdf',
MOVE 'mainlogfile' to 'c:\newloglocation.ldf'
As to having both installed at the same time, one reason you might decide to do this would be to simplify the job of testing code against both versions, if you were intending to have your software support talking to both versions.
You can detatch a 2005 database and attach it to a 2008 server. I would recommend against installing both on the same machine unless you must (e.g. you're writing code for a third party and they only use 2005).
What I'd highly recommend is using windows server 2008 hyper-v to create 2 virtual machines one with the 2005 environment, the other with 2008. Hyper-v virtual machines are incredibly faster than Virtual server 2007.
The databases should (should!) work unmodified. However, for development it is preferable that you have sql2005 to test your scripts unless you assume all your clients would upgrade to 2008 as well, since 2008 has features that do not exist in SQL Server 2005.
In dev and test environments, having multiple database servers installed is not a problem and can reduce the number of test servers required.
In production, I wouldn't recommend it due to the fact that multiple buffer pools fight and kill your performance.
To me the important thing is will you have prod instances that are 2005 databases? Will you have to support reporting services reports that are on a prod server that only has the 2005 version of reporting servives, etc?
If so, you should have both the 2005 and the 2008 versions on your development machines. I've seen a lot of code that had to be thrown out because developers worked on 2008 when prod was 2005. ALways develop against the version of the software you will have in prod. If you are converting to 2008 but not there in prod yet, you need both, one for maintenance changes and one for future stuff.
Personally I have SQL server 2000, 2005 and 2008 on my machine because we haven't converted everything yet and I have some things which can only be done on the older version. We have found the key to maintaining multiple versions is to install them i nthe correct order. It seems to go badly if you put 2008 on first and then the older versions.
Sometimes you need to be able to test on multiple versions, or you may need 2005 for one thing and 2008 for another.
Sometimes you maintain several different apps, some of which are on one and some on the other, and you haven't updated everything yet. Sometimes you're upgrading, and need to test on both versions during the upgrade. Sometimes you support several different customers, some on one version and some on another. Sometimes you want to upgrade your internal apps, but you're using a software package that is only certified on an older version.
There's lots of reasons.