标签: update

我在 Postgres 表中有一个jsonb列。它包含以下数据：datamy_table

[
   {"id":"1","status":"test status1","updatedAt":"1571145003"},
   {"id":"2","status":"test status2","updatedAt":"1571145323"}
]

我想updatedAt使用一个查询更新该数组中所有对象的键。我试过：

update my_table set data = data || '{"updatedAt": "1571150000"}';

上面的查询在数组中添加了一个新对象，如下所示：

[
   {"id":"1","status":"test status1","updatedAt":"1571145003"},
   {"id":"2","status":"test status2","updatedAt":"1571145323"},
   {"updatedAt":"1571150000"}
]

我想要的输出如下：

[
   {"id":"1","status":"test status1","updatedAt":"1571150000"},
   {"id":"2","status":"test status2","updatedAt":"1571150000"}
]

我也尝试过jsonb_set()，但这需要第二个参数是数组索引。我无法确定数组中 JSON 对象的数量。

如果可以通过自定义函数解决这个问题，也很好。

我有一个关于 SQL Server 的 UPDATE 语句的内部工作原理的问题。我试图了解如果同时收到或服务以下 2 个更新语句会发生什么：

 |    Session 1 - Statement 1 | Session 2 - Statement 2
 |   -------------------------+-------------------------
 |    update dbo.Table1       |  update dbo.Table1 
 |    set Value = 10          |  set Value = 20 
 |    where ID = 1            |  where ID = 1 
 ?    and Value = 0;          |  and Value = 0;
(t)

据我了解，更新将首先选择需要使用共享锁更新的行，这意味着两个更新语句都可以选择特定行。然后它请求一个排它锁来更新列值。因此，结果似乎将 Value 设置为 20。

我错过了什么还是我的理解正确？

连接的隔离级别设置为 READ UNCOMMITTED。

当我尝试更新连接时，我收到“ORA-01779：无法修改映射到非键保留表的列”。我在网站上搜索并找到了很多关于保留密钥的含义以及为什么有必要的建议......但据我所知，我正在遵守该建议，但仍然出现错误。

我有两个表：

PG_LABLOCATION has, among other things, the columns:
"LABLOCID" NUMBER,
"DNSNAME" VARCHAR2(200 BYTE)

LABLOCID is the primary key, DNSNAME has a unique constraint

PG_MACHINE has, among other things, the columns:
"MACHINEID" NUMBER, 
"LABLOCID" NUMBER, 
"IN_USE" NUMBER(1,0) DEFAULT 0, 
"UPDATE_TIME" TIMESTAMP (6) DEFAULT '01-JAN-1970'

MACHINEID is a primary key
LABLOCID is a foreign key into LABLOCID in PG_LABLOCATION (its primary key)

我正在运行的更新是：

update 
  (select mac.in_use, mac.update_time
     from pg_machine mac 
     inner join pg_lablocation loc
       on mac.lablocid = loc.lablocid
     where loc.dnsname = …

我必须更新一个大表的某些值（为了一个假定的例子，它被称为“资源”，它超过 500 万行），因此我必须在执行更改之前进行备份。我们没有足够的数据库可用空间来存储完整的备份表。

哪种方法最好？有没有办法通过块来做到这一点？我的意思是：备份原始表中的前 100K 行，更新原始表中的那 100K 行，从备份表中删除那 100K 行，备份原始表中的以下 100K 行，然后进行类似的操作. 这可行吗？

我发现您可以使用子句（示例here和here）high performance updates对varchar(max),nvarchar(max),varbinary(max)列进行操作。不幸的是，官方文档中没有提到性能优化。.WRITE

谁能告诉有任何优化吗？有人做过性能测试吗？此外，如果有优化，我想它也只会影响特定情况。

我已经提供了 SQL Server 2014 的 RTM 版本，我需要应用最新的 SP（当前为 SP2）和 CU（当前为 CU8）。我需要先申请SP1吗？或者我可以直接迁移到 SQL Server 2014 SP2 CU8 而不应用旧的 Service Pack 1 和相关的累积更新吗？

我正在尝试运行脚本来更新 XML 列：

UPDATE DataImpTable
SET serviceData.modify('replace value of (/SMObjInfo/CentralData/SMData/CentralSDItem/ControlData/text())[1] with "9876"')
WHERE identifier=5

UPDATE DataImpTable
SET serviceData.modify('replace value of (/SMObjInfo/CentralData/SMData/CentralSDItem/ControlData/text())[1] with "9876"')
WHERE identifier=5

将 的值更改ControlData为 9876，但该值在 XML 中似乎没有更改/SMObjInfo/CentralData/SMData/CentralSDItem/ControlData。

它与类型化和非类型化 XML 有什么关系？

我们有这种非常奇怪的行为，我们刚刚开始体验我们的 update intersect 语句。这些工作正常，但现在我们在列方面摄取了相当广泛的数据源，并逐渐减慢直至无限期挂起。

当我们以 20K 行（非常小）为一组添加数据时，下面的查询将变得越来越长，并且大约有 70K 行。没有使用索引，我们在摄取数据之前删除它们。

这是声明：

UPDATE Staging.[TdDailyPerformance]
SET [SYS_OPERATION] = 'U'
FROM (
    SELECT [HashCode]           
    FROM Staging.[TdDailyPerformance]
    INTERSECT
    SELECT [HashCode]
    FROM [IdMatch].[TdDailyPerformance]
) AS A

执行计划：

现在这个查询在我们服务器上的许多其他地方都有效，但不是在这里。有趣的是，无论是否INTERSECT返回行，查询都会永远挂起（我通过独立运行 intersect 来测试这一点 - 它花费的时间不到 2ms。）。

根据 SQL 似乎它不应该工作，但确实如此。如果HasCode在Staging表中已经存在IdMatch的表就更新[SYS_OPERATION]了的Staging表是“U”。我们在几个地方使用了这几个地方，它最近才开始在这个数据集上失败。

任何想法可能导致这种情况？

就我们所见，没有阻塞。交易的唯一等待类型CXPACKET是我对 QP 的期望。我已经查询sp_who2、查看了所有事务和活动监视器以识别块，但一无所获。我没有追过。

大多数情况下，我们的测试现在可以运行，因此它在挂起时有 0 行。但是我们已经验证它也挂起 1-100 行INTERSECT.

IdMatch有没有HashCodes存在的Staging，但是这两个表在杭的时间大约有70K行。所以要清楚，两个表都有大约 70K，但交叉点HashCode是 0 行。

我们已经用索引进行了测试。在我们遇到有问题的查询之前，我们的整体性能很差。索引只是碎片化得太快而无济于事。

表定义 …

我正在学习 SQL Server 并试图了解 SQL Server 如何更新行。

据我了解，SQL Server首先对数据库加一个意向排它锁，然后对表加一个意向排它锁，然后对要更新的记录加一个更新锁。稍后，它将将该行上的更新锁转换为排他锁，以便可以修改该行中的数据。

但问题是共享锁与更新锁兼容。因此，虽然该行有更新锁，但其他会话仍然可以使用共享锁读取该行。如果行上有共享锁，则无法将更新锁转换为排它锁，因为共享锁和排它锁不兼容。

这是否意味着如果有会话连续读取该行，SQL Server 根本没有机会更新该行。这种情况可能会持续很长一段时间。这是真的？SQL Server 会等到该行上没有共享锁时才开始更新其中的数据吗？

我所说的“连续”是指一个会话读取该行，并且在从该行释放共享锁之前，另一个会话在同一行上放置一个共享锁。在第二个共享锁从该行释放之前，另一个会话在同一行上放置另一个共享锁，依此类推。因此，基本上，该行上总是至少有一个共享锁。

我继承了一个系统，其中对 MySQL 表的所有更新（甚至是单行/记录）都不是使用UPDATE table_name SET. 相反，它们是通过以下方式完成的：

1. 将现有表导出到 CSV（文本）文件。
2. 修改 CSV 文件中的相应行。
3. 使用 重新加载 CSV 文件LOAD DATA ... REPLACE INTO TABLE。

这是我第一次看到这种更新表记录的方法，我想知道这样做的理由是什么。

顺便说一句，由于更新时需要锁定 CSV 文件，该方案会导致许多线程同步问题。

LOAD DATA ... REPLACE INTO TABLE我希望得到关于使用而不是 的好处的解释或见解UPDATE table_name SET。