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.
Related
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/
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.
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.
We are currently evaluation our hosting options and the cheapest suitable option we've found only has SQL Server 2000 MSDE as the db server. Does this have the ability to schedule jobs using SQL Agent?
If not, can I use a windows scheduled job to run scripts for me?
Yes you can SQL Agent is part of SQL 2000 MSDE unlike SQL2005 Express...
http://msdn.microsoft.com/en-us/library/ms165672(SQL.90).aspx
Just answered this on your other question, but I'd recommend using Lazy Coding's SQLScheduler product. It's a nice bit of software that makes setting up and managing these a lot easier when you don't have the full version of SQL Server to hand
EDIT: I forgot to mention that it's also Freeware, so well worth grabbing a copy.
You can use SQL Agent on the MSDE version of SQL Server 2000 to schedule jobs. You will have to use a licensed copy of SQL Server, either the one that comes with MSDN or a retail copy and install the tools from it and then remotely connect to the MSDE installation of SQL server.
MSDE is at or over its support lifecycle:
http://blogs.msdn.com/sqlexpress/archive/2006/08/09/693650.aspx
So hopefully this host is using SQL Server Express (i.e. the free version of SQL Server 2005 or later) instead of MSDE.
Otherwise, Express doesn't come with a job scheduler. But you can always bundle up SQL commands either in .bat files or stored in .sql files and run them at the command prompt using oSQL (SQL Server 2000) or sqlcmd (SQL Server 2005). This would then let you use the windows scheduler.
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.