标签: parallelism

如果我有一些像这样的 T-SQL 代码：

While @done<1
Begin
WAITFOR DELAY '00:00:30';
Set @done=<some select statement>
End

这可能会增加等待CXPACKET吗？据推测，其他处理器将在WAITFOR运行时等待？

我们正在构建一个商业智能系统，我们有一个巨大的 PostgreSQL 数据库 (DB)，可以在其中进行所有信息处理，还有一个 Redshift 数据仓库 (DWH)，可以在其中存储数据并执行查询。

后端是用 Java Server Faces (JSF) 构建的，之前的查询都是线性的。有些视图需要一分多钟的时间才能完成查询并将信息加载到屏幕中，因此我们决定在 Java 中使用线程并使查询异步。

因此，我们为每个视图准备了必要的查询，以便从我们的 EC2 应用程序机器并行运行到我们的 Redshift DWH，并运行线程，但视图仍然需要很长时间才能加载，有时甚至更长。

我们在文档中发现：

http://docs.aws.amazon.com/redshift/latest/dg/cm-c-executing-queries.html

http://docs.aws.amazon.com/redshift/latest/dg/c_troubleshooting_query_performance.html

http://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html

默认情况下，redshift 同时接收 5 个查询，但我们可以更改此设置。

有 3 个主要因素需要考虑：查询槽、并发和队列。我们已经明白了这一点：

队列就像 Java 中的线程。查询到达并被指定到“负载较少”队列，然后等待轮到它得到解决。我们可以有任意数量的队列。队列分配了一些内存（我们猜是平均分配的？）在队列中我们可以分配用户组或查询组。但短期来看，我们现在无法在查询中完成大量分类工作。

并发度是队列可以并行运行的查询量。默认为 5。

查询槽是查询可以使用的内存量。正如我们所理解的，它与并发有关。队列的并发性越高，每个查询槽中的内存就越少。

我们尝试过有 3 个队列，每个队列并发数为 5，但性能仍然很慢。

那么，如果我们理解正确的话，有些视图会进行 25-28 次查询，并且总加载时间约为 60 秒，那么我们如何保留设置才能更快地解决查询呢？

我正在研究并行设置的可能边缘情况。

我长期以来一直相信maxdop 1是 Microsoft Dynamics CRM 数据库的可行选项。由于数据库的本质是严格的 OLTP，并且并行性对 CRM 实例几乎没有好处，因此我始终将 CRM 数据库设置为maxdop 1.

但是，我现在有一个数据库实例，它具有：

• Microsoft Dynamics CRM 数据库
• 主要用于 OLAP 目的的 ETL 数据库

我询问了我们的业务合作伙伴，他们对性能重要性的看法如下：

1. CRM 必须快速，期间
2. ETL 导入不应受到限制，但应排在 CRM 性能之后

因此，我倾向于牺牲 OLAP 数据库的并行性，并设置maxdop 1为最大限度地使 CRM 受益。
然而，可能存在一些中间立场。

如果我将 设置cost threshold for parallelism为一个数字，排除 CRM 抛出的所有内容，但根据我的查询计划可能会抓取一些 OLAP 事务，对 CRM 会有任何不利影响吗？

如果有的话，保持阈值如此之高（几乎从未达到）的影响是什么，与设置相比maxdop 1，我是否会在计算查询计划时让 SQL Server 考虑阈值而产生一些隐藏成本？

以有效并行度 运行的 SQL Server 查询是否有可能x将并行工作器分配给多个x不同的调度程序？即使执行计划有许多并行区域？

我想对 PostgreSQL 中的一些东西进行基准测试。当我这样做时，我通常会关闭数据库当前正在使用的一些功能，仅用于我的会话，以查看次优计划是什么。

虽然设置max_parallel_works = 0，我仍然得到一个平行的计划。

                                                         QUERY PLAN                                                         
----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..120892.01 rows=1000 width=15) (actual time=0.444..4781.539 rows=666667 loops=1)
   Workers Planned: 2
   Workers Launched: 0
   ->  Parallel Seq Scan on foo  (cost=0.00..119792.01 rows=417 width=15) (actual time=0.102..4711.530 rows=666667 loops=1)
         Filter: (lower(x) ~~ '%999.com'::text)
         Rows Removed by Filter: 9333333
 Planning time: 0.124 ms
 Execution time: 4801.491 ms
(8 rows)

我知道它说Workers Launched: 0。但是，我希望它看起来像一个预平行计划，其中计划本身甚至没有计划为平行计划。我怎样才能做到这一点？

我在 Windows Server 2019（1809 版）上安装了 SQL Server 2019 Express Edition (CU8)，并且我的所有查询都NoParallelPlansInDesktopOrExpressEdition在NoparallelPlanReason属性中进行了串行。

是不是 Express Edition 永远不会并行？我在 Microsoft 文档中找不到任何关于此的信息。

我正在努力寻找将一些“varchar”列迁移到“nvarchar”的最佳方法。我使用的选项之一是添加新的 nvarchar 列，然后更新原始列中的值，删除原始列并将新列重命名为旧名称。

我知道它会生成大量的UNDO和REDO数据。不过，我还有其他限制（主要是 SQL Server 不支持并行 DDL 和多列 ALTER 表操作），因此让我们关注如何更快地运行更新语句。

我的 Oracle 经验告诉我使用内部并行性，但是它在 SQL Server 中可用吗？

尽管我特意将该表创建为堆表（无聚集索引），但我无法并行运行此语句。

update t
set new_col_1 = col_1
   ,new_col_2 = col_2
   ...
   , new_col_N = col_N
;

有 3 个文本列可容纳 400GB 数据。AWS RDS 的 IO 性能有限（10000 IOPS）。我们只有 4 小时的停机时间。

在此特定迁移中，不能选择在线重建，因为必须先将数据迁移（到 nvarchar），然后才能启动应用程序。在启动期间，它会检查实际数据类型是否与定义的数据类型（在应用程序元数据存储库中）相对应。

我知道碎片化，但我们别无选择。不过，如果有一些在线重建命令，它可能会很有用，因为我们稍后将能够进行迁移和碎片整理。实际上，作为准备步骤之一，我们正在删除聚集索引。稍后将再次创建该索引，我相信这将解决碎片问题，因为我们将从堆转移到 b*tree 结构。

令人非常沮丧的是我们无法使用任何其他“并行”技术。我正在考虑尝试手动并行更新，通过针对目标表的不重叠范围运行一些并行更新语句。尽管如此，锁升级可能是下一个问题，因为我将在每个更新中更新数百万条记录，并且很可能 SQL Server 将尝试升级到表锁，这将锁定其他更新，并且死机锁定将是最终结果..

这里和这里似乎表明它们是，但我也被告知（源无法定位）多行单语句插入只会使用一个线程进行所有写入，要多线程化，查询应该被分解并发送到与核心数量一样多的连接。

该文件指出，热膨胀系数执行“同时”，但没有效果，用来“热膨胀系数将使用所有可用内核来处理任何并行子报表和/或主查询”链接说明确。

CTE 是否总是将所有可用内核用于任何并行任务？如果是这样，除了可以合理地假设与 链接之外，还有什么警告RETURNING吗？

我们的 MS SQL Server 2016 数据库运行缓慢，我一直在使用 Brent Ozar 的急救箱进行一些初步故障排除。

我看到大量 CXPACKET 等待类型，在 17.5 小时的数据样本中，我们看到 10 个 CPU 的等待时间为 99 小时，即 55.5%！

我希望这里有人可以确认我们应该关注这个数字并尽快解决它。我们的 MAXDOP 设置为 4，这与 MS 的建议是准确的，但我们的 CTP 设置为 5，我认为需要更改为 50。

在我将这些信息交给我的老板之前，我只是想澄清一下，是的，我是数据库管理的新手，是的，我正在研究其他等待类型，但这似乎是迄今为止最重要的。

干杯，
乔希

我使用 pg_restore 从目录备份恢复 50 GB 数据库，使用以下命令，该命令使用了 4 个作业：

pg_restore -d analytics -U postgres  -j 4 -v "D:\Program Files\PostgreSQL\10\backups\Analytics_08_2018__7_53_21.36.compressed"

我从命令行运行了这个。恢复时间比非并行恢复长约 2 小时。它似乎在恢复作业结束时继续创建索引

pg_restore: launching item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: creating INDEX "public.nidx_bigrams_inc_hits"
pg_restore: finished item 2965 TABLE DATA trigrams
pg_restore: launching item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: creating INDEX "public.nidx_trigrams_inc_hits"
pg_restore: finished item 2823 INDEX nidx_unigrams_inc_hits
pg_restore: finished item 2822 INDEX nidx_trigrams_inc_hits
pg_restore: finished item 2817 INDEX nidx_bigrams_inc_hits
pg_restore: finished main parallel loop

每个 pg_restore“创建索引”作业在 pg_stat_activity 中的状态均为“空闲”。另一个 pg_restore 作业在提交时“空闲”。

我希望并行恢复能够比默认恢复快得多，而且它似乎一直在这样做，直到大约 …