Skip to content

Commit a24aef5

Browse files
BrentOzarBrentOzar
authored
Merge pull request BrentOzarULTD#1605 from BrentOzarULTD/issue_1604_InMemoryOLTP_docs
BrentOzarULTD#1604 readme & license for in-memory OLTP
2 parents 1b2e055 + 8026c8b commit a24aef5

File tree

2 files changed

+82
-59
lines changed

2 files changed

+82
-59
lines changed

‎LICENSE.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,9 +12,12 @@ https://github.com/GregWhiteDBA/MSSQLAutoRestore
1212
All other copyrights for DatabaseRestore are held by Brent Ozar Unlimited, 2017
1313
as described below.
1414

15+
Copyright for sp_BlitzInMemoryOLTP are held by Ned Otter and Konstantin
16+
Taranov as part of project sqlserver-kit and are provided under the MIT license:
17+
https://github.com/ktaranov/sqlserver-kit
1518

1619

17-
Copyright (c) 2017 Brent Ozar Unlimited
20+
Copyright (c) 2018 Brent Ozar Unlimited
1821

1922
Permission is hereby granted, free of charge, to any person obtaining a copy
2023
of this software and associated documentation files (the "Software"), to deal

‎README.md

Lines changed: 78 additions & 58 deletions
Original file line numberDiff line numberDiff line change
@@ -7,18 +7,21 @@
77

88
Navigation
99
- [How to Get Support](#how-to-get-support)
10-
- [sp_Blitz: Overall Health Check](#sp_blitz-overall-health-check)
11-
- [Advanced sp_Blitz Parameters](#advanced-sp_blitz-parameters)
12-
- [Writing sp_Blitz Output to a Table](#writing-sp_blitz-output-to-a-table)
13-
- [Skipping Checks or Databases](#skipping-checks-or-databases)
14-
- [sp_BlitzCache: Find the Most Resource-Intensive Queries](#sp_blitzcache-find-the-most-resource-intensive-queries)
15-
- [Advanced sp_BlitzCache Parameters](#advanced-sp_blitzcache-parameters)
16-
- [sp_BlitzIndex: Tune Your Indexes](#sp_blitzindex-tune-your-indexes)
17-
- [Advanced sp_BlitzIndex Parameters](#advanced-sp_blitzindex-parameters)
18-
- [sp_BlitzFirst: Real-Time Performance Advice](#sp_blitzfirst-real-time-performance-advice)
19-
- [sp_BlitzWho: What Queries are Running Now](#sp_blitzwho-what-queries-are-running-now)
20-
- [sp_BlitzQueryStore: Like BlitzCache, for Query Store](#sp_blitzquerystore-query-store-sale)
21-
- [sp_BlitzLock: Deadlock Analysis](#sp_blitzlock-deadlock-analysis)
10+
- Common Scripts:
11+
- [sp_Blitz: Overall Health Check](#sp_blitz-overall-health-check)
12+
- [Advanced sp_Blitz Parameters](#advanced-sp_blitz-parameters)
13+
- [Writing sp_Blitz Output to a Table](#writing-sp_blitz-output-to-a-table)
14+
- [Skipping Checks or Databases](#skipping-checks-or-databases)
15+
- [sp_BlitzCache: Find the Most Resource-Intensive Queries](#sp_blitzcache-find-the-most-resource-intensive-queries)
16+
- [Advanced sp_BlitzCache Parameters](#advanced-sp_blitzcache-parameters)
17+
- [sp_BlitzFirst: Real-Time Performance Advice](#sp_blitzfirst-real-time-performance-advice)
18+
- [sp_BlitzIndex: Tune Your Indexes](#sp_blitzindex-tune-your-indexes)
19+
- [Advanced sp_BlitzIndex Parameters](#advanced-sp_blitzindex-parameters)
20+
- Performance Tuning:
21+
- [sp_BlitzInMemoryOLTP: Hekaton Analysis](#sp_blitzinmemoryoltp-hekaton-analysis)
22+
- [sp_BlitzLock: Deadlock Analysis](#sp_blitzlock-deadlock-analysis)
23+
- [sp_BlitzQueryStore: Like BlitzCache, for Query Store](#sp_blitzquerystore-query-store-sale)
24+
- [sp_BlitzWho: What Queries are Running Now](#sp_blitzwho-what-queries-are-running-now)
2225
- Backups and Restores:
2326
- [sp_BlitzBackups: How Much Data Could You Lose](#sp_blitzbackups-how-much-data-could-you-lose)
2427
- [sp_AllNightLog: Back Up Faster to Lose Less Data](#sp_allnightlog-back-up-faster-to-lose-less-data)
@@ -172,36 +175,6 @@ In addition to the [parameters common to many of the stored procedures](#paramet
172175

173176
[*Back to top*](#header1)
174177

175-
176-
## sp_BlitzIndex: Tune Your Indexes
177-
178-
SQL Server tracks your indexes: how big they are, how often they change, whether they're used to make queries go faster, and which indexes you should consider adding. The results columns are fairly self-explanatory.
179-
180-
By default, sp_BlitzIndex analyzes the indexes of the database you're in (your current context.)
181-
182-
Common parameters include:
183-
184-
* @DatabaseName - if you want to analyze a specific database
185-
* @SchemaName, @TableName - if you pass in these, sp_BlitzIndex does a deeper-dive analysis of just one table. You get several result sets back describing more information about the table's current indexes, foreign key relationships, missing indexes, and fields in the table.
186-
* @GetAllDatabases = 1 - slower, but lets you analyze all the databases at once, up to 50. If you want more than 50 databases, you also have to pass in @BringThePain = 1.
187-
* @ThresholdMB = 250 - by default, we only analyze objects over 250MB because you're busy.
188-
* @Mode = 0 (default) - get different data with 0=Diagnose, 1=Summarize, 2=Index Usage Detail, 3=Missing Index Detail, 4=Diagnose Details.
189-
190-
191-
[*Back to top*](#header1)
192-
193-
### Advanced sp_BlitzIndex Parameters
194-
195-
In addition to the [parameters common to many of the stored procedures](#parameters-common-to-many-of-the-stored-procedures), here are the ones specific to sp_BlitzIndex:
196-
197-
* @SkipPartitions = 1 - add this if you want to analyze large partitioned tables. We skip these by default for performance reasons.
198-
* @SkipStatistics = 0 - right now, by default, we skip statistics analysis because we've had some performance issues on this.
199-
* @Filter = 0 (default) - 1=No low-usage warnings for objects with 0 reads. 2=Only warn for objects >= 500MB
200-
201-
202-
[*Back to top*](#header1)
203-
204-
205178
## sp_BlitzFirst: Real-Time Performance Advice
206179

207180
When performance emergencies strike, this should be the first stored proc in the kit you run.
@@ -255,15 +228,71 @@ Optionally, you can also pass in:
255228

256229
[*Back to top*](#header1)
257230

231+
## sp_BlitzIndex: Tune Your Indexes
258232

259-
## sp_BlitzWho: What Queries are Running Now
233+
SQL Server tracks your indexes: how big they are, how often they change, whether they're used to make queries go faster, and which indexes you should consider adding. The results columns are fairly self-explanatory.
260234

261-
This is like sp_who, except it goes into way, way, way more details.
235+
By default, sp_BlitzIndex analyzes the indexes of the database you're in (your current context.)
236+
237+
Common parameters include:
238+
239+
* @DatabaseName - if you want to analyze a specific database
240+
* @SchemaName, @TableName - if you pass in these, sp_BlitzIndex does a deeper-dive analysis of just one table. You get several result sets back describing more information about the table's current indexes, foreign key relationships, missing indexes, and fields in the table.
241+
* @GetAllDatabases = 1 - slower, but lets you analyze all the databases at once, up to 50. If you want more than 50 databases, you also have to pass in @BringThePain = 1.
242+
* @ThresholdMB = 250 - by default, we only analyze objects over 250MB because you're busy.
243+
* @Mode = 0 (default) - get different data with 0=Diagnose, 1=Summarize, 2=Index Usage Detail, 3=Missing Index Detail, 4=Diagnose Details.
244+
245+
246+
[*Back to top*](#header1)
247+
248+
### Advanced sp_BlitzIndex Parameters
249+
250+
In addition to the [parameters common to many of the stored procedures](#parameters-common-to-many-of-the-stored-procedures), here are the ones specific to sp_BlitzIndex:
251+
252+
* @SkipPartitions = 1 - add this if you want to analyze large partitioned tables. We skip these by default for performance reasons.
253+
* @SkipStatistics = 0 - right now, by default, we skip statistics analysis because we've had some performance issues on this.
254+
* @Filter = 0 (default) - 1=No low-usage warnings for objects with 0 reads. 2=Only warn for objects >= 500MB
255+
256+
257+
[*Back to top*](#header1)
258+
259+
260+
## sp_BlitzInMemoryOLTP: Hekaton Analysis
261+
262+
Examines your usage of In-Memory OLTP tables. Parameters you can use:
263+
264+
* @instanceLevelOnly BIT: This flag determines whether or not to simply report on the server-level environment (if applicable, i.e. there is no server-level environment for Azure SQL Database). With this parameter, memory-optimized databases are ignored. If you specify @instanceLevelOnly and a database name, the database name is ignored.
265+
* @dbName NVARCHAR(4000) = N'ALL' - If you don't specify a database name, then sp_BlitzInMemoryOLTP reports on all memory-optimized databases within the instance that it executes in, or in the case of Azure SQL Database, the database that you provisioned. This is because the default for the @dbName parameter is N'ALL'.
266+
* @tableName NVARCHAR(4000) = NULL
267+
* @debug BIT
268+
269+
To interpret the output of this stored procedure, read [Ned Otter's sp_BlitzInMemoryOLTP documentation](http://nedotter.com/archive/2018/06/new-kid-on-the-block-sp_blitzinmemoryoltp/).
270+
271+
272+
[*Back to top*](#header1)
273+
274+
275+
276+
## sp_BlitzLock: Deadlock Analysis
277+
278+
Checks either the System Health session or a specific Extended Event session that captures deadlocks and parses out all the XML for you.
279+
280+
Parameters you can use:
281+
* @Top: Use if you want to limit the number of deadlocks to return. This is ordered by event date ascending.
282+
* @DatabaseName: If you want to filter to a specific database
283+
* @StartDate: The date you want to start searching on.
284+
* @EndDate: The date you want to stop searching on.
285+
* @ObjectName: If you want to filter to a specific table. The object name has to be fully qualified 'Database.Schema.Table'
286+
* @StoredProcName: If you want to search for a single stored proc.
287+
* @AppName: If you want to filter to a specific application.
288+
* @HostName: If you want to filter to a specific host.
289+
* @LoginName: If you want to filter to a specific login.
290+
* @EventSessionPath: If you want to point this at an XE session rather than the system health session.
262291

263-
It's designed for query tuners, so it includes things like memory grants, degrees of parallelism, and execution plans.
264292

265293
[*Back to top*](#header1)
266294

295+
267296
## sp_BlitzQueryStore: Query Store Sale
268297

269298
Analyzes data in Query Store schema (2016+ only) in many similar ways to what sp_BlitzCache does for the plan cache.
@@ -286,25 +315,16 @@ Analyzes data in Query Store schema (2016+ only) in many similar ways to what sp
286315

287316
[*Back to top*](#header1)
288317

289-
## sp_BlitzLock: Deadlock Analysis
290318

291-
Checks either the System Health session or a specific Extended Event session that captures deadlocks and parses out all the XML for you.
319+
## sp_BlitzWho: What Queries are Running Now
292320

293-
Variables you can use:
294-
* @Top: Use if you want to limit the number of deadlocks to return. This is ordered by event date ascending.
295-
* @DatabaseName: If you want to filter to a specific database
296-
* @StartDate: The date you want to start searching on.
297-
* @EndDate: The date you want to stop searching on.
298-
* @ObjectName: If you want to filter to a specific table. The object name has to be fully qualified 'Database.Schema.Table'
299-
* @StoredProcName: If you want to search for a single stored proc.
300-
* @AppName: If you want to filter to a specific application.
301-
* @HostName: If you want to filter to a specific host.
302-
* @LoginName: If you want to filter to a specific login.
303-
* @EventSessionPath: If you want to point this at an XE session rather than the system health session.
321+
This is like sp_who, except it goes into way, way, way more details.
304322

323+
It's designed for query tuners, so it includes things like memory grants, degrees of parallelism, and execution plans.
305324

306325
[*Back to top*](#header1)
307326

327+
308328
## sp_BlitzBackups: How Much Data Could You Lose
309329

310330
Checks your backups and reports estimated RPO and RTO based on historical data in msdb, or a centralized location for [msdb].dbo.backupset.

0 commit comments

Comments
 (0)