Open gstolz opened 6 years ago
Just to be clear, the originating database is present. This error only appears sporadically. That's why I assume this has something to do with too limited timeouts. (sorry for the partly German output. I hope the important part is still readable.)
@jaredmoo @akromm can you guys take a look at this issue?
Any updates on this issue?
This really became critical for us yesterday.
I already opened an issue #6122 but the behavior was that first it failed, and on the second try it succeeded. We were ok with that because we couldn't spend any more time dealing with support regarding this issue.
But yesterday it failed 5 or 6 times in a row. This stops us from deploying to production which is a critical issue.
Sorry for not getting a chance to look at this for such a long time.
DEBUG: ============================ HTTP REQUEST ============================
HTTP Method: GET
Absolute Uri:
https://management.microsoftazure.de/subscriptions/f291673a-/resourceGroups/dev2-rg/
providers/Microsoft.Sql/locations/germanycentral/databaseAzureAsyncOperation/3027d248-acbb-43d1-b45f-0f7683132da0?api-v
ersion=2017-10-01-preview
DEBUG: ============================ HTTP RESPONSE ============================
Status Code: OK
Body:
{
"name": "3027d248-acbb-43d1-b45f-0f7683132da0",
"status": "Succeeded",
"startTime": "2018-06-13T07:32:42.303Z"
}
DEBUG: ============================ HTTP REQUEST ============================
HTTP Method: GET
Absolute Uri:
https://management.microsoftazure.de/subscriptions/f291673a-/resourceGroups/dev2-rg/
providers/Microsoft.Sql/servers/azuresql-dbsrv/databases/azuresql-db?api-version=2017-10-01-preview
DEBUG: ============================ HTTP RESPONSE ============================
Status Code: NotFound
Body:
{
"error": {
"code": "ResourceNotFound",
"message": "The Resource 'Microsoft.Sql/servers/azuresql-dbsrv/databases/azuresql-db' under
resource group 'dev2-rg' was not found."
}
}
In the longs you can see that the long-running operation succeeded (GET databaseAzureAsyncOperation => "Succeeded"), but then GETting the database itself immediately after that failed.
Are you able to see the database using Azure management interfaces (e.g. Portal or PowerShell), and are you able to connect to the the database (e.g. using SSMS)? If you are able to connect with SSMS, was the database actually copied as expected?
My hypothesis for now is that the copy succeeded, but there is a timing issue where the database fails for GET in a short window after it is created.
@maboja-msft @jimoha fyi
Any updates on this is appreciated as we are also facing this issue.
@MertSenel, we may know the answer but would like to confirm with your case before publishing. Can you pls send the server and database name (source and target).
@MertSenel, we may know the answer but would like to confirm with your case before publishing. Can you pls send the server and database name (source and target).
@anosov1960, I unfortunately can't share details as it happened to us in production environment. I had to fix this fast, so I just installed AzureRM module 5.7.0 and the latest 6.13.1 side by side and converted my scripts to import version 5.7.0 instead of the latest.
I will try to replicate this in the upcoming weeks and share details.
Any news on this? We are running the New-AzureRmSqlDatabaseCopy daily and the above error is happening periodically.
AzureRM - 6.13.1 AzureRM.Sql - 4.12.1
Same issue for me also. An immediate rerun of the process is successful.
AzureRM.Sql 4.12.1
We experience this problem as well in Azure West Europe.
This just started for me in the last week too, but it's worked for the last 3 months, but for me, it's with New-AzureRmSqlDatabaseImport. Something seems to have changed recently. Ideally, I'd like to be able to look at a status and wait in my powershell to confirm that the delete was successful before running the import, but I intermittently get a "database already exists" error...
We understand the issue here - it's due to some complicated interactions with ARM resource tracking. Unfortunately the fix is not easy. We are investigating various strategies to improve the reliability of this scenario, but it will take some time. Thanks for your patience.
I too am getting the same issue, up to last week it was working great. Essentially what I want to do is as part of a staging build, delete existing staging db, take a copy of production db, restore this copy as staging
I ended up writing some PowerShell to loop until the database deletion was resolved. As I run my script in Dev/QA overnight, it wasn't a big deal to let it run for 5-10 minutes for it complete. Happy to share it here.
Same issue here, exact same scenario as @dannythomas13.
I got the same issue but with the newer New-AzSqlDatabaseCopy - been working fine for weeks. The command always works fine in CloudShell - the db copy takes approx 1 minute. When run in a release pipeline - it takes ages to fail - approx 10 minutes, when it works it takes approx 3 minutes - no idea why 3 times longer than interactive. Also when it fails, and I check the db has actually been copied successfully.
Can't believe this critical issue has been open for so long - doesn't anyone see the urgency in getting this fixed?
FYI I saw this related article https://github.com/microsoft/azure-pipelines-tasks/issues/10085 and it suggested issue was related to resources deleted immediately before the db copy i.e. the target of the copy. So I introduced a Wait 60 seconds task into my pipeline (from the Marketplace) and not seen an error so far since - although as it was intermittent, I can't read too much into the change so far.
@maboja-msft
This issue is still happening. When fix will be available ?
fyi since i introduced my Wait 60 seconds task in my pipeline I have not seen any re-occurrence. Its a workaround rather than a fix.
fyi since i introduced my Wait 60 seconds task in my pipeline I have not seen any re-occurrence. Its a workaround rather than a fix.
Can you tell me where is option to put my wait in azure power shell tasks in release pipeline
Pull the Wait task in from the marketplace, and then add to your release pipeline - task yaml for a 60 second delay is:
steps:
I am intermittently also getting this problem. I have a ps1 script called from the AzurePowerShell@4 YAML task that simply does the following:
Remove-AzSqlInstanceDatabase -ResourceGroupName $AzureResourceGroupName -InstanceName $AzureSqlServerResourceName -Name $DatabaseName -Force;
New-AzSqlInstanceDatabase -ResourceGroupName $AzureResourceGroupName -InstanceName $AzureSqlServerResourceName -Name $DatabaseName;
The script intermittently errors out on the New-AzSqlInstanceDatabase command, with an error:
Long running operation failed with status 'NotFound'.
The YAML target ran for 1m 41s on this occasion.
I will try the wait workaround but it is only a workaround.
I'm not working in this field anymore and cannot retest the original issue. But I would leave this open because of all the other users, so they can track any progress.
Same issue with command New-AzSqlDatabaseCopy. Any estimates in this issue resolve? Or any workaround if I use Azure Automation Account?
Still encountering this in 2022
Still encountering this in 2023 with New-AzSqlDatabaseCopy
Also still encountering this in 2024 with New-AzSqlDatabaseCopy.
Also still encountering this in 2024 with New-AzSqlDatabaseCopy. Region is North Europe.
I'm also experiencing this issue with the following flow via AzurePowerShell@5:
Remove-AzSqlDatabase New-AzSqlDatabaseCopy
Long running operation failed with status 'NotFound'.
The copy does appear to have worked however.
Description
When calling New-AzureRmSqlDatabaseCopy we sporadically receive error message "Long running operation failed with status 'NotFound'". (on Azure Germany)
Script/Steps for Reproduction
All the need resources are present.
Module Version
Environment Data
Debug Output