You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The basic mechanism to recover or restore a database with memory-optimized tables is similar to databases with only disk-based tables. But unlike disk-based tables, memory-optimized tables must be loaded into memory before database is available for user access. This adds a new step in the database recovery.
25
+
The basic mechanism to recover or restore a database that uses memory-optimized tables is similar to the mechanism for a database that uses only disk-based tables. But unlike disk-based tables, memory-optimized tables must be loaded into memory before the database is available for user access. This requirement adds a new step in the database recovery.
26
26
27
-
If the server does not have enough available memory, database recovery will fail and the database will be marked as suspect. To resolve this issue, see [Resolve Out Of Memory issues](resolve-out-of-memory-issues.md).
27
+
If the server does not have enough available memory, database recovery fails and the database is marked as suspect. To resolve this problem, see [Resolve out-of-memory issues](resolve-out-of-memory-issues.md).
28
28
29
-
During recovery or restore operations, the In-Memory OLTP engine reads data and delta files for loading into physical memory. The load time is determined by:
29
+
## Factors that affect load time
30
+
During recovery or restore operations, the In-Memory OLTP engine reads data and delta files for loading into physical memory. The load time is determined by:
30
31
31
32
- The amount of data to load.
32
33
33
34
- Sequential I/O bandwidth.
34
35
35
-
-Degree of parallelism, determined by number of file containers and processor cores.
36
+
-The degree of parallelism, determined by the number of file containers and processor cores.
36
37
37
-
- The amount of log records in the active portion of the log that need to be redone.
38
-
39
-
When the [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] restarts, each database goes through a recovery phase that consists of the following three phases:
38
+
- The number of log records in the active portion of the log that need to be redone.
39
+
40
+
## Phases of recovery
41
+
When [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] restarts, each database goes through a recovery process that consists of three phases:
40
42
41
-
1.The analysis phase. During this phase, a pass is made on the active transaction logs to detect committed and uncommitted transactions. The In-Memory OLTP engine identifies the checkpoint to load and preloads its system table log entries. It will also process some file allocation log records.
43
+
1.**Analysis**. In this phase, a pass is made on the active transaction logs to detect committed and uncommitted transactions. The In-Memory OLTP engine identifies the checkpoint to load and preloads its system table log entries. It also processes some file allocation log records.
42
44
43
-
2.The redo phase. This phase is run concurrently on both disk-based and memory-optimized tables.
45
+
2.**Redo**. This phase is run concurrently on both disk-based and memory-optimized tables.
44
46
45
-
For disk-based tables, the database is moved to the current point in time and acquires locks taken by uncommitted transactions.
47
+
- For disk-based tables, the database is moved to the current point in time and acquires locks taken by uncommitted transactions.
46
48
47
-
For memory-optimized tables, data from the data and delta file pairs are loaded into memory and then update the data with the active transaction log based on the last durable checkpoint.
49
+
- For memory-optimized tables, data from the data and delta file pairs are loaded into memory. Data is then updated with the active transaction log based on the last durable checkpoint.
48
50
49
-
When the above operations on disk-based and memory-optimized tables are complete, the database is available for access.
51
+
When the preceding operations on disk-based and memory-optimized tables are complete, the database is available for access.
50
52
51
-
3.The undo phase. In this phase, the uncommitted transactions are rolled back.
53
+
3.**Undo**. In this phase, the uncommitted transactions are rolled back.
52
54
53
-
Loading memory-optimized tables into memory can affect performance of the recovery time objective (RTO). To improve the load time of memory-optimized data from data and delta files, the In-Memory OLTP engine loads the data/delta files in parallel as follows:
55
+
## Process for improving load time
56
+
Loading memory-optimized tables into memory can affect performance of the recovery time objective (RTO). To improve the load time of memory-optimized data from data and delta files, the In-Memory OLTP engine loads the data/delta files in parallel as follows:
54
57
55
-
- Creating a Delta Map Filter. Delta files store references to the deleted rows. One thread per container reads the delta files and creates a delta map filter. (A memoryoptimized data filegroup can have one or more containers.)
58
+
-**Creating a delta map filter**. Delta files store references to the deleted rows. One thread per container reads the delta files and creates a delta map filter. (A memory-optimized data file group can have one or more containers.)
56
59
57
-
- Streaming the data files. Once the delta-map filter is created, data files are read using as many threads as there are logical CPUs. Each thread reading the data file reads the data rows, checks the associated delta map and only inserts the row into table if this row has not been marked deleted. This part of recovery can be CPU bound in some cases as noted below.
60
+
-**Streaming the data files**. After the deltamap filter is created, data files are read by as many threads as there are logical CPUs. Each thread reads the data rows, checks the associated delta map, and inserts a row into the table only if the row has not been marked deleted. This part of recovery can be CPU bound in some cases, as noted in this diagram:
![Data streaming to memory-optimized tables](../../relational-databases/in-memory-oltp/media/memory-optimized-tables.gif"Data streaming to memory-optimized tables")
60
63
61
-
Memory-optimized tables can generally be loaded into memory at the speed of I/O but there are cases when loading data rows into memory will be slower. Specific cases are:
64
+
## Specific cases of slow load times
65
+
Memory-optimized tables can generally be loaded into memory at the speed of I/O, but loading data rows into memory is sometimes slower. Specific cases are:
62
66
63
-
- Low bucket count for hash index can lead to excessive collision causing data row inserts to be slower. This generally results in very high CPU utilization throughout, and especially towards the end of recovery. If you configured the hash index correctly, it should not impact the recovery time.
67
+
- Low bucket count for a hash index can lead to excessive collision, which causes data row inserts to be slower. This generally results in high CPU utilization throughout, and especially toward the end of recovery. If you configured the hash index correctly, it should not affect the recovery time.
64
68
65
-
- Large memory-optimized tables with one or more nonclustered indexes, unlike a hash index whose bucket count is sized at create time, the nonclustered indexes grow dynamically, resulting in high CPU utilization.
69
+
- Large memory-optimized tables with one or more nonclustered indexes can cause high CPU utilization. Unlike a hash index whose bucket count is sized at create time, nonclustered indexes grow dynamically.
66
70
67
-
## See Also
71
+
## See also
68
72
[Backup, Restore, and Recovery of Memory-Optimized Tables](http://msdn.microsoft.com/library/3f083347-0fbb-4b19-a6fb-1818d545e281)
0 commit comments