I have used the following powershell script to delete a database:
Remove-AzureRmSqlDatabase -ServerName $server -ResourceGroupName $rgname -DatabaseName $dbname
(first setting the variables)
and have tried using the Azure Portal
The port indicates a success in deletion, as does the activity logs, however
the resource is not being deleted?
Screenshot of activity log:
The deletes (on a number of occasions after the db comes back) show successful, however there is an audit policy that seems to be doing something.
There are no Locks on the resrouce group.
UPDATE:
I have deleted from SSMS, and is not showing there or in the portal anymore..
(will wait to see if it comes back, as it did when deleting via portal and powershell)
UPDATE 2:
Database is now back, so this is the database having been deleted 3 ways, portal, powershell and via SSMS.
It turns out the web application uses EF migrations which is recreating the database.
Note: The bigger issue is that the database is created on a much higher, and much more expensive tier.
Do you happen to have a rogue policy somewhere? It seems something is running a Policy Effect: deployIfNotExist on the resource. Without access to your environment, there's not much I could recommend.
Check the documentation here: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effects#audit
Related
We've got a rogue process running somewhere that executes queries against a test database we have hosted on Azure SQL. I'm trying find this process so I can kill it. There are a number of app servers and development PCs where it could be hiding, and I haven't been able to track it down by looking at processes running on these machines by hand.
I can use The Azure Data Studio Profiler extension to get some Extended Event logging from the database. From there, I can see the text of queries being run, the Application Name and the ClientProcessID.
Sample data from profiler
I can't seem to use any of this data to find the host name or ip address of the server where these queries originate. Can I determine this using the data available in Azure Data Tools Profiler? Or is there some other way to work backward to find it? Since this is hosted on Azure, I can't use the Sql Management Studio Profiler, which I think would give me the Hostname right away.
Azure SQL Auditing should provide you the application name, login name and client IP address that executed the query. Please read this article to enable Auditing and look for the event type BATCH_COMPLETED.
Set-AzureRmSqlDatabaseAuditing `
-State Enabled `
-ResourceGroupName "rgYourResourceGroup" `
-ServerName "yourservername" `
-StorageAccountName "StorageAccountForAuditing" `
-DatabaseName "YourDatabaseName"
We are using Devops to recreate our demo environment. Within the Devops deployment we have an Azure Powershell task to copy our production Azure SQL database to a "demo" database on the same server the prod db is located on.
We first search for the databases on the server and if the "demo" database exists we delete it:
Remove-AzSqlDatabase -ResourceGroupName prdResource -ServerName prdServer -DatabaseName demoDb
Then we copy the prod db to the demo db:
New-AzSqlDatabaseCopy -ResourceGroupName prdResource -ServerName prdServer -DatabaseName prodDb -CopyDatabaseName demoDb
Finally we set the service level on the demoDb:
Set-AzSqlDatabase -ResourceGroupName prdResource -ServerName prdServer -DatabaseName demoDb -Edition "Standard" -RequestedServiceObjectiveName "S4"
This all works fine and the demo db is created correctly with the appropriate service level. The issue is our Azure prod webapp that is connected to the prod database struggles with performance issues. Calls that used to take ~2 seconds just prior to the copy db, now take 30+ seconds. We found if we restart the webApp that clears the issue.
Just wondering why the copy db command is effecting our performance on the web app? Are there other settings we should be using with the copy command? We have ran this process several times and get the same performance issues each time we run.
From our understanding this process should not have any negative side effects on the prod db, is that a correct assumption? Any other ways of fixing the issue without having to restart the webApp?
Scale out your sql database tier and located webapp and db to be in the same region.
These two changes resulted in a massive performance increase.
Also, you could refer to this article to troubleshoot Azure SQL Database performance issues with Intelligent Insights.
The DTU's really don't seem to be the issue as they don't go above 20%. We have a DevOps deployment in place that runs all the tasks and that is scheduled each Sat at 1:00am. Here is a screenshot of the DTUs for that database during that timeframe:
Also the DB and the WebApp are both in the East US Region so that also should not be the issue.
Again, restarting the webapp clears up the issue so that points to it not being a DB/DTU issue.
I used the Azure Backup client (MARS) to back up a server he had. The server no longer exists. In the Azure portal I am unable to delete the vault because the resource group contains backup items.
I tried using Powershell but Az.RecoveryServices is not meant to be used for MARS BackupManagementType. You can Get-AzureRmRecoveryServicesBackupContainer but then Get-AzureRmRecoveryServicesBackupItem fails because there is no WorkLoadType for MARS
So I cant delete the backup items from the Portal. I cant delete backup Items using powershell and the server no longer exists so I can use the MARS agent to delete items.
You can't delete a Recovery Services vault that has servers registered in it, or that holds backup data.
To gracefully delete a vault, unregister servers it contains, remove vault data, and then delete the vault.
If you try to delete a vault that still has dependencies, an error message is issued, and you will need to manually remove the vault dependencies, including:
Backed up items
Protected servers
Backup management servers (Azure Backup Server, DPM)
Refer to this article for detailed info:https://learn.microsoft.com/en-us/azure/backup/backup-azure-delete-vault
Note: You can use Cloud Shell available in portal to achieve this. Please select PowerShell after you launch Cloud Shell.
Kindly let us know if the above helps or you need further assistance on this issue.
If I used Get-AzAutomationSchedule for my automation account, I get nothing in return because I used Remove-AzAutomationSchedule for all of them. But if I look in the portal, every schedule I've deployed is there present. If I select a schedule that I've removed using Powershell and then attempt to update the schedule in the portal, I get the crying rain cloud and it says
NewScheduleBladeV2
MICROSOFT_AZURE_AUTOMATION
NewScheduleBladeV2
The reacurrance is also listed as unknown in the list.
This is a problem not only for clarity when viewing in the portal, but if I attempt to run my ARM template again with the schedules there, I get an "Internal Server Error" code 500. I can't redeploy them if I delete them with Powershell.
Is there anyway to send something to Azure to update these? Not sure if I need to do some API call or some form of Set-Az cmdlet
Thanks
I have tried to reproduce the issue you are facing but all worked good for me when i used cmdlets Get-AzAutomationSchedule and Remove-AzAutomationSchedule of Az.Automation module versioned 1.2.1.
Is this still an issue at your end ? If yes, can you restart the browser after clearing the cache and deleting the cookies ?
I am attempting to create a SharePoint Server Farm using the option via the New menu in Azure. I've tried like 5 times now and each time, it fails after about an hour.
The error is so cryptic that I cannot figure out exactly what is going on.
The operation name is: Microsoft.ClassicCompute/virtualMachines/extensions/write
The status is: Failed
And then another,
The operation name is: Update deployment
The status is: Failed.
Thoughts?
I've had a similar experience using the "new" preview portal when deploying Databases. This portal uses Resource Manager to deploy it's resources which is a new way of doing things. Anyhow, I used the PowerShell command:
Get-AzureResourceGroupLog -Name ResourceGroupName
This provided me the detail to understand what was happening with the deployment. I had to adjust my Datacenter because the one I was trying to use was hot.
I talk a little more about the other options this command has here:
http://devian.co/?p=1181