I have a problem with my new instance database in SQL Server 2014, I installed SQL server 2014 and have restored all the databases I had in my instance of SQL Server 2012, but it seems that SQL Server 2014 is slower. Is this the correct way to migrate data?
An example of that is slower is that if I open SQL Server Management Studio 2014 and try to deploy the database tree of my instance and it takes around 3 minutes, mientrar SQL Server Management Studio 2012 takes 3 seconds.
I was researching on how to support databases and replace all compatibility mode to 120 which is the compatibility mode SQL Server 2014 but still just as slow.
Can anybody help me?
Thank you very much and regards
Backup/restore is common way to switch database to another instance.
You mean connect to the instance is slower in new management studio? you need to run sql server Configuration Manager to enable all the server/client protocols such as Shared Memory/Namedpipe etc.
If you are saying the database performance is slower after migrated to new instance. You need to do some migration work:
https://www.mssqltips.com/sqlservertip/1936/sql-server-database-migration-checklist/
Related
I think you can help me.
I am developing an application for a small company. I have been working on Visual Studio 2015 with a SQL Server 2014 database and I have made a noob mistake. My app was almost finished but I discovered that the company has only one server with Windows Server 2003 on it, and it is not possible to update it.
Windows Server 2003 works up to SQL Server 2008 so I have tried but it has been impossible to me to attach my database to SQL Server 2008 (even changing compatibility level to 100) or connecting a new 2008 database to the application in Visual Studio 2015.
I do not know what to do now. Is there some possibility to make that my database works? Or is any other DBMS that would be better to work with my 2015 app in my 2003 server? Thanks!
You can create a database in production SQL Server 2008, then
create a Linked Server on your production Server to your development SQL Server 2014 and copy all the tables / procedures / functions over.
How to Create a Linked Server
Backup/restore works with older backup/newer restore server. Detach/attach do the same. The best solution here is to script developer DB (make sure you don't include newest features not supported by the production server) and run on production. If you want to move data as well, it is better to create at least two separate .sql's, one for schema and another for data.
I have a SQL Server instance running on Windows Server 2008 R2. The instance is hosting 120 databases. I want to migrate the SQL Server to a new physical server running Windows Server 2012R2 and SQL Server 2014 software installed on it.
To manually back up and restore databases is not a good option for me. How do I migrate the instance with 120 databases to SQL Server 2014?
Thanks!
The only way to upgrade all 120 databases in a single step is to upgrade the existing SQL Server instance in-place. No other way. Even if you have the databases on a SAN, the best you can do is detach from current instance then attach to new instance. Two actions per database, no shortcuts.
Backup/restore for 120 databases is a fair bit of work and depending on their sizes, it could take a long time also. However, it is pretty easy work plus the huge benefit you get is a quick and easy fallback to the original instance if something went bad with the new version. If you upgraded in place, it's a lot more effort to revert to the previous version.
I have a server running SQL Server 2008 Enterprise version which has a lot of SQL Codes and I want to upgrade it into SQL Server 2014 Enterprise version. But I don't know what will happen after I upgrade the SQL Server. Will there any SQL Code go unavailable/error? Will it run correctly after upgrading?
SQL Server 2008/2014 is a tool. It has got nothing to do with data/procedures/views etc. Data for SQL Server is stored in the form of .mdf files. So, no, your data or procedurers wont be touched. But yes lot of features are going to be deprecated in SQL Server 2014 when compared to SQL Server 2008. Full list is here. You should go through the list and find a suitable replacement for every deprecated item before migrating.
I'm asking for the proper way, in SQL Server's T-SQL (I think that's what it is) code or using another language, to import data from a Microsoft Access MDB Database into a new SQL Server Database.
Now, typically I would just import it in. The problem is I'm writing a .SQL script (I could use another technology if needed) to do all this leg work as this will need to be done fairly regularly. Likely at least once a week, for about 5 months in the year.
To digress a tad, I had wanted to implement a single database and distinguish separate source database using something like a DatabaseID field, but the powers that be overthrew me there.
I was previously using SQL Server Management Studio 2012 with SQL Server 2008 running the T-SQL (on a production machine) that worked fine. I've now migrated to a local SQL Server Management Studio 2012 with SQL Server 2012 (for development) and the code that used to work doesn't anymore.
This code is what used to work: SELECT * INTO [dbo].[Controls] FROM OpenDataSource('Microsoft.Jet.OLEDB.4.0', 'Data Source=C:\Show.mdb; Jet OLEDB:Database Password=BobSaget')...[Control] The password has been obfuscated for security ...
That's likely a sloppy solution. What's the ideal way?
Thanks in advance!
I would recommend using Microsoft's SQL Server Migration Assistant for Access.
SQL Server Migration Assistant (SSMA) is a free supported tool from Microsoft that simplifies database migration process from Access to SQL Server. SSMA for Access automates conversion of Microsoft Access database objects to SQL Server database objects, loads the objects into SQL Server, and then migrates data from Microsoft Access to SQL Server.
SSMA for Access v5.2 is designed to support migration from Microsoft Access 97 and higher to all editions of SQL Server 2005, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Azure.
You can find it here.
You may need to fix the structure after the migration as it tends to over exaggerate many of the data types.
Have you checked your DCOM security on MSDAINITIALIZE?
I had this problem when moving to a local instance of SSMS 2012.
http://blogs.msdn.com/b/dataaccesstechnologies/archive/2011/09/28/troubleshooting-cannot-create-an-instance-of-ole-db-provider.aspx
We have a production web and database server with SQL Server 2000. (However, a few clients they have their own servers with SQL 2005.) So we have local installs of SQL 2005 Express for development on Windows XP SP3 boxes (which don't allow SQL 2000 Enterprise installations).
We often need to copy SQL 2000 databases to SQL 2005 instances. In the past, we have used the SQL Publishing tool (also mentioned here). However, one of our databases is so big that using that tool fails as it creates SQL scripts that get too large for Management Studio to handle them properly. Besides, it takes too long... :)
We would use the Copy Database Wizard included with SQL 2005, but our development machines run SQL 2005 Express which don't included SQL Server Agent, which is required for Copy Database Wizard to work. So, I guess our solution will be to upgrade our development installs with the full version of SQL 2005 (we have an MSDN subscription of course).
I was wondering what other solutions, if any, work well for you guys? (Besides complaining to the bosses to upgrade our production servers to 2005 or even 2008--which I've already tried.)
Back it up in SQL Server 2000 and then use the RESTORE WITH MOVE command into 2005 Express.