Exportera (0) Skriv ut
Visa allt
EN
Det här innehållet finns inte tillgängligt på ditt språk men här finns den engelska versionen,

sys.federation_distribution_history (Azure SQL Database)

Updated: November 21, 2014

This topic is OBSOLETE. You can find the most current version in the SQL 14 Transact-SQL Reference. See Sys.federation_distribution_history.

ImportantImportant
The current implementation of Federations will be retired with Web and Business service tiers. Consider deploying custom sharding solutions to maximize scalability, flexibility, and performance. For more information about custom sharding, see Scaling Out Azure SQL Databases.

Returns historical information about the distribution type and data types used by a federation. Sys.federation_distribution_history is specific to Microsoft Azure SQL Database and is not supported in on-premises SQL Server.

 

Columns Data type Description

federation_id

int

Unique identifier for the federation

distribution_name

sysname

Name identifier for the federation key

distribution_type

nvarchar(60)

RANGE

system_type_id

tinyint

The system data type id for federation data types.

max_length

smallint

Maximum length (in bytes) of the column.

-1 = Column data type is varchar(max), nvarchar(max), varbinary(max), or xml.

For text columns, the max_length value will be 16 or the value set by sp_tableoption ‘text in row’.

precision

tinyint

Precision o fthe column if numeric-based; otherwise, 0.

scale

tinyint

Scale of the column if numeric-based; otherwise, 0.

collation_name

sysname

Name o fthe collation of the column if character-based; otherwise, NULL.

user_type_id

int

ID of the type. For system data types, user_type_id = system_type_id.

boundary_value_in_high

bit

For range partitioning. Will always contain a value of 1.

drop_date

datetimeoffset

Datetime the federation was dropped

create_date

datetimeoffset

Datetime the federation was created

This view requires VIEW DATABASE STATE permission.

Cleanup of historical data is performed automatically every two weeks. Cleanup is triggered by operations that update the log information. This can result in historical information being retained for longer than two weeks if no new operations have been performed.

The drop_date and create_date columns are populated on the completion of an operation. For asynchronous operations these fields are populated when the operation completes fully, not when the command returns.

The value for federation_id is not reused within a single root database.

Visa:
© 2014 Microsoft