I have an automatic backup running each night through the Portal which should back up my Azure database to blob storage as a .bacpac file and up until Friday that had been working successfully.
Each night I get an email error saying:
Automated SQL Export failed for myServer:myDatabase at 5/30/2016 11:35:39 PM. The temporary database copy was made, but this copy could not be exported to the .bacpac file.
Some tutorials suggest logging into the Portal and doing it manually. When I do this it works successfully and I am able to see the file without error. But on the following night, the process fails again (it doesn't recover itself from performing a manual backup). Is there a way to get more information on why it is failing?
In the new Portal, you can find more information via audit log, database level operations will be logged there including import/export.
OK so after further analysis I was able to pinpoint the root cause of my issue to a Stored Procedure.
I had a Stored Proc which was explicitly referencing my database. Whenever the database backup is taken in Azure, it creates a temporary name and at that point, "breaks" the Stored Procedure as it was Self Referencing.
Fixing the Stored Proc has resumed the automatic backups.
An example of a statement the Proc was calling was:
Select Name from MyDatabase.Dbo.MyTable
This should be rewritten as the following to make it exportable:
Select Name from Dbo.MyTable
Note that while I was able to obtain a more meaningful error using a local copy of Sql Server Management Studio, no error was present in the Azure Portal.
Hopefully this will help someone else.
Related
We have a release pipeline in Azure DevOps that deploys a database project to our Azure SQL Database via the Azure SQL Dacpac Task. Everything has been working fine but suddenly yesterday the pipeline started failing with the following error:
##[error]*** An error occurred during deployment plan generation. Deployment cannot continue.
##[error]Error SQL72018: Permission could not be imported but one or more of these objects exist in your source.
As far as I know, nothing has changed on the database side or in the pipeline. We also ruled out that it could be an issue with the specific dacpac file because previously successful releases now fail with the same error.
I searched extensively for the SQL72018 error, but didn't really find any answers as to what would be causing that so am wondering if there was some Azure DevOps task update or something that we could be missing?
Not sure what would have caused this to break out of nowhere like that.
It does work if we add the p:/ignorePermissions=true parameter to the task, but we have never needed that before this.
UPDATE:
Wanted to update this as I was able to gather a little more information by adding the /Diagnostics:True parameter to the pipeline task in order to print out Diagnostic info from SQLPackage.
When I added that, I also see this error:
Microsoft.Data.Tools.Diagnostics.Tracer Error: 1 : 2022-04-05T08:38:37 : Error detected when reverse engineering the database. Severity:'Warning' Prefix:'' Error Code:'0' Message:The permission 'VDP ' was not recognized and was not imported. If this problem persists, contact customer support.
So it looks like some "VDP" permission is what is causing the issue, but we don't know what that permission is for or where it came from as it's not in the database project.
We finally got to the bottom of this. It turns out a new permission was added to the database the day before the pipeline started to fail. The database permission that caused the issue was VIEW DATABASE PERFORMANCE STATE. That was the VDP permission that SQLPackage.exe was complaining about.
Unsure why that particular permission caused the error as we manage all of our database permissions outside of the database project, so not sure why other permissions wouldn't have caused issues prior to this one.
Since we are managing permissions outside of our database project, the resolution was to add the p:/ignorePermissions=true SQLPackage parameter to the pipeline permanently. This was confirmed as the appropriate solution by a Microsoft representative after we put a ticket in.
It seems you have a spurious/orphan permission in your target database - as mentioned in this post How could our database be causing SqlPackage to fail? (SQL72018).
We have a process which needs to work with a series of Excel (sigh) files.
The setup is:
SQL agent job run as a SSIS proxy account.
Calls SSIS package on a share on the server.
Which then starts accessing these excel files using the ACE driver.
The process will work under my credentials.
The process will work under other people's credentials.
The process will work in debug mode (although this is not a fair test
as that would use my local machine's driver)
The process will not work using the SSIS proxy account.
The process WILL work if I make the SSIS proxy account an
administrator on the server.
I have ruled out the following:
access to the files share. The account can load text files from
there.
32bit/64bit issues. The account CAN run given sufficient
permissions.
My opinion is that the service account needs some sort of level of permission to be able to use the driver. I can't work out what though.
I have tried LOCAL SECURITY POLICY option "Load and unload device drivers" with no success. ( I did think this had done it, but then realised that I had left the account in the admin group :-( )
Finally, the error message in question:
SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER.
The AcquireConnection method call to the connection manager
"TPR_ReadReportsExcelConnection" failed with error code 0xC0202009.
There may be error messages posted before this with more information
on why the AcquireConnection method call failed.
This seems to be beyond the supported scope depending on how you've set up your SSIS proxy account. See Additional Information section here. Not enough points to post an image so here is the important sentence:
provided the SSIS jobs run in the context of a logged-on user with a valid HKEY_CURRENT_USER registry hive
While regular publish to Azure with WebDeploy, had checked Execute Code First Migrations, which i did before.
But this time the Use this connection string at runtime, was also checked, and i published without noticing it. as a result the remote azure db was wiped and instead is seeded with what looks like a default database with aspnetmemembership tables and _Migrations table that only has migrations related to identity tables.
The production data w db structures is gone and I did not yet setup backup on azure, doing it now.
Is there way to restore the database from some sort of auto backup on azure, i have web version w 1Gb size selected, I do not see any options
this suggests that web version would not have any daily backup, but also that web version is discountinued as of april, but i still have it. http://msdn.microsoft.com/en-us/library/jj650016.aspx
and another questions, i understand everything that happened? But it seems extremly dangerous that its so easy to wipe out the whole database and VS shows no warning nor publishing to azure notifies of anything. Is there anything that can be done to prevent dumb but yet very costly erros like this ?
TIA
As admin for an Azure subscription I am getting emails reporting:
Automated SQL Export failed for {server:database} at 9/5/2013 12:00:11
AM. The temporary database copy to export from could not be made.
I deleted this server, without explicitly removing the automated export configuration.
First question: how do I tell Azure to stop trying to do the export?
Second question: newbie mistake (if so please let me know what I failed to do) or bug?
Thanks!
I believe that this might be because the schema of the database has changed, which has resulted in an object (stored procedure, view, function) becoming invalid.
This problem / solution is elaborated on in another question:
Automated azure sql export fails
I am trying to take a backup and restore a site collection on my SharePoint 2003 Server environment using the STSADM utility. I was able to create a backup of my top level site which contains a document library of 2000 items. The utility completed successively generating a back up file around 2Gigs in size.
When i try to restore the site the utility gives an Operation Aborted message. Is there a log that is generated that gives better insight into why the restore operation failed?
Try the ULS logs as usual in the first instance...
You should monitor your SQL server. When doing backup and restores, TembDB takes a bit of a hammering, as does the database where your site is being restored. Ensure that everything has space to grow sufficiently (this may be more than you think - I've experienced the need for greater than 3 times the source data size).
If things should fail on the SQL end, this should be reflected in Application or SQL error logs on the SQL instance.
Are you renaming the site when you restore? If you are making the site name longer you may be running into limits over path lengths.