Updated Wiki: MiracleDB - Indexing component

Indexing - object descriptions
When you have installed the MiracleDB - Indexing component, you have these objects of interests:

• idx.Settings
  • This is a table containing different settings used by the index maintenance procedures. The different settings have default values set by us, but you are welcome to change to meet your needs.
• idx.CollectData
  • This is a stored procedure which scans all databases on your instance, and looks for indexes exceeding the defined fragmentation levels in the idx.Settings table. The procedure generates the rebuild or reorganize scripts, and queues them for execution.
• base.ExecuteTasks
  • This is a stored procedure which executes all the rebuild/reorganize scripts that were collected by idx.CollectData and queued for execution.
• idx.MaintenanceStats
  • This is a view that gives you an overview over how much time you have spend per day on index maintenance tasks. It tells you how many indexes have been rebuild/reorganized, and how long it took.
• idx.MaintenanceLog
  • This is a view that gives you all the detailed information about each index rebuild/reorganize task.
• idx.MissingIndexes
  • This is a view that gives you a list of all the missing indexes reported by the SQL Server itself.
• idx.IndexUsage
  • This is a stored procedure that shows you the actual usage (scans, lookups, inserts) of each index on all tables in all databases.

Examples
For automatic index maintenance, you need to schedule these two via a SQL Server Agent job:

EXEC idx.CollectData
EXEC base.ExecuteTasks @ScheduleType = 'Index maintenance'

 We recommend that you schedule this on a daily basis.

When the above maintenance job has been run, you can have a look at some stats with these:

SELECT * FROM idx.MaintenanceStatus

and

SELECT * FROM idx.MaintenanceLog

If you would like to see if the SQL Server has reported any missing indexes, you can use this:

SELECT * FROM idx.MissingIndexes

What you should look for, is indexes with a high value in either user_seeks or user_scans. This _could_ indicate that you should consider building the index. The T-SQL script to create the index is provided for you in the CreateIndexStmt column.

If you would like to see how often your existing indexes are being used, you can run this:

EXEC idx.IndexUsage --Shows stats for all databases

EXEC idx.IndexUsage @DatabaseName = '[MyDatabase]'--Only shows stats for the database named [MyDatabase]

EXEC idx.IndexUsage @DatabaseName = '[MyDatabase]', @SchemaName = '[MySchema]', @TableName = '[MyTable]'--Only shows stats for the indexes on [MySchema].[MyTable] in [MyDatabase]

EXEC idx.IndexUsage @DatabaseName = '[MyDatabase]', @TableName = '[MyTable]'--@SchemaName is optional - it will default to [dbo]. This only shows stats for the indexes on [dbo].[MyTable] in [MyDatabase]


GO

What you should look for are indexes that are _not_ primary keys which have a low range_scan_count as well as a low singleton_lookup_count. Be aware, that these stats are reset when the SQL Server service is restarte