Here's the situation. We've been running BizTalk 2013 with SQL Server 2008 backbone for several months now. Meaning, our messagebox, SSO and all other database related things have resided on a Windows 2008 R2/SQL Server 2008 Cluster with 2 nodes and BizTalk 2013 has been running with 2 nodes on Windows Server 2008 R2 as well. It's been working great, however it's not time to upgrade SQL Server in our organization and our BizTalk environment is next.
We've already got 2 new servers, SQL Server 2012 installed, the BizTalk SSO components are installed on them (the SQL Servers will also be serving as Master Secret Servers). The BizTalk Servers are going to stay on the same nodes, as-is.
I have not been able to find any specific information on how one should go about switching to a new SQL server for BizTalk (especially when upgrading versions). So as a worst case, I was thinking of this:
stopping all our BizTalk services
exporting all MSIs and bindings
Unconfiguring BizTalk servers
reconfigure to point at the new SQL
server cluster import all MSIs and bindings
start all services again
Is this the correct approach? I know there is the possibility of moving the BizTalk databases, but I was under the impression that moving from SQL Server 2008 to SQL Server 2012 is not a good possibility.
Has anyone done this, or have any better ideas?
Yes, you can follow the guidence here to move the databases: http://msdn.microsoft.com/en-us/library/ee378546.aspx
So long as the version of SQL Server is supported by the version of BizTalk Server, which SQL Server 2012 is, you're ok.
The process you describe is essentially staging a new BizTalk Group, database and all. If you don't have to maintain long-running Orchestrations, this is the method I would recommend and take myself in your situation.
I've done both and un-Configure/re-Configure is just easier.
Related
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 restaurant with two computers, on the same network, each computer has SQL Server 2014 and my POS Software (Point of Sale).
Every once in a while I take a backup from my MAIN to my BACKUP computers.
The problem is that in SQL Server 2014 Express, the service SQL Server Agent is not starting, in any way possible, I tried.
I want to be able to connect to my MAIN computer through network.
All SQL Server 2014 data is connected well and working, plus all Services are running well, except for SQL Server Agent.
I see two solutions:
I downgrade my database from 2014 to 2012 and have SQL Server Agent Service Running, however I don't know how to do that.
I fix the SQL Server Agent service and have everything working well, I don't know how to do that either, I tried googling it, awkwardly I couldn't find an answer.
SQL Agent is not available on SQL Server Express edition, only on Standard and Enterprise
If you had SQL Agent running in 2012, that implies you have either standard, bi or enterprise edition.
Downgrading a database to an older version is not an easy task. There is no direct way to do this. If you still have your 2012 backup and very little or nothing has changed since the upgrade, just restore the 2012 database and manually sync the databases (i.e. manually move data). If it's a non-trivial amount of changes, you'll need to do a database copy or export/import from 2014 to 2012.
If you want to setup a scheduled backup of the SQL Express database, you can create a task using Windows scheduler to execute the backup using sqlcmd. For example:
SqlCmd -E -S Server_Name –Q “BACKUP DATABASE your_prod_db TO DISK='D:\folder_on_local_drive\your_prod_db.bak'"
As hinted in the sample, you should backup to the local computer first then copy the backup file to your remote computer. This can be part of the same job (ideally) or a separate job (a bit of extra effort to get the timing right). This can significantly increase the success rate of getting a good backup plus it'll probably run a lot faster too.
I'm planning to migrate all the SSRS reports from 2008R2 server to new sql server 2014 environment. As far as migration is concerned, I was asked to take the backup of 2008R2 report server database and restore it in 2014 server.
I was not convinced with this since there may be new tables available in 2014 Report server.
The new features of 2014 cant be utilized if the old report server database is restored.
Please let me know if this thought is correct.
Are there any new tables available in 2014 report server database?
What is the best option to migrate ssrs reports from 2008 r2 to 2014 server?.
Your question is a bit confusing, I will assume you want to move the database from a Server A with SQL Server 2008R2 + SSRS 2008R2 to a Server B with SQL Server 2014 + SSRS 2014.
Are there any new tables available in 2014 report server database?
There is no official communication on it.
If you really want to know it you could do a schema compare between the 2 versions.
But do not forget to compare everything, not only tables:
Columns
Stored Procedures, Functions
...
Database structure is not the only thing to take into account, what about:
All the configuration files
Encryption Keys
...
What is the best option to migrate ssrs reports from 2008 r2 to 2014
server?.
Short answer:
My recommended way of doing it would be to use RS Scripter and generate a script on Server A with all the objects (reports, datasources, subscriptions, ...) you want to move.
Then you can restore it on Server B.
Long answer:
If you really want to migrate the full database like you were asked to do, there is no officially supported way to move the database to another SQL instance and upgrade the version at the same time.
You could try to follow the steps to Backup and Restore Operations for Reporting Services, and apply it to a newer SQL Server instance with another SSRS version, but it will be at your own risk.
The supported ways to do would be to either:
Upgrade from SSRS 2008R2 to SSRS 2014 on Server A
Move from Server A to Server B
or
Move from Server A to Server B
Upgrade from SSRS 2008R2 to SSRS 2014 on Server B
Here are the related MSDN articles for these operations:
Migrate a Reporting Services Installation (Native Mode)
Upgrade to SQL Server 2014
Again, I would advise using a tool to migrate the reports and other items instead of trying to migrate the full database.
I do not think restore 2008R2 reportserver db on 2014 will work, because the report definition schema is totally different.
I did a migration task to move 2008R2 reports to 2012. Because there are hundreds of reports on the 2008R2 server, I found the easiest way is to write some codes to read report definition, and then create on 2012 server.
From: https://msdn.microsoft.com/en-us/library/ms143747.aspx
There are two general approaches to upgrading a Reporting Services
deployment:
Upgrade: You upgrade the Reporting Services components on
the servers and instances where they are currently installed. This is
commonly called an “in place” upgrade. In-place upgrade is not
supported from one mode of Reporting Services server to another. For
example, you cannot upgrade a Native Mode report server to a
SharePoint mode report server. You can migrate your report items from
one mode to another. For more information, see the ‘Native to
SharePoint Migration’ section later in this document.
Migrate: You
install and configure a new SharePoint environment, copy your report
items and resources to the new environment, and configure the new
environment to use existing content. A lower level form of migration
is to copy the Reporting Services databases, configuration files, and
if you are using SharePoint mode, the SharePoint content databases.
If you do an in-place upgrade from SQL Server 2008R2 to SQL Server 2014, then everything should work as expected.
My client is retiring a server and wishes to move our application's data from SQL Server 2005 to SQL Server 2008r2. We use Merge Replication via IIS to synch the data to Windows Mobile 6.5 devices. The devices currently are running SQL Server CE3, and we'd rather avoid the cost of coding the application to use Sql Server CE 3.5, deploying the new version to hundreds of devices, etc.
Unfortunately, although we were able to get the server side replication conversion set up correctly using 90 schema for all pieces, the clients are not able to get to the server. They seem to be stopped when they hit IIS, reporting that they are not able to reach the publication.
IIS was not changed as part of the conversion, so there should be no configuration problem there. In fact the diagnostics for the IIS replication proxy (i.e SQLCESA30.dll?diag) report that all is well.
It's clear that the snapshot directory is configured correctly as well. It appears that the problem occurs specifically when IIS attempts to communicate via SQLCESA30.dll with SQL Server 2008 R2.
This leads me to believe that there is some basic incompatibility with SQL Server CE 3.0 and SQL Server 2008 R2. Can anybody confirm this is true or offer a workaround?
You will have to install the 3.5 agent, and that also means pointing all devices to a new URL:
https://yourserver/yourdir/sqlcesa35.dll
See this rather confusing blog post for more info: http://blogs.msdn.com/b/sqlservercompact/archive/2007/12/19/connectivity-cross-version-compatibility-sql-server-compact-3-5.aspx
Your scenario is: "2.1.2 SQL Server Compact versions 3.0 or 3.1 and SQL Server 2008 (D4)"
"... a single SQL Server Compact 3.5 Server Agent URL can be used by all SQL Server Compact version 3.x Clients."
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