I have a number of databases on a Windows 2000 Server running the 32 bit version of SQL Server 2000. I need to transfer all the data and settings to a new server running the 64 bit version of SQL 2008 on Windows 2003 64 bit.
Is this as simple as backing up the databases and restoring to the new server. Will this work with the system databases (master, model, msdb) as well? If not, is there a way to automate the process of moving across the user accounts and permissions?
Is anybody aware of any other gotchas?
Many thanks for any help.
[EDIT] I've successfully tested an upgrade to SQL2008 32-bit, I'm mostly concerned with any differences in the 64-bit version as I don't have a 64 bit server I can test on at the moment e.g. I know you can't restore a SQL2000 master database to 2008; can you restore a SQL2008 32bit master to SQL2008 64bit? Downtime during the migration is not a problem.
To transfer logins, you should be able to use the 'Transfer Logins Task' described in Books Online here.
Ross Mistry has published a few articles on SQL Server 2008 Installation Strategies and Best Practices. Also this document, although directed at specific hardware, contains useful info.
EDIT: Have you looked at the Microsoft SQL Server 2008 Upgrade Advisor?
I would use the RedGate SQL Compare and SQL Data Compare. That would give you some assurances of the integrity of the database. However its not going to be an online migration of the data, you would have to prevent updates during the transition.
Related
We are working for a client with an asp.net/SQL server application which has been using a SQL Server 2005 system till now. The client has decided to upgrade the database to SQL Server 2008 R2 and has procured a powerful server machine with 16 processors with enough RAM and installed Windows Server 2008 64 bit on the system. Now we are tasked with the installation of SQL Server 2008 on the system followed by migration of the existing DB from the SQL 2005 box. Now I am not a SQL Server DBA nor am I a System Administrator by role. Hence, in spite of reading up a lot of the literature on the net, I am not quite able to make sense of it all or put it in the right order of execution. Can somebody explain me the following items, preferably in terms of bullet lists:
What are the points of consideration during installation of SQL Server 2008, specifically in terms of
Configuring memory usage
Configuring the SQL Server to take advantage of the multiple processors available
Other factors to configure to enable SQL Server 2008 features for performance and scalability
Other points, if any, for configuring the Windows Server 2008 with respect to SQL Server 2008
Note: We will only use the Database Engine services in SQL Server. The applications does not use SSIS, SSRS, etc.
SQL Server will take advantage of whatever processors are available. Processors will be shared between sessions - if all of the work is being done by a single session, then it will all occur on the same processor (to the best of my knowledge - this requires citation).
Memory usage is dynamic by default, meaning that there is no restrication on memory usage. You can limit the memory usage used by the server (right-click on the connection in SSMS and select properties) if needed. This is generally used if the instance is part of a server performing other tasks, such as running other database instances, web service tasks, etc.
SQL server is pretty good it sorting itself out according to its environment. If you are in a position that you need to create a server farm and distribute data and processing between different machines, this is a whole new topic, discussed at length on MSDN and the StackExchange forums.
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.
I need to install SQL Server 2008 on the server. I wanted to know which edition of SQL Server 2008 would scale for the usage of 350+users. Can you please share your views to select on which would be more appropriate?
SQL Server 2008 Datacenter
SQL Server 2008 Enterprise (32/64bit)
SQL Server 2008 Standard
SQL Server 2008 Developer
SQL Server 2008 Workgroup
Thanks,
With only user counts to go on and no idea how well the DB is architected AND how well written/designed the software application is for scalability makes this question very hard to say whether you will have scalability problems. Scalability of SQL Server has been well tested but often it is not SQL Server's fault that something is scaling badly. It is often a failing of the application code or a poor DB design.
However, with what you have given us information wise.....
Options 1-3 should be fine in general for that many users.
Option 4 is only meant to be on a developers workstation.
Option 5 is meant for small teams / users.
I'd say any of 1, 2 or 3 will work fine. Which of those you choose is going to depend on what type of application you are developing and what features you will be using. The Datacenter version is probably overkill, so it's probably going to come down to whether you need the features that Enterprise offers over Standard.
Probably the most significant difference is the CPU support - Standard only supports 4 CPUs. You can see a detailed comparison here
Generally I think the same as the tow above but it depends also from many various factors.
We run SQL Server 2005 exclusively for databases that we use (I'm trying to push to get them upgraded, but alas!). On the client side with Management Studio, are there any benefits to upgrading to SSMS2008 when only connecting to SQL Server 2005 databases? I've seen that Intellisense won't work, so I'm curious if it's worth the hassle.
Yes, there's quite a few improvements intellisense is definitely a big one for developers (Intellisense only works against SQL Server 2008 databases, unfortunately), but there are also other things like T-SQL Debugger, Activity Monitor, the Object Explorer Details
Also, multi-server queries, and the ability to color the connections (get a visual clue whether you're on dev, test or prod system) and a lot more.
See some good background info here at Simple-Talk.
It is up to you. My favorite is search feature. See link for details.
Having worked with SQL 2005 since it came out, upgraded my client tools to 2008 when it came out, and still not upgraded our server, I don't think it is worth upgrading, especially if you aren't moving to SQL 2008 on your server anytime soon. There is no real harm in upgrading, but you need to get familiar with a slightly different tool that IMO is neither worse nor better.
There are a lot of things to like about SQL2008 SSMS, even if you are connecting to SQL 2005 servers:
Customize the columns in the object views, including some very useful ones like DB size
When viewing a query execution plan, it will list any indexes that it recommends
Color-code server connections
Execute SQL statements against multiple servers
In our environment, we have a mix of SQL 2000, 2005, and 2008 servers, so I still use SQL 2005 SSMS to connect to all three (The new "Activity Monitor" in SQL2008 SSMS doesn't work for SQL 2000 servers.)
I don't want to sound like taking sides, but Toad 4.6 rulez! :-)
Exact duplicate:
Advantages of MS SQL Server 2008 over MS SQL Server 2005?
i am a sql developer and i use sql 2005. i want to now to pass to 2008 but i am a little affraid. can anyone gives me some advices about this. should i still continue using sql 2005 or is better pass all my projects to 2008 due to better performace?
Who is going to use your projects; if they are going to customers with existing SQL Licenses then 2005 might be the way to go; assuming they are running 2005. SQL 2005 databases will work on 2008; though if you use some of the new language features in 2008 then the SQL2008 databases wont be backwards compatible to 2005.
If you are controlling where they are going to be deployed; some of the new features in sql 2008 might be of interest; better full text search, improved Analysis services, reporting services and some language tweaks. If you are managing the servers; your admins will likely appreciate the new management features in 2008.
I moved to 2008 because I am heavy into SSIS and have large databases meaning: The backup compression and increased concurrent processes in SSIS for 2008 make it worth it for me.
I moved 6 projects from 2005 to 2008 without any problems except reporting services. To me the biggest benefit is the SQL Management Studio enhancements like auto complete and change history.
The only reason I did upgrade was because I work in education and Microsoft is very gracious on licensing.
In general, unless you hear that it is a disaster, I think you should strive to use the most recent release at the earliest opportunity. The advances in server functionality and the tool set will usually offset the time it takes you to learn the new features. All software is built with planned obsolescence in mind, so you will eventually need to migrate to newer technology. If you make a habit of migrating your systems to the latest technology, you will find that the migrations become relatively painless.
One of the benefits of SQLServer 2008 with respect to SSIS is that it includes very fast bulk connectors for Oracle and Teradata (well, the development and enterprise versions do).
So if you need to move data between SQLServer 2008 and those databases you get this for no additional cost.
See Microsoft Connectors for Oracle and Teradata by Attunity
Another major benefit in SQLServer 2008 is the new Change Data Capture (CDC) functionality which means you can build your application in any way you like and then if at later time you are interested in starting some processing when table X changed, you can turn on CDC for that table and get a change table that contains all the changes to table X with minimal overhead. Ben Hall did a useful post on this.
I think SQL 2008 has somewhat advantage in compare to sql 2005
New data types(date,time,files stream)
2.Backup compressin
3.Data compression
4.policy based management.
If anyone know better answer kindly inform