RecoveryModelCurrent varchar This is the recovery model of the database before the reindex operation began. RecoveryModelReindex varchar This is the recovery model of the database during the operation. The recovery model can be changed in the IndexSettingsDB table. SQLVersion varchar The current version of SQL Server. SQLEdition varchar The current edition of SQL Server. DBPreCode nvarchar Any database-level code that was run before Minion Reindex processed any tables. DBPostCode nvarchar Any database-level code that was run after Minion Reindex processed all the tables. DBPreCodeBeginDateTime datetime Date and time the precode started. DBPreCodeEndDateTime datetime Date and time the precode ended. DBPostCodeBeginDateTime datetime Date and time the postcode started. DBPostCodeEndDateTime datetime Date and time the postcode ended. DBPreCodeRunTimeInSecs int How many seconds the precode took. DBPostCodeRunTimeInSecs int How many seconds the postcode took. ExecutionFinishTime datetime Date and time the entire database reindex operation finished. ExecutionRunTimeInSecs int How many seconds the database reindex operation took. Discussion: Each row contains the database name, the start and end time of the index maintenance event, and much more. Minion.IndexMaintLogDetails Keeps a record of individual index maintenance activities. It contains one time-stamped row for each individual index operation (e.g., a single index rebuild). Name Type Description ID int Primary key row identifier. ExecutionDateTime datetime Date and time the entire reindex operation took place. If the job were started through IndexMaintMaster then all databases in that run have the same ExecutionDateTime. If the job was run manually from Minion.IndexMaintDB, then this value will only be for this database. It will still have a matching row in the Minion.IndexMaintLog table. Status varchar Current status of the index operation. If Live Insight is being used the status updates will appear here. When finished, this column will either read or ERROR: error ‘Complete’ ‘FATAL message’. The one exception is when the job has been run with PrepOnly = 1.
RecoveryModelCurrent varchar This is the recovery model of the database before the reindex operation began. RecoveryModelReindex varchar This is the recovery model of the database during the operation. The recovery model can be changed in the IndexSettingsDB table. SQLVersion varchar The current version of SQL Server. SQLEdition varchar The current edition of SQL Server. DBPreCode nvarchar Any database-level code that was run before Minion Reindex processed any tables. DBPostCode nvarchar Any database-level code that was run after Minion Reindex processed all the tables. DBPreCodeBeginDateTime datetime Date and time the precode started. DBPreCodeEndDateTime datetime Date and time the precode ended. DBPostCodeBeginDateTime datetime Date and time the postcode started. DBPostCodeEndDateTime datetime Date and time the postcode ended. DBPreCodeRunTimeInSecs int How many seconds the precode took. DBPostCodeRunTimeInSecs int How many seconds the postcode took. ExecutionFinishTime datetime Date and time the entire database reindex operation finished. ExecutionRunTimeInSecs int How many seconds the database reindex operation took. Discussion: Each row contains the database name, the start and end time of the index maintenance event, and much more. Minion.IndexMaintLogDetails Keeps a record of individual index maintenance activities. It contains one time-stamped row for each individual index operation (e.g., a single index rebuild). Name Type Description ID int Primary key row identifier. ExecutionDateTime datetime Date and time the entire reindex operation took place. If the job were started through IndexMaintMaster then all databases in that run have the same ExecutionDateTime. If the job was run manually from Minion.IndexMaintDB, then this value will only be for this database. It will still have a matching row in the Minion.IndexMaintLog table. Status varchar Current status of the index operation. If Live Insight is being used the status updates will appear here. When finished, this column will either read ‘Complete’ or ‘FATAL ERROR: error message’. The one exception is when the job has been run with PrepOnly = 1.