Skip to content

Commit 6b77537

Browse files
MikeRayMSFTMikeRayMSFT
committed
Replace non-clustered with nonclustered
1 parent f9dbc18 commit 6b77537

72 files changed

Lines changed: 116 additions & 116 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎docs/2014/analysis-services/data-mining/cross-validation-analysis-services-data-mining.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -99,7 +99,7 @@ manager: craigg
9999

100100
The stored procedures are grouped by mining model type. One set of stored procedures works with clustering models only. The other set of stored procedures works with other mining models.
101101

102-
For each type of mining model, clustered or non-clustered, the stored procedures perform cross-validation in two separate phases.
102+
For each type of mining model, clustered or nonclustered, the stored procedures perform cross-validation in two separate phases.
103103

104104
**Partition data and generate metrics for partitions**
105105

‎docs/2014/analysis-services/multidimensional-models/understanding-incremental-generation.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -56,7 +56,7 @@ manager: craigg
5656
Adding a new object, such as a dimension, cube, or attribute.
5757
The Schema Generation Wizard adds underlying objects to which the new object is mapped.
5858

59-
If the Schema Generation Wizard cannot make the required change because of the presence of a user object in the subject area database (because the Database Engine returns an error), the Schema Generation Wizard fails and displays the error returned by the Database Engine. For example, if you create a primary key constraint or a non-clustered index on a table after the wizard generated the table, the Schema Generation Wizard does not drop that table because it did not create the constraint or the index.
59+
If the Schema Generation Wizard cannot make the required change because of the presence of a user object in the subject area database (because the Database Engine returns an error), the Schema Generation Wizard fails and displays the error returned by the Database Engine. For example, if you create a primary key constraint or a nonclustered index on a table after the wizard generated the table, the Schema Generation Wizard does not drop that table because it did not create the constraint or the index.
6060

6161
## Supporting Schema Changes
6262
When you change the properties of the tables or columns in the subject area database or in the associated data source view, the Schema Generation Wizard treats the changes as described in the following table.

‎docs/2014/analysis-services/multidimensional-models/understanding-the-database-schemas.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,7 @@ manager: craigg
6565
Relationships
6666
The wizard generates one relationship for each regular dimension relationship from the fact table to the dimension table's granularity attribute. If the granularity is based on the key attribute of the dimension table, the relationship is created in the database and in the data source view. If the granularity is based on another attribute, the relationship is created only in the data source view.
6767

68-
If you chose to generate indexes in the wizard, a non-clustered index is generated for each of these relationship columns.
68+
If you chose to generate indexes in the wizard, a nonclustered index is generated for each of these relationship columns.
6969

7070
Constraints
7171
Primary keys are not generated on fact tables.

‎docs/2014/relational-databases/blob/create-alter-and-drop-filetables.md‎

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -156,9 +156,9 @@ GO
156156
|||
157157
|-|-|
158158
|**Columns**|**Index type**|
159-
|[path_locator] ASC|Primary Key, non-clustered|
160-
|[parent_path_locator] ASC,<br /><br /> [name] ASC|Unique, non-clustered|
161-
|[stream_id] ASC|Unique, non-clustered|
159+
|[path_locator] ASC|Primary Key, nonclustered|
160+
|[parent_path_locator] ASC,<br /><br /> [name] ASC|Unique, nonclustered|
161+
|[stream_id] ASC|Unique, nonclustered|
162162

163163
**Constraints that are created when you create a new FileTable**
164164
When you create a new FileTable, the following system-defined constraints are also created:

‎docs/2014/relational-databases/event-classes/progress-report-online-index-operation-event-class.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,7 @@ manager: craigg
3232
|EndTime|`datetime`|Time at which the online index operation completed.|15|Yes|
3333
|EventClass|`int`|Type of event = 190.|27|No|
3434
|EventSequence|`int`|Sequence of a given event within the request.|51|No|
35-
|EventSubClass|`int`|Type of event subclass.<br /><br /> 1=Start<br /><br /> 2=Stage 1 execution begin<br /><br /> 3=Stage 1 execution end<br /><br /> 4=Stage 2 execution begin<br /><br /> 5=Stage 2 execution end<br /><br /> 6=Inserted row count<br /><br /> 7=Done<br /><br /> Stage 1 refers to the base object (clustered index or heap), or if the index operation involves one non-clustered index only. Stage 2 is used when an index build operation involves both the original rebuild plus additional non-clustered indexes. For example, if an object has a clustered index and several non-clustered indexes, 'rebuild all' would rebuild all indexes. The base object (the clustered index) is rebuilt in stage 1, and then all the non-clustered indexes are rebuilt in stage 2.|21|Yes|
35+
|EventSubClass|`int`|Type of event subclass.<br /><br /> 1=Start<br /><br /> 2=Stage 1 execution begin<br /><br /> 3=Stage 1 execution end<br /><br /> 4=Stage 2 execution begin<br /><br /> 5=Stage 2 execution end<br /><br /> 6=Inserted row count<br /><br /> 7=Done<br /><br /> Stage 1 refers to the base object (clustered index or heap), or if the index operation involves one nonclustered index only. Stage 2 is used when an index build operation involves both the original rebuild plus additional nonclustered indexes. For example, if an object has a clustered index and several nonclustered indexes, 'rebuild all' would rebuild all indexes. The base object (the clustered index) is rebuilt in stage 1, and then all the nonclustered indexes are rebuilt in stage 2.|21|Yes|
3636
|GroupID|`int`|ID of the workload group where the SQL Trace event fires.|66|Yes|
3737
|HostName|`nvarchar`|Name of the computer on which the client is running. This data column is populated if the client provides the host name. To determine the host name, use the HOST_NAME function.|8|Yes|
3838
|IndexID|`int`|ID for the index on the object affected by the event.|24|Yes|

‎docs/2014/relational-databases/in-memory-oltp/a-guide-to-query-processing-for-memory-optimized-tables.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -71,7 +71,7 @@ Query plan for join of disk-based tables.
7171

7272
- The rows from the Customer table are retrieved from the clustered index, which is the primary data structure and has the full table data.
7373

74-
- Data from the Order table is retrieved using the non-clustered index on the CustomerID column. This index contains both the CustomerID column, which is used for the join, and the primary key column OrderID, which is returned to the user. Returning additional columns from the Order table would require lookups in the clustered index for the Order table.
74+
- Data from the Order table is retrieved using the nonclustered index on the CustomerID column. This index contains both the CustomerID column, which is used for the join, and the primary key column OrderID, which is returned to the user. Returning additional columns from the Order table would require lookups in the clustered index for the Order table.
7575

7676
- The logical operator `Inner Join` is implemented by the physical operator `Merge Join`. The other physical join types are `Nested Loops` and `Hash Join`. The `Merge Join` operator takes advantage of the fact that both indexes are sorted on the join column CustomerID.
7777

@@ -108,7 +108,7 @@ SQL Server query processing pipeline.
108108

109109
6. Access Methods retrieves the rows from the index and data pages in the buffer pool and loads pages from disk into the buffer pool as needed.
110110

111-
For the first example query, the execution engine requests rows in the clustered index on Customer and the non-clustered index on Order from Access Methods. Access Methods traverses the B-tree index structures to retrieve the requested rows. In this case all rows are retrieved as the plan calls for full index scans.
111+
For the first example query, the execution engine requests rows in the clustered index on Customer and the nonclustered index on Order from Access Methods. Access Methods traverses the B-tree index structures to retrieve the requested rows. In this case all rows are retrieved as the plan calls for full index scans.
112112

113113
## Interpreted [!INCLUDE[tsql](../../../includes/tsql-md.md)] Access to Memory-Optimized Tables
114114
[!INCLUDE[tsql](../../../includes/tsql-md.md)] ad hoc batches and stored procedures are also referred to as interpreted [!INCLUDE[tsql](../../../includes/tsql-md.md)]. Interpreted refers to the fact that the query plan is interpreted by the query execution engine for each operator in the query plan. The execution engine reads the operator and its parameters and performs the operation.

‎docs/2014/relational-databases/in-memory-oltp/estimate-memory-requirements-for-memory-optimized-tables.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -121,19 +121,19 @@ SELECT COUNT(DISTINCT [Col2])
121121

122122
Since we have three hash indexes, the memory needed for the hash indexes is 3 * 64MB = 192MB.
123123

124-
**Memory for non-clustered indexes**
124+
**Memory for nonclustered indexes**
125125

126126
Nonclustered indexes are implemented as BTrees with the inner nodes containing the index value and pointers to subsequent nodes. Leaf nodes contain the index value and a pointer to the table row in memory.
127127

128-
Unlike hash indexes, non-clustered indexes do not have a fixed bucket size. The index grows and shrinks dynamically with the data.
128+
Unlike hash indexes, nonclustered indexes do not have a fixed bucket size. The index grows and shrinks dynamically with the data.
129129

130-
Memory needed by non-clustered indexes can be computed as follows:
130+
Memory needed by nonclustered indexes can be computed as follows:
131131

132132
- **Memory allocated to non-leaf nodes**
133133
For a typical configuration, the memory allocated to non-leaf nodes is a small percentage of the overall memory taken by the index. This is so small it can safely be ignored.
134134

135135
- **Memory for leaf nodes**
136-
The leaf nodes have one row for each unique key in the table that points to the data rows with that unique key. If you have multiple rows with the same key (i.e., you have a non-unique non-clustered index), there is only one row in the index leaf node that points to one of the rows with the other rows linked to each other. Thus, the total memory required can be approximated by:
136+
The leaf nodes have one row for each unique key in the table that points to the data rows with that unique key. If you have multiple rows with the same key (i.e., you have a non-unique nonclustered index), there is only one row in the index leaf node that points to one of the rows with the other rows linked to each other. Thus, the total memory required can be approximated by:
137137
memoryForNonClusteredIndex = (pointerSize + sum(keyColumnDataTypeSizes)) * rowsWithUniqueKeys
138138

139139
Nonclustered indexes are best when used for range lookups, as exemplified by the following query:

‎docs/2014/relational-databases/indexes/columnstore-indexes-described.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -122,7 +122,7 @@ manager: craigg
122122
![Column segment](../../database-engine/media/sql-server-pdw-columnstore-columnsegment.gif "Column segment")
123123

124124
nonclustered columnstore index
125-
A *nonclustered columnstore index* is a read-only index created on an existing clustered index or heap table. It contains a copy of a subset of columns, up to and including all of the columns in the table.. The table is read-only while it contains a non-clustered columnstore index.
125+
A *nonclustered columnstore index* is a read-only index created on an existing clustered index or heap table. It contains a copy of a subset of columns, up to and including all of the columns in the table.. The table is read-only while it contains a nonclustered columnstore index.
126126

127127
A nonclustered columnstore index provides a way to have a columnstore index for running analysis queries while at the same time performing read-only operations on the original table.
128128

‎docs/2014/relational-databases/indexes/reorganize-and-rebuild-indexes.md‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -81,23 +81,23 @@ manager: craigg
8181
<sup>1</sup> Rebuilding an index can be executed online or offline. Reorganizing an index is always executed online. To achieve availability similar to the reorganize option, you should rebuild indexes online.
8282

8383
> [!TIP]
84-
> These values provide a rough guideline for determining the point at which you should switch between `ALTER INDEX REORGANIZE` and `ALTER INDEX REBUILD`. However, the actual values may vary from case to case. It is important that you experiment to determine the best threshold for your environment. For example, if a given index is used mainly for scan operations, removing fragmentation can improve performance of these operations. The performance benefit is less noticeable for indexes that are used primarily for seek operations. Similarly, removing fragmentation in a heap (a table with no clustered index) is especially useful for non-clustered index scan operations, but has little effect in lookup operations.
84+
> These values provide a rough guideline for determining the point at which you should switch between `ALTER INDEX REORGANIZE` and `ALTER INDEX REBUILD`. However, the actual values may vary from case to case. It is important that you experiment to determine the best threshold for your environment. For example, if a given index is used mainly for scan operations, removing fragmentation can improve performance of these operations. The performance benefit is less noticeable for indexes that are used primarily for seek operations. Similarly, removing fragmentation in a heap (a table with no clustered index) is especially useful for nonclustered index scan operations, but has little effect in lookup operations.
8585
8686
Very low levels of fragmentation (less than 5 percent) should typically not be addressed by either of these commands, because the benefit from removing such a small amount of fragmentation is almost always vastly outweighed by the cost of reorganizing or rebuilding the index.
8787

8888
> [!NOTE]
8989
> Rebuilding or reorganizing small indexes often does not reduce fragmentation. The pages of small indexes are sometimes stored on mixed extents. Mixed extents are shared by up to eight objects, so the fragmentation in a small index might not be reduced after reorganizing or rebuilding it.
9090
9191
### Index defragmentation considerations
92-
Under certain conditions, rebuilding a clustered index will automatically rebuild any non-clustered index that reference the clustering key, if the physical or logical identifiers contained in the non-clustered index records needs to change.
92+
Under certain conditions, rebuilding a clustered index will automatically rebuild any nonclustered index that reference the clustering key, if the physical or logical identifiers contained in the nonclustered index records needs to change.
9393

94-
Scenarios that force all non-clustered indexes to be automatically rebuilt on a table:
94+
Scenarios that force all nonclustered indexes to be automatically rebuilt on a table:
9595

9696
- Creating a clustered index on a table
9797
- Removing a clustered index, causing the table to be stored as a heap
9898
- Changing the clustering key to include or exclude columns
9999

100-
Scenarios that do not require all non-clustered indexes to be automatically rebuilt on a table:
100+
Scenarios that do not require all nonclustered indexes to be automatically rebuilt on a table:
101101

102102
- Rebuilding a unique clustered index
103103
- Rebuilding a non-unique clustered index

‎docs/2014/relational-databases/performance/view-and-work-with-the-output-from-the-database-engine-tuning-advisor.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -276,7 +276,7 @@ manager: craigg
276276
The index or view affected by the recommendation. The icon in this column reflects the recommendation to drop or add the **Target of Recommendation**.
277277
278278
**Details**
279-
A description of the **Target of Recommendation**. Possible values include clustered, indexed view, or blank indicating a non-clustered index. Also indicates whether the index is unique.
279+
A description of the **Target of Recommendation**. Possible values include clustered, indexed view, or blank indicating a nonclustered index. Also indicates whether the index is unique.
280280
281281
**Partition Scheme**
282282
The partition scheme is provided in this column if partitioning is recommended.

0 commit comments

Comments
 (0)