【问题标题】:force replication of replicated tables强制复制已复制的表
【发布时间】:2019-05-05 06:48:56
【问题描述】:

我的一些表是 REPLICATE 类型的。在我开始查询我的数据之前,我会实际复制这些表(而不是挂起)。这将帮助我避免数据移动。

我有一个脚本,我在网上找到了它,它循环运行并在所有设置为复制的表上执行 SELECT TOP 1,但有时脚本会运行数小时。即使您从 foo 执行 SELECT TOP 1,服务器有时也可能不会触发复制。

如何强制 SQL 数据仓库完成复制?

脚本如下所示:

begin

CREATE TABLE #tbl
WITH
( DISTRIBUTION = ROUND_ROBIN
)
AS
SELECT 
       ROW_NUMBER() OVER(
       ORDER BY
                (
                    SELECT 
                           NULL
                )) AS                                            Sequence
     , CONCAT('SELECT TOP(1) * FROM ', s.name, '.', t.[name]) AS sql_code
FROM sys.pdw_replicated_table_cache_state AS p
JOIN sys.tables AS t
         ON t.object_id = p.object_id
JOIN sys.schemas AS s
         ON t.schema_id = s.schema_id
WHERE p.[state] = 'NotReady';

DECLARE @nbr_statements INT=
        (
            SELECT 
                   COUNT(*)
            FROM #tbl
        ), @i INT= 1;

    WHILE @i <= @nbr_statements

        BEGIN
        DECLARE @sql_code NVARCHAR(4000)= (SELECT 
        sql_code
        FROM #tbl
        WHERE Sequence = @i);
        EXEC sp_executesql @sql_code;
        SET @i+=1;
        END;
        DROP TABLE #tbl;
        SET @i = 0;
        WHILE
              (
                  SELECT TOP (1) 
                         p.[state]
                  FROM sys.pdw_replicated_table_cache_state AS p
                  JOIN sys.tables AS t
                           ON t.object_id = p.object_id
                  JOIN sys.schemas AS s
                           ON t.schema_id = s.schema_id
                  WHERE p.[state] = 'NotReady'
              ) = 'NotReady'
            BEGIN
                IF @i % 100 = 0
                    BEGIN
                        RAISERROR('Replication in progress' , 0, 0) WITH NOWAIT;
                    END;
                SET @i = @i + 1;
            END;

END

【问题讨论】:

    标签: azure sql-data-warehouse azure-sql-data-warehouse


    【解决方案1】:

    Henrik,如果“select top 1”没有触发复制表构建,那么这将是一个缺陷。请提交支持票。

    如果不查看您的系统,就不可能确切知道发生了什么。以下是一些可能需要考虑延长构建时间的因素:

    • 复制的表很大(大小,不一定是行),需要很长的构建时间。
    • 复制表上有很多二级索引,需要很长的构建时间。
    • 复制表构建需要 statirc20(2 个并发槽)。如果并发槽不可用,则构建将排在其他正在运行的查询之后。
    • 复制的表不断被插入、更新和删除修改。修改需要重新构建表。

    【讨论】:

    • 伟大的洞察力,谢谢。复制的表并不大。没有二级索引。在更大的c 下运行。当我运行此脚本时,所有更改都已完成。下一步是填充事实表。奇怪的是,有时这个脚本会运行几个小时,直到实例被缩小才停止。
    【解决方案2】:

    最好的方法是在创建/更新表的作业中运行这样的命令:

    select top 1 * from <table>
    

    这将强制它在正确的时间重新分配,而不会在存储过程中缓慢循环。

    【讨论】:

    • 做一个 select top 1 没有这样的效果。 Select top 1 正在触发表进行计划复制。从这个意义上说,它不是同步的。您无法保证复制何时发生,因此,这就是脚本所做的,它等待表被复制。
    猜你喜欢
    • 2019-01-23
    • 2012-01-06
    • 2014-04-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-05-09
    • 2013-07-24
    • 2014-05-26
    相关资源
    最近更新 更多