ImportSales<\/code> database, run the following T-SQL code:<\/p>\n\n\n\nUSE master;\nGO\nDROP DATABASE IF EXISTS ImportSales;\nGO\nCREATE DATABASE ImportSales;\nGO\nUSE ImportSales;\nGO\nCREATE SCHEMA Sales;\nGO\nCREATE TABLE Sales.Customers(\n CustID INT IDENTITY PRIMARY KEY,\n Customer NVARCHAR(100) NOT NULL,\n Contact NVARCHAR(50) NOT NULL,\n Email NVARCHAR(256) NULL,\n Phone NVARCHAR(20) NULL,\n Category NVARCHAR(50) NOT NULL);\nGO\nINSERT INTO Sales.Customers(Customer, Contact, Email, Phone, Category) \nSELECT c.CustomerName, p.FullName, p.EmailAddress,\n p.PhoneNumber, cc.CustomerCategoryName\nFROM WideWorldImporters.Sales.Customers c\n INNER JOIN WideWorldImporters.Application.People p\n ON c.PrimaryContactPersonID = p.PersonID\n INNER JOIN WideWorldImporters.Sales.CustomerCategories cc\n ON c.CustomerCategoryID = cc.CustomerCategoryID;\nGO<\/pre>\n\n\n\nIf you don\u2019t have the WideWorldImporters<\/code> database installed, you can populate the Customers<\/code> table with your own data. If you want to use a different table and database for these examples, skip the T-SQL statements above and use a database and table that best suit your needs (and are not in a production environment, of course). Just be sure to replace any references to the ImportSales<\/code> database or Customers<\/code> table in the subsequent examples.<\/p>\n\n\n\nThe next step is to create an audit object at the SQL Server instance level and a database audit specification at the ImportSales<\/code> database level. The audit object serves as a container for organizing the server and database audit settings and for delivering the final audit logs. For this article, you\u2019ll be saving the audit data to a local folder, but know that SQL Server Audit also lets you save the data to the Windows Application log or Security log.<\/p>\n\n\n\nA database audit specification is created at the database level and is associated with an audit object, which means that the audit object needs to exist before you can create the database audit specification. The specification determines what actions should be audited at the database level. You can also create a server audit specification for auditing actions at the server level, but for this article, you need only the database audit specification.<\/p>\n\n\n\n
To create both the audit object and database audit specification, run the following T-SQL code:<\/p>\n\n\n\n
USE master; \nGO \nCREATE SERVER AUDIT ImportSalesAudit \nTO FILE (FILEPATH = 'C:\\DataFiles\\audit\\'); \nGO \nALTER SERVER AUDIT ImportSalesAudit \nWITH (STATE = ON); \nGO \nUSE ImportSales; \nGO \nCREATE DATABASE AUDIT SPECIFICATION ImportSalesDbSpec \nFOR SERVER AUDIT ImportSalesAudit\nADD (SCHEMA_OBJECT_CHANGE_GROUP),\nADD (SELECT, INSERT, UPDATE, DELETE \n ON Object::Sales.Customers BY public) \nWITH (STATE = ON); \nGO<\/pre>\n\n\n\nThe CREATE<\/code> SERVER<\/code> AUDIT<\/code> statement creates an audit object named ImportSalesAudit<\/code> that saves the audit data to the C:\\DataFiles\\Audit<\/em> folder. You must then run an ALTER<\/code> SERVER<\/code> AUDIT<\/code> statement as a separate step to set the STATE<\/code> property to ON<\/code>.<\/p>\n\n\n\nNext comes the CREATE<\/code> DATABASE<\/code> AUDIT<\/code> SPECIFICATION<\/code> statement, which defines a specification named ImportSalesDbSpec<\/code>. The specification includes two ADD<\/code> clauses. The first ADD<\/code> clause specifies the action group SCHEMA_OBJECT_CHANGE_GROUP<\/code>, which audits all CREATE<\/code>, ALTER<\/code>, and DROP<\/code> statements issued against any schema objects in the database. Because this is a group action, it must be specified separately from individual actions, such as those in the second ADD<\/code> clause.<\/p>\n\n\n\nThe second ADD<\/code> clause specifies four individual actions:<\/p>\n\n\n\n
\nThe SELECT<\/code> action audits all SELECT<\/code> statements.<\/li>\n\n\n\nThe INSERT<\/code> action audits all INSERT<\/code> statements.<\/li>\n\n\n\nThe UPDATE<\/code> action audits all UPDATE<\/code> statements.<\/li>\n\n\n\nThe DELETE<\/code> action audits all DELETE<\/code> statements.<\/li>\n<\/ul>\n<\/div>\n\n\nThe ON<\/code> subclause in the second ADD<\/code> clause points to the Customers<\/code> table, which means that the SELECT<\/code>, INSERT<\/code>, UPDATE<\/code>, and DELETE<\/code> actions are all specific to that table. In addition, because the BY<\/code> subclause specifies the public<\/code> login, the auditing applies to all users.<\/p>\n\n\n\nUnder normal circumstances, you would likely be auditing many more users and actions than you\u2019ve done here, but this is enough to demonstrate the basic principles behind using Power BI to review audit data.<\/p>\n\n\n\n
With the auditing structure in place, run the following T-SQL code to create three test user accounts within the ImportSales<\/code> database, assigning a different set of permissions to each user:<\/p>\n\n\n\nCREATE USER User01 WITHOUT LOGIN;\nGRANT ALTER, SELECT, INSERT, DELETE, UPDATE\nON OBJECT::Sales.Customers TO user01; \nGO\nCREATE USER User02 WITHOUT LOGIN;\nGRANT SELECT, INSERT, DELETE, UPDATE\nON OBJECT::Sales.Customers TO user02; \nGO\nCREATE USER User03 WITHOUT LOGIN;\nGRANT SELECT\nON OBJECT::Sales.Customers TO user03; \nGO<\/pre>\n\n\n\nThe user accounts are created without logins to keep the testing simple. For the same reason, all the granted permissions are specific to the Customers<\/code> table, with access defined as follows:<\/p>\n\n\n\n
\nUser01<\/code> can access and modify all data within the table as well as update the table\u2019s definition.<\/li>\n\n\n\nUser02<\/code> can access and modify all data within the table but is not permitted to update the table\u2019s definition.<\/li>\n\n\n\nUser03<\/code> can access all data within the table but is not permitted to modify any of the data or update the table\u2019s definition.<\/li>\n<\/ul>\n<\/div>\n\n\nYou can set up the test users and their permissions any way you like, so that you have them in place when you\u2019re ready to generate audit data to use in Power BI Desktop.<\/p>\n\n\n\n
Generating Test Audit Data<\/h2>\n\n\n\n To generate the audit data, you should run a series of data manipulation language (DML) statements and data definition language (DDL) statements against the Customers<\/code> table, running them within the execution context of the three database user accounts. The easiest way to do this is to use an EXECUTE<\/code> AS<\/code> statement to specify the user context, run one or more statements, and then run a REVERT<\/code> statement to switch back to the original user.<\/p>\n\n\n\nYou can run whatever DML and DDL statements you want, as long as you test each account and the permissions assigned to that account. On my system, I ran several sets of T-SQL statements, most of them multiple times to generate a reasonable amount of data. If you want to use the same statements that I used, start with the following DML statements, running them under the User01<\/code> account:<\/p>\n\n\n\nEXECUTE AS USER = 'User01';\nSELECT * FROM Sales.Customers;\nINSERT INTO Sales.Customers \n (Customer, Contact, Email, Phone, Category)\n VALUES('Wingtip Toys (Eugene, OR)', 'Flora Olofsson', \n 'flora@wingtiptoys.com', '(787) 555-0100', 'Gift Store');\nDECLARE @LastID INT = (SELECT SCOPE_IDENTITY())\nUPDATE Sales.Customers SET Category = 'Novelty Shop' \nWHERE CustID = @LastID;\nDELETE Sales.Customers WHERE CustID = @LastID;\nREVERT;\nGO<\/pre>\n\n\n\nBe sure to run these statements multiple times, according to how much audit data you want available. I ran the DML statements about five times and the DDL statements either one or two times.<\/p>\n\n\n\n
After you run the preceding DML statements, run the following statements to add a column to the Customers<\/code> table, again as User01<\/code>:<\/p>\n\n\n\nEXECUTE AS USER = 'User01';\nALTER TABLE Sales.Customers\nADD Status BIT NOT NULL DEFAULT(1); \nREVERT;\nGO<\/pre>\n\n\n\nNext, repeat the same DML statements for User02<\/code>, again running the block of statements multiple times:<\/p>\n\n\n\nEXECUTE AS USER = 'User02';\nSELECT * FROM Sales.Customers;\nINSERT INTO Sales.Customers \n (Customer, Contact, Email, Phone, Category)\n VALUES('Tailspin Toys (Bainbridge Island, WA)', 'Kanti Kotadia', \n 'kanti@tailspintoys.com', '(303) 555-0100', 'Gift Store');\nDECLARE @LastID INT = (SELECT SCOPE_IDENTITY())\nUPDATE Sales.Customers SET Category = 'Novelty Shop' \nWHERE CustID = @LastID;\nDELETE Sales.Customers WHERE CustID = @LastID;\nREVERT;\nGO<\/pre>\n\n\n\nNow try to add another column to the Customers<\/code> table, but this time as User02<\/code>, using the following T-SQL:<\/p>\n\n\n\nEXECUTE AS USER = 'User02';\nALTER TABLE Sales.Customers\nADD LastUpdated DATETIME NOT NULL DEFAULT(GETDATE()); \nREVERT;\nGO<\/pre>\n\n\n\nThe statement should generate an error because the User02<\/code> account does not have the proper permissions to modify the table definition. Be aware, however, that if you run one or more T-SQL statements under the context of a specific user and one of the statements fails, the REVERT<\/code> statement will not run, in which case, you must rerun the REVERT statement, without the other statements, to ensure that you close that execution context. (A better approach, of course, is to add the proper logic to your code to ensure that the REVERT<\/code> statement always runs.)<\/p>\n\n\n\nNext, run the same DML statements as before, but under the User03<\/code> account:<\/p>\n\n\n\nEXECUTE AS USER = 'User03';\nSELECT * FROM Sales.Customers;\nINSERT INTO Sales.Customers \n (Customer, Contact, Email, Phone, Category)\n VALUES('Tailspin Toys (Bainbridge Island, WA)', 'Kanti Kotadia', \n 'kanti@tailspintoys.com', '(303) 555-0100', 'Gift Store');\nDECLARE @LastID INT = (SELECT SCOPE_IDENTITY())\nUPDATE Sales.Customers SET Category = 'Novelty Shop' \nWHERE CustID = @LastID;\nDELETE Sales.Customers WHERE CustID = @LastID;\nREVERT;\nGO<\/pre>\n\n\n\nIn this case, the INSERT<\/code>, UPDATE<\/code>, and DELETE<\/code> statements each return an error because of the lack of permissions, which means you\u2019ll once again need to run the REVERT<\/code> statement separately. The same goes for the following ALTER<\/code> TABLE<\/code> statement, which also returns an error:<\/p>\n\n\n\nEXECUTE AS USER = 'User03';\nALTER TABLE Sales.Customers\nADD LastUpdated DATETIME NOT NULL DEFAULT(GETDATE()); \nREVERT;<\/pre>\n\n\n\nAgain, you can run whatever DML and DDL statements you like to generate the test audit statements. The idea is to have enough data to use in Power BI Desktop.<\/p>\n\n\n\n
Connecting to SQL Server Audit Data in Power BI Desktop<\/h2>\n\n\n\n When connecting to SQL Server within Power BI Desktop, you can retrieve the data from specific tables and views, or you can run a query that returns exactly the data you need from multiple tables and views. With a query, you can also use system functions such as sys.fn_get_audit_file<\/code>, a table-valued function that returns data from SQL Server Audit log files. (You cannot use this function to retrieve data from the Application or Security log.)<\/p>\n\n\n\nFor this article, you will use the function in the following SELECT<\/code> statement to return the user account, action, success status, T-SQL statement, and event time of each logged event:<\/p>\n\n\n\nSELECT f.database_principal_name [User Acct],\n (CASE\n WHEN a.name = 'STATEMENT ROLLBACK' THEN 'ROLLBACK'\n ELSE a.name \n END) [User Action], \n (CASE\n WHEN f.succeeded = 1 THEN 'Succeeded'\n ELSE 'Failed'\n END) [Succeeded],\n f.statement [SQL Statement],\n f.event_time [Date\/Time]\nFROM sys.fn_get_audit_file \n ('C:\\DataFiles\\audit\\ImportSalesAudit_*.sqlaudit', \n default, default) f\n INNER JOIN (SELECT DISTINCT action_id, name \n FROM sys.dm_audit_actions) a\n ON f.action_id = a.action_id\nWHERE f.database_principal_name IN ('User01', 'User02', 'User03')<\/pre>\n\n\n\nThe statement joins the sys.fn_get_audit_file<\/code> function to the sys.dm_audit_actions<\/code> function to return an action\u2019s full name, rather than its abbreviation. The statement also limits the results to the three test user accounts.<\/p>\n\n\n\nYou\u2019ll use this SELECT<\/code> statement when setting up your SQL Server connection in Power BI Desktop. To configure the connection, create a new report in Power BI Desktop, click the Get Data<\/em> down arrow on the Home<\/em> ribbon, and then click SQL Server<\/em>. When the SQL Server database<\/em> dialog box appears, click the Advanced options<\/em> arrow to expand the dialog box, as shown in Figure 1.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 1. Defining a SQL Server connection in Power BI Desktop<\/p>\n\n\n\n
To configure the connection:<\/p>\n\n\n
\n
\nType the SQL Server instance in the Server<\/em> text box.<\/li>\n\n\n\nType the name of the database, ImportSales<\/code>, in the Database<\/em> text box.<\/li>\n\n\n\nSelect an option in the Data Connectivity<\/em> mode section. I chose DirectQuery<\/em>.<\/li>\n\n\n\nType or paste the SELECT<\/code> statement into the SQL statement<\/em> text box.<\/li>\n<\/ol>\n<\/div>\n\n\nWhen you select DirectQuery,<\/em> no data is imported or copied into Power BI Desktop. Instead, Power BI Desktop queries the underlying data source whenever you create or interact with a visualization, ensuring that you\u2019re always viewing the most current data. Be aware, however, that if you plan to publish your report to the Power BI service, you\u2019ll need to set up a gateway connection that enables the service to retrieve the source data. Also, note that you cannot create a Power BI Desktop report that includes both a DirectQuery<\/em> SQL Server connection and an Import<\/em> SQL Server connection. You must choose one or the other.<\/p>\n\n\n\nAfter you\u2019ve configured the connection in the SQL Server<\/em> database<\/em> dialog box, click OK<\/em>. This launches a preview window, where you can view a sample of the audit data, as shown in Figure 2.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 2. Verifying the SQL Server Audit data<\/p>\n\n\n\n
If everything looks as you would expect, click Load<\/em> to make the data available to Power BI Desktop, where you can use the data to add tables or visualizations. If you selected DirectQuery,<\/em> you\u2019re loading only the table schema into Power BI Desktop, with no source data imported until it is needed.<\/p>\n\n\n\nAs noted earlier, you\u2019re not limited to saving the audit data to log files. You can also save the data to the Application or Security log, but that means taking extra steps to get the data out of the logs and into a digestible format, such as a .csv file.<\/p>\n\n\n\n
For example, you can export the data from Windows Event Viewer or the Log File Viewer in SQL Server Management Studio (SSMS), but the resulting format can be difficult to work with, and you could end up with much more data than you need. Another approach is to use PowerShell to retrieve the log data, creating a script that can be scheduled to run automatically. In this way, you have far more control over the output, although there\u2019s still some work involved to get it right.<\/p>\n\n\n\n
Regardless of how you make the data available to Power BI Desktop, the more important consideration is data security. The Security log might be the safest approach initially, but once you export the data to files, you\u2019re up against the same issues you face when sending the data directly to log files. The data in those files needs to be fully protected at all times both at-rest and in-motion. There would be little point in implementing an audit strategy to comply with regulatory standards if the auditing process itself puts the data at risk.<\/p>\n\n\n\n
Once you\u2019ve made the test audit data available to Power BI Desktop, you can create reports that present the data in ways that offer different insights. Throughout the rest of the article, I show you several approaches that I\u2019ve tried, using both tables and visualizations, in order to demonstrate ways you can present SQL Server Audit data. For details on how to actually create these components, refer to Part 7 of this series, Building Reports in Power BI Desktop<\/a>.<\/p>\n\n\n\nAdding a Table to Your Report<\/h2>\n\n\n\n One useful approach to presenting information is to make at least some of the data available in tables. For example, Figure 3 shows a table that includes all the audit data I pulled into Power BI Desktop. You can, of course, filter the data however you need to, such as with Slicers, depending on your specific audit strategy. The auditing that\u2019s implemented for this article is very simple in comparison to the types and amounts of data that you will likely be generating.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 3. Adding a table and slicers to a report page<\/p>\n\n\n\n
In addition to the table, I added three slicers to the report page for filtering the data by users, actions, and successes and failures. For example, Figure 4 shows the data I generated on my system after I filtered the information by the User03<\/code> account and the Failed<\/code> status.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 4. Using slicers to filter data in a table<\/p>\n\n\n\n
When you apply a filter, Power BI updates the data in the table and slicers, based on the selected values. In this way, you have a quick and easy way to access various categories of data, without needing to manually weed through gobs of data or generate a new T-SQL statement each time you want to focus on different information.<\/p>\n\n\n\n
Adding a Matrix to Your Report<\/h2>\n\n\n\n Another effective way to provide quick insights into the data is to add a matrix that summarizes the data. For example, Figure 5 shows a matrix that displays the number of actions per user and action type. (A ROLLBACK<\/code> statement is issued when a primary statement fails, such as when a user does not have the permissions necessary to run a statement.)<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 5. Adding a matrix and slicers to a report page<\/p>\n\n\n\n
On the same report page as the matrix, I added two slicers, one for user accounts and the other for user actions, again allowing me to easily filter the data as needed.<\/p>\n\n\n\n
What is especially useful about the matrix is that you can set it up to drill down into the data. In this case, the matrix allows you to drill to the number of actions that have succeeded or failed. For example, Figure 6 shows the matrix after drilling down into all users, although it\u2019s also possible to drill down into specific users.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 6. Drilling into a matrix<\/p>\n\n\n\n
When setting up the drill-down categories in a matrix, you can choose the order in which to present each layer, depending on the type of data and its hierarchical nature. For example, this matrix can also be configured to drill down further into the T-SQL statements associated with each category.<\/p>\n\n\n\n
Adding Visualizations to Your Report<\/h2>\n\n\n\n Power BI Desktop supports a wide variety of visualizations, and you can import even more. You should use whichever visualizations help you and other users best understand the types of audit data you\u2019re collecting. For example, Figure 7 shows a report page with three types of visualizations, each providing a different perspective into the audit data (keeping in mind that you\u2019re working with a limited sample size).<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 7. Adding visualizations to a report page<\/p>\n\n\n\n
For all three visualizations, I filtered out the ROLLBACK<\/code> actions, so the visualizations reflect only the statements that were initiated by the users, rather than those generated as a response to their actions. The visualizations on the left and top-right are clustered bar charts. The clustered bar chart lets you group related data in various ways to provide different perspectives.<\/p>\n\n\n\nFor example, the clustered bar chart on the left groups the data by user, and for each user, provides a total for each action type. In this case, the DML actions show the same totals across all three user accounts because I ran the statements the same number of times. Even so, the visualization still demonstrates how you can use the clustered bar chart to provide a quick overview of the data from different perspectives, in this case, the types of statements each user has tried to run.<\/p>\n\n\n\n
The clustered bar chart at the top right also groups the data by user, but then provides a total of statement successes and failures for each account, making it possible to see which users might be attempting to run statements that they\u2019re not permitted to run.<\/p>\n\n\n\n
The bottom right visualization is a basic donut chart. The visualization presents the same data as the clustered bar chart above it, but in a different way. If you hover over one of the elements, for example, you\u2019ll get the percentage of total actions. What all this points to is that you can try out different visualizations against the same data to see which ones provide the best perspectives into the underlying information.<\/p>\n\n\n\n
When you place elements on the same report page, Power BI automatically ties them together. In this way, if you select an element in one visualization, the other visualizations will reflect the selection. For example, if you click the Failed<\/em> bar for User03<\/em> in the top right clustered bar chart, the corresponding data elements in the other visualizations will be selected, resulting in the nonrelated elements being grayed out.<\/p>\n\n\n\nAdding a Gauge to Your Report<\/h2>\n\n\n\n Power BI Desktop also lets you add elements such as gauges, cards, and key performance indicators (KPIs) to a report. For example, I added the gauge shown in Figure 8 to display the number of ROLLBACK<\/code> statements that were executed in response to the users\u2019 failed attempts to run T-SQL statements.<\/p>\n\n\n\n<\/p>\n\n\n\n
Figure 8. Adding a gauge to a report page<\/p>\n\n\n\n
I also added a slicer for the user accounts to make it easy to see whether individual users are hitting the specified threshold. In Figure 8, the User03<\/code> account is selected in the slicer, so the gauge shows only the number of rollbacks that pertain to that user. The gauge also specifies a target of 50,<\/em> but you can specify any target value.<\/p>\n\n\n\nThe reason the target value is significant is that you can set alerts based on that value in the Power BI service (something you cannot do in Power BI Desktop). To use this feature, however, you must have a Power BI Pro license, which allows you to set up alerts that notify you regularly about potential issues. You can also set up alerts that generate email notifications on a regular basis. Plus, you can add alerts to card and KPI visuals.<\/p>\n\n\n\n
Visualizing Audit Data in Power BI<\/h2>\n\n\n\n Using Power BI to visualize SQL Server Audit data can provide you will a powerful tool for reviewing the logged information in a quick and efficient manner. What I\u2019ve covered here only scratches the surface. There\u2019s far more to SQL Server Audit and Power BI Desktop, and both topics deserve much more attention.<\/p>\n\n\n\n
But this article should at least offer you a good starting point for understanding what it takes to use Power BI to work with SQL Server Audit data. It\u2019s up to you to decide how far you want to take this and how extensively you might want to use the Power BI service, in addition to Power BI Desktop, keeping in mind the importance of protecting the audit data wherever it resides.<\/p>\n\n\n\n\n FAQs: Power BI Introduction: Visualizing SQL Server Audit Data \u2014 Part 9<\/h2>\n\n 1. What SQL Server views contain audit data for Power BI?<\/h3>\n \n
SQL Server Audit stores data in the Windows Security Event Log, a binary file target, or the Application Log, depending on configuration. To query audit data, use the sys.fn_get_audit_file function: SELECT * FROM sys.fn_get_audit_file(‘C:AuditLogs*.sqlaudit’, DEFAULT, DEFAULT). For SQL Server Audit configured to write to a file target, this function returns one row per audit event with columns for action_id, object_name, database_name, statement, and server_principal_name. Use this query as the Power BI data source in a native database query connection.<\/p>\n <\/div>\n
2. How do I connect Power BI Desktop to SQL Server Audit data?<\/h3>\n \n
In Power BI Desktop, select Get Data > SQL Server. Enter the server and database name, then under Advanced Options, enter a native database query using sys.fn_get_audit_file or a view built on top of it. This returns the audit events as a Power BI table that can be modelled, filtered, and visualised. Alternatively, create a SQL Server view or stored procedure that queries the audit file and connect Power BI to that view – this abstracts the file path and makes the connection simpler to manage as the audit file location changes.<\/p>\n <\/div>\n
3. What Power BI visualisations work well for SQL Server Audit data?<\/h3>\n \n
Effective visualisations for audit data: bar or column charts by action_id (to see which operations are most frequent); time series line charts for activity over time; tables or matrices showing the most recent events with filters for specific users, objects, or action types; gauges for KPIs like failed login count or DDL changes in a period; and cards for summary counts (total events, unique users). Adding slicers for server_principal_name and object_name lets users drill into specific users’ or tables’ activity.<\/p>\n <\/div>\n
4. How do I monitor database security with Power BI?<\/h3>\n \n
Combine SQL Server Audit data with Power BI to build a security monitoring dashboard: create a scheduled refresh dataset that pulls the latest audit events daily; add visuals for failed logins, privileged account activity, DDL changes, and access to sensitive tables; set up Power BI alerts on calculated measures (e.g., if failed logins today > threshold, trigger an alert notification). For continuous monitoring, consider Power BI Embedded with automated refresh, or use Azure Sentinel for real-time security event analysis with Power BI as the reporting layer.<\/p>\n <\/div>\n <\/section>\n","protected":false},"excerpt":{"rendered":"
Connect Power BI Desktop to SQL Server Audit data to create interactive reports. Covers test database setup, DML\/DDL audit generation, Power BI data connections, and building tables, matrices, charts, and gauges from audit logs.…<\/p>\n","protected":false},"author":221841,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":true,"footnotes":""},"categories":[143528,143514],"tags":[68855],"coauthors":[6779],"class_list":["post-81849","post","type-post","status-publish","format-standard","hentry","category-bi-sql-server","category-data-privacy-and-protection","tag-sql-provision"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/81849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/221841"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=81849"}],"version-history":[{"count":6,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/81849\/revisions"}],"predecessor-version":[{"id":109869,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/81849\/revisions\/109869"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=81849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=81849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=81849"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=81849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-199.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-200.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-201.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-202.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-203.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-204.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-205.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2018\/11\/word-image-206.png\")
<\/figure>\n\n\n\n