I have a Azure SQL Database with Auditing turned on. I noticed that my database comes online after a pause when it shouldn't. I checked the audit logs and it shows strange entries of 'sa' login trying to do smth. Not sure what these entries mean. Is a normal activity from Azure or somebody is trying to connect to my database? I believe that there is no such user 'sa' on Azure SQL databases, or am I wrong. Attaching the screenshot of audit logs.
Additional_info column shows these values (they repeat for every event).
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">destroyed</action_info>
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">event disabled</action_info>
<action_info xmlns="http://schemas.microsoft.com/sqlserver/2008/sqlaudit_data">event enabled<startup_type>automatic</startup_type></action_info>
logs
Tried Google, found nothing.
I created azure SQL database in azure portal, and I enabled auditing server level destination as storage account.
Image for reference:
After that I enabled auditing at database level with same destination of storage account.
Image for reference:
It enabled successfully, and containers are created successfully in storage account.
Image for reference:
Audit Records:
Here is my log
In this way I am not getting any error related to sa user.
As per my knowledge sa user is the admin you created during setup of SQL Azure server
According to this
Once the azure database is in pause status, it resumes automatically in the following conditions:
Database connection
database export or copy
Viewing auditing records
Viewing or applying performance recommendation
Vulnerability assessment
Modifying or viewing data masking rules
View state for transparent data encryption
Modification for serverless configuration such as max vCores, min vCores, or auto-pause delay
May be for above reason database still remains in online when you pause it.
Related
I am attempting to share an SQL view via Azure Data Share. I have set up the data share, created a share to send, and am attempting to add a dataset. I am logged into Azure Portal as me#example.com. I am also connected to the database (an Azure SQL DB) in SSMS as me#example.com. I do the following:
Select "Add datasets"
Select "Azure SQL Database"
Select the resource group
Select the SQL server
I got the the message about setting up permissions (the create user and exec sp_addrolemember db_datareader query), which I did successfully in SSMS. So, next I select the data, which was found successfully, and select "Next". This is where the problem starts.
I am given the options for Tables and Views. However, neither is populated. I can see all the tables and views in SSMS, including the view I created. However, when I select, say, "View" from the 2 options, it finds nothing and says, "No results to show".
This is mystifying. I clearly have access and permissions, yet it won't even populate the list of views. Any suggestions what might be causing this? This is my first Azure Data Share, and I could easily have missed something, but it seems like it should have everything that it needs for this operation.
Here are my assumptions:
It is using my Azure Portal login credentials to authorize access to populate the list.
The fact that I can see the tables and views in the SSMS Object Explorer implies sufficient permission to see the same in Azure Portal.
Since this data share and the database are in the same resource group, no firewall configuration is needed.
How to get the transaction logs for a Azure SQL db? I'm trying to find log from portal of azure but not getting any luck.
If there is no way to get the log where that is saying in Microsoft docs. any help is appriciate
You don't as it is not exposed in the service. Please step back and describe what problem you'd like to solve. If you want a DR solution, for example, then active geo-replication can solve this for you as part of the service offering.
The log format in Azure SQL DB is constantly changing and is "ahead" of the most recent version of SQL Server. So, it is probably not useful to expose the log (the format is not documented). Your use case will likely determine the alternative question you can ask instead.
Azure SQL Database auditing tracks database events and writes them to an audit log in your Azure storage account, or sends them to Event Hub or Log Analytics for downstream processing and analysis.
Blob audit
Audit logs stored in Azure Blob storage are stored in a container named sqldbauditlogs in the Azure storage account. The directory hierarchy within the container is of the form ////. The Blob file name format is _.xel, where CreationTime is in UTC hh_mm_ss_ms format, and FileNumberInSession is a running index in case session logs spans across multiple Blob files.
For example, for database Database1 on Server1 the following is a possible valid path:
Server1/Database1/SqlDbAuditing_ServerAudit_NoRetention/2019-02-03/12_23_30_794_0.xel
Read-only Replicas audit logs are stored in the same container. The directory hierarchy within the container is of the form ////RO/. The Blob file name shares the same format. The Audit Logs of Read-only Replicas are stored in the same container.
I have restored a database for an application that uses SQL Server logins for security. The restore is complete and functional, although there is a small issue.
The database users are present (Server->Database->Security->Users) but they are not present in the server logins (Server->Security->Logins). This is because I restored the DB on a different server than where the backup was taken.
So it seems I cannot reset their passwords anymore. AFAIK, you can only do this from Server->Security->Logins and not from the database security itself.
Is there anyway to quickly "synchronize" the whole thing so users show at both places ?
Thanks.
We have set up a logshipping scenairo on 2 Sql Server 2005 machines. The secondary database is in STANDBY mode.
We want to use this secondary server for reporting purposes, as the report viewers will query this STANDBY database according to their given execute rights. So we need multiple users on this secondary server, having different execute rights on the STANDBY database.
The problem is, after seting up log shipping, we can't grant the necessary permissions to the standby database as it is read-only.
Do you have any suggestions ?
Thanks,
Umut
For some reason, till we setup a better reporting system, we need to use the Standby server for reporting purposes.
And there is a way to create new users and give necessary sp execute rights to that user on the standby server.
The simple solution is, to create a login on the primary server and Select its SID from master table. Then with "sp_addlogin" create the same login with the same SID on the Standby database.
Then, on the primary server give required rights to the user on the database. With the restored transaction logs, the execute rights will ship to standby server. Passwords don't need to be the same on two servers, so the standby report viewer user can't access the primary server with the same credentials.
Sadly, you need to look into something other than log shipping.
Log shipping works by keeping up-to-date copies of your logs in a 'continually' restoring/recovery state on the secondary server. As such, the database there is never actually 'active' or live - as it's always just applying more and more logs and waiting for the command that will make it go active.
In other words, log shipping is ONLY for high-availability - it does NOT support duplication of your data in USABLE form.
To learn more about what purpose logging serves, check out this video:
http://www.sqlservervideos.com/video/logging-essentials/
And if you really need a secondary server for reporting purposes, then I'd suggest using something like transactional replication. (It's NOT suitable for high-availability solutions because of some of the schema changes and limitations you'd have to make... but it does work well as a way to 'publish' multiple copies of your database to different servers/locations for reporting purposes.)
I am having a problem with one database on my SQL Server 2005 production server.
A number of databases are already set up for mirroring, however when I right click and go to properties in SSMS, on one particular database there is no "Mirroring" property page available.
I have done the normal tasks, such as setting Full Recovery model, running a full backup of the database and backing up the logs.
I can't see that this is a server specific issue as other databases are happily mirroring.
I've looked around and I can't see that I'm missing a setting, any help would be appreciated.
Thanks.
EDIT: This is nothing to do with the Mirror Database yet, I can't get as far as specifying the Mirror Database , I cannot see the "Mirroring" page on the principle.
EDIT: I have managed to setup mirroring using t-sql commands. However I am still unable to see the "Mirroring Page".
UPDATE: This applies to the Transaction Log Shipping option as well. I can successfully set it up in SQL but not through SSMS.
Check theese items:
2 . The mirror database has to be created from a full backup of the principal server and should be restored in "Restore with Norecovery" model. It is followed by a restore of transaction log backup of the principal database so that the log sequence numbers of the mirror and the principal database are in synch with each other.
3 . The mirror database must have the same name as the principal database.
...
8 . DB Mirroring is available in Enterprise, Developer and Standard Editions, however, please refer to Microsoft website for a comparison chart as some features are not available in the Standard Edition. SQL Server Workgroup and Express Editions can only be used as witness servers.
Database Mirroring in Microsoft SQL Server 2005
Test monitoring with sp_dbmmonitorresults (Transact-SQL)
I don't have the answer, but I ran across the same symptom yesterday, and I remembered your question here, hahaha. My problem was that I set up database mirroring using the wizards, but one of the systems had a firewall blocking the mirroring port. The wizard setup went all the way to the final part of enabling database mirroring, and then errored out - but at that point, mirroring was already set up. Mirroring worked great, but there was something in the database metadata that wasn't set quite right. Even when I removed the firewall, parts of SSMS acted as if mirroring wasn't set up for that particular database, even though it was.
I then set up additional databases for mirroring (with the firewall off) and they worked great. My solution was to remove mirroring on that database and then add it again, and it worked fine. Doesn't sound like that's worked for you, though.
I ended up having to have a Microsoft Support call for the problem I was facing. Anyway after sometime and a number of support sessions they worked out that the database with the problem had an ID of 4 in sys.databases. IDs 1-4 are usually reserved for the system databases and if a database has any of these ids the T-log or Mirroring properties are not displayed. So somehow our database got the ID 3 and now I better get on and detach and reattach some databases to reassign IDs.