My boss tasked me with doing research on migrating sql server 2005 to 2014.
my first question is, is it really as easy as restoring into an old backup?
No thing needs to be changed in terms of processes that load to the databases or components that look at the databases?
I'm completely new to this, obviously. I use SQL server management studio almost every day, yet I am still not familiar with anything else besides running a few simple queries.
I've looked at this site here that finds all permissions/access for all users in a database. I've also run sp_who2 and:
SELECT *
FROM
Master..sysprocesses
order by spid
just to get an idea of all the processes going on. How would I see the websites that are pulling from the databases? I know we have a DB loader, how can I see that process?
I can't quite get a grasp of the scope of this project.
It can be as simple as backup and restore or an in-place upgrade, but there are subtle changes with each new edition that mean there's no way to be sure that it will be without thorough testing. There's hundreds of things that may catch you up caused by 10 years and 4 different revisions. Some might be as simple needing to fix SQL Users and SQL Login mapping, to changes to the SQL client causing incompatibility, to functions or methods that simply no longer work or work differently. It's impossible to tell without knowing your data and your database. The first step should be getting the documentation from your application vendor, assuming it's an application with support.
I strongly recommend that you start reading the MSDN doc on installing and upgrading SQL Server 2014, and you may need to read the 2008, 2008 R2, and 2012 doc as well to look for changes that might impact you. I'd strongly recommend setting up a testing environment to make sure that your application will even work.
Bottom line is that you should not assume that it will work without thorough investigation, planning, and testing.
Related
I am a developer and performance tester but not a DBA. My team is working on a performance testing tool that is specific to our software. One of the features we want it to have is the ability to generate a database report immediately after the test. Our software is database agnostic. For Oracle, I can easily create a snapshot id before and after the test and programmatically create an AWR report for those snapshots, write to a file and save with other artifacts we gather. Works great.
For SQL Server, however, there is no AWR equivalent (that I know of). I know the MDW as part of the SSMS has a UI for getting things like top 10 slow SQL and things like that. But, I have not yet found a way to programmatically create and extract a SQL performance report (preferably similar to Oracle's AWR) for SQL Server.
I am even willing to create the report myself if I can find a way to extract the raw data.
Any ideas would be greatly appreciated because searching online is not getting me anywhere.
P.S. I'm trying to do this in Java, by the way, but will accept help in any language. Thanks again!
Good news! In SQL Server 2016, you can use Query Store. This is like your flight recorder blackbox.. finding long running queries and waits. Capture baseline built in to SQL Server. You can compare before and after hardware changes and/or upgrades on queries. Maybe this similar to Oracle AWR.
Only available SQL Server 2016 and up.
Hello,
I'm new here, so sorry, if my question is too basic. However, maybe you have some advice, example, links, which could help me... I'm trying to find something helpfull for few days, but no results as for now.
I'm working in a distributed environment. I have a Oracle server hundreds of miles away and a MS SQL server close to me. I'm writing a application using Visual Web Developer 2008 Express. I need some data from Oracle. It's not worth to query the Oracle server every time i need some data from it. I'd prefer to run some Oracle queries once each night and store results in some local (SQL Server) tables. I assume, I should run queries through standard windows scheduler (Windows Server 2008). I have the basic connectivity - I can open Oracle Database from local Visual Studio.
The questions are:
How to write a query/procedure/function that would get data from Oracle and put them into a SQL Server table (possibly recreated before each query run)?
How can I run such a query from command line (or in other way run from scheduler)
What naming conventions are applicable? In VS I use something like //IP.IP.IP.IP/Name and a user with password.
Thanks for any help or advice.
Regards,
Matteo
I suggest you speak to the DBA's of the Oracle and SQL Server databases, as there may be other considerations you need to bear in mind. (Data Integrity, Security, ownership etc.)
One route you could follow would be to implement DTS (For older databases) or SSIS (for new versions of SQL Server) processes to copy the data across on the schedule you want. (This is pretty much what they were built for.)
How much data are we talking about?
If there is a small quantity that you need to transfer every day, you can write a stupid fetch and insert script in language of your choice.
You only need to search for better solutions if "sync" would take too much resources.
Thanks...
I'm the DBA for the SQL Server, which will serve only for my application. For Oracle I just want to read data and I have enough privileges and agreement with DBA's. Security, ownership and integrity are not an issue for now. I just need some technical advise how to get data from Oracle to MSSQL tables on a schedule.
I use MS SQL Server 2008 Express SP1. I'm very close to solve my problem - I have established connections and everything installed and working. I just don't know, how to run a query, which would get data from Oracle and put into MSSQL, on regular basis, without manual interaction.
I've some experience in programming, but not much in databases (except creating complex SQl queries). Therefore some example or links to detailed description would be helpful. I'm not sure about naming conventions, differences between procedures, functions and queries, command line options to run db automation procedures and so on. I'm also not sure, about which mechanisms or technologies are available in MS SQL Server 2008 Express edition.
I m using Access 97 database.It has lots of forms. Data bulked. I have to upgrade it quickly. I bought SQL Server 2005 enterprise edition.
I want to use SQL Server for data holder. I m going to use Access forms regularly. I just want to export data to the sql server.
Is it possible to use "Linked" data storing?
While I agree with HLGEMs first paragraph I respectfully disagree with HLGEMs second paragraph. There are quirks you need to know about of which I'm somewhat ignorant. Such as changing boolean fields to LittleInt. But otherwise it's a lot of tedious work to recreate the database schema. And it'll be error prone such as missing indexes or relationships.
There is a tool from the SQL Server group which is a lot better than the Upsizing Wizard especially the Access 97 version.
SQL Server Migration Assistant for Access (SSMA Access)
http://www.microsoft.com/sql/solutions/migration/access/default.mspx
As you discover these quirks you can change the scripts to recreate the database with the appropriate changes.
I concur with Tony Toews (and you should trust him on this, he's an Access guru): use SSMA to help you move data to SQL Server, it does a more complete job than the upsizing Wizard integrated in Access (which doesn't work for upsizing to SQL Server 2008 anyway).
You have to be wary of a few caveat though; I've made a blog post about some of the things you should check out.
The point is that if the original Access database was designed without relying too much on the liberties that Access allows (strange characters in table and column names for instance), then the process will be much easier.
Pay special attention to all the warning and errors reported by SSMA, they are really useful in helping you focus on the issues you must solve.
With regards to performance, moving to SQL Server isn't necessarily going to make things faster.
In some areas it will actually be slower, sometimes much much slower:
Access is pretty good at optimizing certain forms of data access but once the database moves outside of its reach, it doesn't have as much control.
Most things will work fine though.
You will probably have to rewrite a few queries, maybe move them as views on SQL Server instead of keeping them in your Access application.
Little things such as using % instead of * as wildchars in queries using LIKE in their WHERE clause can also cause strange issues like queries not returning any records.
By the way, I'll post a very good resource Tony has on his own website regarding SQL upsizing: My random thoughts on SQL Server Upsizing from Microsoft Access.
There is also a good and detailed read about things to consider when using SQL Server from Access: Optimizing Microsoft Office Access Applications Linked to SQL Server
YOu can add the SQL Server tables to access as linked tables. Then you will want to start looking at your slowest queries and convert them to stored procs.
Do not use the upgrade wizard in Access to create the SQl Server tables becasue it will make poor choices for datatypes. Do the work yourself to create the scripts, choosing the best datatypes. It takes longer this way, but your database will perform better and you will gain a better understanding of how to do things in SQL Server. You should start right now, learning to do everything through a script and never from the GUI. Best to learn good habits in SQL Server from the start.
I've been searching for some time for a good solution to implement the idea of managing schema on an SQL Server Compact 3.5 database.
I know of several ways of managing schema on SQL Server Express, SQL Server Standard, SQL Server Enterprise, but the Compact Edition doesn't support the necessary tools required to use the same methodology.
Any suggestions/tips?
I should expand this to say that it is for 100+ clients with wrapperware software. As the system changes, I need to publish update scripts alongside the new binaries to the client. I was looking for a decent method by which to publish this without having to just hand the client a script file and say "Run this in SSMSE". Most clients are not capable of doing such a beast.
A buddy of mine disclosed a partial script on how to handle the SQL Server piece of my task, but never worked on Compact Edition. It looks like I'll be on my own for this.
What I think that I've decided to do, and it's going to need a "geek week" to accomplish, is to write some sort of a tool much like how WiX and NAnt works, so that I can just write an overzealous XML document to handle the work.
If I think that it is worthwhile, I'll publish it on CodePlex and/or The Code Project because I've used both sites a bit to gain better understanding of concepts for jobs I've done in the past, and I think it is probably worthwhile to give back a little.
Edit on 5/3/2010:
If someone is willing to "name" the project, I'll upload the dirty/nasty version that I've written for MS SQL to CodePlex so that maybe we can start hacking out a version of SQL Compact. Although, I think with the next revision of the initial application that I was planning, I'm going to be abandoning SQL Compact and just use XML Files for storage, as the software is being converted from an Installable package to being a Silverlight application. Silverlight just gives a better access strategy.
I am currently looking into Migrator.Net.
This allows you to write changes to your database, called migrations, directly in C#.
These migrations can contain everything from simple table additions/drops, column modifications, to complicated data update code.
When your application boots, it can verify what version the database is currently in and apply any migrations that are required to bring it up to date. All this is handled automatically. The code to run this update is as simple as:
Assembly asm = Assembly.Load("LocalModels.migration");
Migrator m = new Migrator("SqlServerCe", "Data Source=LocalModels.sdf", asm, false);
m.MigrateToLastVersion();
I am having a couple minor issues with the Compact support (it assumes the default schema is dbo). But I don't think it will be too difficult to fix them.
some random thoughts (not sure I can fully answer though)
the Microsoft Sync Framework is one option. I haven't had a chance to fully appreciate what it can do once you've deployed it after the initial first time (which seems to work fine). There's a MSDN site for it here
You can execute scripts on a mobile device, but not through something like SQL Management Studio, so in theory you could manage/maintain T-SQL scripts but the down side is that the T-SQL would be convoluted (to CE's supported statements) and I don't know a way to "automate" execution - but the Sync Framework might hold some answers..
If one of your key criteria is going to be working efficiently over a small pipe, the only real choice you have is to store a DB Schema Version (maybe somehow tied to the scripts checked into your CMS) and when an update is needed, the change scripts are sent over the wire and applied in order. You would probably want to keep a log in your DB as well of these scripts being applied so you can gracefully handle disconnects, reboots and other potentially nasty problems.
Is SQL Server Management Studio any use for you?
http://technet.microsoft.com/en-us/library/ms172933.aspx
I'm starting a new project and I'm considering using sqlserver 2008.
I've had a lot of trouble getting teamsystem to work with it, and I'm wondering if sql server 2008 is widely used in productions environment yet.
What whould you choose? How do you compare sqlserver 2005 and 2008?
EDIT : I agree about the obvious and general tradeoff between new (new features, one painfull migration avoided in the future) and old (less bugs, more documentation). I've already browse the web about differences between 2005 and 2008. My question is more specific : Are YOU using 2008? are YOU experiencing problems (such as the FTS mentionned below?)
Maybe you should take a look at Breaking Changes to Database Engine Features in SQL Server 2008 for if you go with 2005 and try and upgrade later.
Personally at this stage I'd go with 2005 and avoid the features outlines in the article. Your customers/application/developers won't lose out on much (if any) functionality.
Database systems are one of the areas that considering the change is costly. From what I have seen so far, since 2005 works pretty well, large projects are probably still using it (some large projects even still use 2000). However, it doesn't mean 2008 is bad or doesn't worth it. If you are considering a new project, you should probably go with 2008. I don't think there are any big downside to do so.
About TFS, I got to say, team foundation server has one of the worst installation experiences I have ever seen in a Microsoft product. I believe it's an issue with TFS not SQL Server 2008. By the way TFS SP1 is compatible with 2008, but you have to integrate the service pack first.
One downside to 2008: Full-Text search is slower (in some cases, at least). This hit Stack Overflow (the link is to the SO blog). There are good reasons behind the change, but it's worth knowing about before you start.
If you don't need any of the functionality of SQL Server 2008, then I would recommend using SQL Server 2005 SP3. This is a mature, robust and feature-rich database platform. I am currently implementing a strategic database platform for a client right now and have standardised on SQL Server 2005 SP3 64bit clusters. None of my client's applications require any SQL Server 2008 features, and I get the comfort of knowing that SQL Server 2005 has been used in the field for three years now.
Main downside: you will be discovering the new bugs and you will be waiting for the corresponding packs or hotfixes. Please have a look at this page (cumulative update pack 11 for SQL server 2005) or navigate in the Microsoft Knowledge Base, close your eyes and imagine all the pain other users went through when they discovered these buggs ...
EDIT: we do not use SQL 2008. We do not need any of its new functionalities.
This is always a risk in moving to a new version of a program. These are some questions you should be asking yourself:
Have you already completed a lot of manual testing on the old version?
Can you cope with a bug in the new version?
How long has the new version been in use by other people?
Are you at the start or end of a project cycle?
The big risk in not moving to the new version now is that:
You will be forced to move later and that may not be such a good time for you. (But you may be able to skip a release so not having to repeat the pain as many times)
You can’t use what has been added to the new version
In the long term a lot less people will know how to use the old version
It is not good for your staff’s CV to be using too many very old versions of different things – hence it may affect your staff turnover etc.
So you need to plot, “pain” and “benefit” against time and then you will clearly see the right time to move; however we can’t see forward in time, and we can’t move back in time!