We're in the final phase of migrating our SQL Server on VM to Azure SQL Server. What is the most time-efficient approach to getting our existing SQL Server Agent Jobs out to Azure? I've noticed that inside of SSMS, when connected to an Azure SQL Server, the Agent does not exist - we were aware of this before migrating, but I have yet to have found whether there is an Azure service that replaces the SQL Server Agent Jobs functionality.
There are a number of options.
If you need timed execution of some data momement, Azure Data Factory can be a good replacement.
There is also an Azure Scheduler, that is often mentioned as an alternative. However, I believe that would work better on API's than directly on a database.
I think the best option is Azure automation and create a runbook that connects to your database and performs some action.
An interesting blog that details these options in more detail can be foond at: https://blogs.technet.microsoft.com/uktechnet/2016/02/05/is-sql-server-agent-missing-from-azure-sql-database/
Related
I have a SQL Server service account: domain\sqlservice.
This account is running both SQL Server service and SQL Server Agent Service.
This account has read/write permission to a file share: \\fileserver\Path1, and from the SQL Server and SQL Server Agent jobs, we are able to write to this folder path using the service account (using master..xp_cmdshell. xp_cmdshell is enabled).
This permission got removed by mistake, now we have added it back.
I can use the service account domain\sqlservice to browse to \\fileserver\Path1 and create files and folders (using Windows Explorer), but SQL Server and SQL Server Agent jobs still could not.
I have restarted the SQL Server Agent service (I believe this is account used to access the file share when running the SQL Server Agent jobs).
But it still failed to access the path - I get an access denied error.
I think I will need to restart the SQL Server service to fix this issue (waiting for my maintenance window now).
I want to understand it better, can someone give me some hint on why SQL Server Agent job is related to the SQL Server services running account? And what is the relationship between SQL Server Agent job service account and SQL Server service account? Are we still utilize this account to access fileshare defined in the SQL Server Agent job?
Thank you all very much
It looks like it takes time for the service account to get updated.
So I rerun the task in 10 hours
and task runs fine.
So I guess you have two options.
wait for the token or something expire and renewed.
you can restart the service.
#Charlieface’s comment explains the reason:
Double check that SQL Server is definitely still running under that service account, as well as which account has now received permissions to the share. The permissions for xp_cmdshell depend on whether the session has sa rights, see learn.microsoft.com/en-us/sql/relational-databases/…. Quite why you are using xp_cmdshell is a different question: it has major security implications, and should probably be converted into a SQL Agent job written in Powershell.
If I use one of the methods to migrate a SQL server instance with several databases into a Azure Managed Instance, would the procedure also replicate any login accounts with access rights?
Particular interested in knowing how this handles Active Directory accounts
From what I know, it doesn't and you cannot use Windows Authentication but only SQL Server Authentication or Azure AD. I've migrated several times a local database of my local SQL Server instance to Azure and I've done it using Export Data-Tier to .bacpac (this is the extension of the DB in Azure) and then deploying it (both actions from SSMS):
However, please be aware that you have to drop any users that use for authentication Windows Authentication because you'll get an error at the moment of deploying it since it cannot inherit your server's active directory settings. Then, you can define your own AD in Azure and use it.
Managed instance is a new deployment option of Azure SQL Database, providing near 100% compatibility with the latest SQL Server on-premises (Enterprise Edition) Database Engine.
The migration only support replicate the login.
You could get this from this document: Tutorial: Migrate SQL Server to an Azure SQL Database managed instance offline using DMS:
By default, Azure Database Migration Service only supports migrating SQL logins. To enable support for migrating Windows logins, see the Prerequisites section of this tutorial.
That means you must re-create all the users and grant it access right(database roles) manually.
Hope this helps.
I am running SQL Server 2014
I am trying to set up a scheduled SQL Agent job that runs an SSIS package and I need it to use a SQL Authentication login in order to access all the applications/servers the SSIS package accesses.
I have created a Credential that is mapped to the SQL Authentication login and connected it to a Proxy which the SQL Agent runs as when accessing the SSIS package, however, the job fails with an error message:
Unable to start execution of step 1 (reason: Could not get proxy data for proxy_id = 1). The step failed.
I have confirmed that:
I can access all servers/applications using the SQL Authentication account
The SSIS package connections are configured for SQL Authentication
I can run the SSIS package manually using the SQL Authentication fine
All accessed SQL Server Databases are configured for both Windows AD and SQL authentication login
When I create the SQL Server Agent Job, the step that runs the SSIS package has an option for the SQL Server Authentication login but the option is greyed out and I cannot select it:
I feel like I am missing a very obvious step but it's eluding me, any assistance will be appreciated.
#oscar and #chuck are both correct SQL Agent jobs running SSIS packages cannot run in SQL Authentication mode they have to use Windows Authentication. The user that runs the agent job unless you specify otherwise is the SQL Agent service account. It is that service account and the SQL Service account on the server you are running it on that will need certain permissions. However, you can change which account it executes as per chuck's note. Of course depending on who many different servers you are passing credentials and what is being accessed you can also get into a kerberos double hop problem...... Trust me solving that last part not so fun but still doable.
However the thing is if you must use SQL Authentication you don't need a windows user at all. you can put the SQL Authentication credentials in your connection strings of the connection managers in SSIS package. The SQL Agent service account can handle any file access issues for you and your connection strings can pass the sql credentials. no double hop problem and easy. If you are worried about embedding credentials you should use a less privileged sql account but you can also encrypt them and store them with the package. There are also several ways of dynamically getting them from an encrypted state.
If I only have one VM in Azure I can get outtages at any time when Azure decides to reboot/reprovision my server. Therefor I have to at least two servers in an availability group to get a stable environment.
This is used by a web app (web roles) and an important aspect is that the databases are used for reading. They will get their data from sql replication from an on-premises database. The replication can be done separately to each database. Additionally using Azure Sql Database is not an option because we have not be able to implement a durable data sync solution (using Microsoft Sync Framework), Sql Database does not support sql replication, and constantly uploading the complete database would be too slow.
How should the database VMs be hosted and accessed to able to use Sql Server VMs?
One alternative is to use AlwaysOn Availability Groups. This however requires Sql Server Enterprise edition and the price is very high considering I need to have at least two servers. In this scenario I at least get one connection point behind which a sql server always should be answering. This is however beyond our reach because of the cost.
One alternative could be to use Traffic manager to round robin the connections. When the database server goes down we have to wait for TTL to expire before the webrole would refresh the ip address so that seems a big problem.
How should one host Sql Server VMs in Azure?
You can use FailoverPartner parameter in the connection string to specify the secondary replica address. You can see more in this article.
I'm struggling with Microsoft SQL Data Sync Agent, which I need to setup the windows Azure platform.
In the ms sql data sync agent preview, the "Ping Sync Service" is successfully executed.
My windows firewall is allowing ingoing via port 1433.
The problem is, when I want to "Register":
First, I'm not sure that I enter the correct "Server" and "Database" names.
Second, I'm not sure whether I should use "SQL" or "Windows" Authentication
Third, how do I ensure that the Client Sync Agent has appropriate rights to the database?
Among alot of other trials, my best guess is:
Server " .\SQLEXPRESS"
Database "SiteSqlServer"
but still I get the following 2 error messages:
1) Unable to connect to the Database. PLease check if service account has connectivity, credentials and permissions to connect. Server: "XXX\SQLEXPRESS". Database: "SiteSqlServer".
2) Connection faild. Please check database credentials along with permissions for Microsoft SQL Data Sync Windows service logon account to connect to database with specified credentials.
Other reasons for failure:
Windows Azure SQL databases have to be added on the SQL Data Sync portal.
SQL Server databases lower than SQL Server 2005 SP2 are not supported on the SQL Data Sync.
I'm using: dotnetnuke CMS system and Microsoft webmatrix.
Any idea on how to proceed from here is warmly welcomed!
Thanks!
It seems you are trying to sync SQL Azure with SQL Express which is not supported and not tested. That's why when you try as described above you get that error. Based on my experiences there are issues using with SQL Express and SQL DataSync and SQL Express is not listed helow:
http://msdn.microsoft.com/en-us/library/windowsazure/hh456371.aspx
There are a few articles on internet where a few folks who went ahead and hacked the system to work with some vers'on of SQL Express so you are your own if you wish to try further. An article I found is here: