Lennart - Slava Ukraini's questions

我尝试创建一个过程来根据列中的最大值调整序列。为了从列中获取最大值并将其存储在变量中，我最终使用了“虚拟”游标。我认为有一种更简单的方法，但我无法让其中任何一个方法起作用。关于如何摆脱游标并仍然能够在 alter 语句中使用最大值，有什么建议吗？

--#SET TERMINATOR @
CREATE OR REPLACE PROCEDURE Adjust_Sequence(
    IN p_table_schema VARCHAR(128),
    IN p_table_name VARCHAR(128),
    IN p_column_name VARCHAR(128),
    IN p_sequence_name VARCHAR(128)
)
LANGUAGE SQL
BEGIN
    DECLARE v_max_value BIGINT DEFAULT 1;
    DECLARE v_sql_stmt VARCHAR(1000);
    DECLARE cur CURSOR FOR S;

    -- Construct SQL to get the max value of the specified column
    SET v_sql_stmt = 'SELECT COALESCE(MAX(' || p_column_name || '), 0) + 1 FROM ' ||  p_table_schema || '.' || p_table_name;

    -- Prepare and execute the statement properly
    PREPARE S FROM v_sql_stmt;
    OPEN cur;
    FETCH cur INTO v_max_value;
    CLOSE cur;

    -- Construct SQL to alter the sequence to restart with the new max value
    SET v_sql_stmt = 'ALTER SEQUENCE ' || p_sequence_name || ' RESTART WITH ' || v_max_value;

    -- Execute the sequence alteration
    EXECUTE IMMEDIATE v_sql_stmt;
END @
--#SET TERMINATOR ;

我注意到导入截断的数据只会引发警告。T 认为通过处理程序捕获该警告并发出错误信号会很简单，但我似乎无法做到这一点。有什么建议么？

CREATE OR REPLACE PROCEDURE FILE_IMPORT_HANDLER(filename VARCHAR(255), tablename 
VARCHAR(255))
LANGUAGE SQL
BEGIN
    DECLARE EXIT HANDLER FOR SQLSTATE '22001'
        SIGNAL SQLSTATE '75002'
            SET MESSAGE_TEXT = '...';

    CALL ADMIN_CMD('import from ' || filename || ' of del insert into ' || tablename);
END @

如果遇到22001我愿意努力失败。从某种意义上说，提高导入过程中数据截断的严重性

在我意识到存在重新验证对象的过程（SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS）之前，我编写了自己的过程。现在，我尝试将其替换为标准的，但似乎对 SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS 的调用破坏了我正在循环的游标。旧程序示例：

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL TOOLBOX.COMPILE_SCHEMA2(v.schemaname); END FOR; END @"
DB20000I  The SQL command completed successfully.

使用 ADMISN_REVALIDATE_DB_OBJECTS 的示例

db2 "CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')"
Return Status = 0
db2 "CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')"
Return Status = 0

尝试在光标上循环使用它：

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>v.schemaname); END FOR; END @"
DB21034E  The command was processed as an SQL statement because it was not a 
valid Command Line Processor command.  During SQL processing it returned:
SQL0501N  The cursor specified in a FETCH statement or CLOSE statement is not 
open or a cursor variable in a cursor scalar function reference is not open.  
SQLSTATE=24501

请注意，它对硬连接架构没有帮助：

db2 -td@ +c "BEGIN FOR v AS c1 CURSOR FOR SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS DO CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>'TMP')
[...]

也会产生错误。我尝试了在光标上循环的变体：

BEGIN
    DECLARE s VARCHAR(128);
    DECLARE v_at_end INTEGER default 0;
    DECLARE not_found CONDITION FOR SQLSTATE '02000';
    DECLARE C1 CURSOR for
        SELECT SCHEMANAME FROM NYA.VALIDATION_SCHEMAS;
    DECLARE CONTINUE HANDLER FOR not_found  SET v_at_end = 1 ;

    OPEN C1;
    fetch_loop:
    LOOP
        FETCH FROM C1 INTO s;
        IF v_at_end <>0 THEN LEAVE fetch_loop; END IF;
        CALL SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS(object_schema=>s);
    END LOOP;
    CLOSE C1;
END
@

但它也不起作用。任何线索，需要做什么才能在循环中调用 ADMIN_REVALIDATE_DB_OBJECTS ？

CHAR(n) FOR BIT DATA我想我在某处看到and之间存在某种语义差异BINARY(n)，但我无法找到它的位置。任何指针？

我之所以问，是因为我有大量CHAR(16) FOR BIT DATA从以前定义的列BINARY(16)，并考虑将它们逐渐迁移到 BINARY(16)。我很好奇是否有任何情况下迁移 fk 关系的一侧之前会导致问题。

我正在考虑将许多日志表转换为范围分区，主要目的是通过分离和归档历史数据来减小数据库的大小。过程如下：

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T1','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

...

CALL SYSPROC.ADMIN_MOVE_TABLE('S','T120','', '', '', '', '',
'(ACTION_TIME) (STARTING FROM (''2000-01-01-00.00.00.000000'') ENDING AT (''2029-12-31-23.59.59.999999'') EVERY 1 YEAR)', '', 'COPY_USE_LOAD', 'MOVE' );

为简单起见，在此测试期间，我没有对每个表 (pk + ts) 上的索引做任何事情，它们与以前保持在同一个表空间中。所有表都使用这个表空间作为它们的索引

似乎工作正常，虽然我收到了一些神秘的警告。对于我得到的每张桌子：

SQL0206N "STATSPROFTYPE" is not valid in the context where it is used.

对于一些临时表（似乎是带引号的名称以小写字母结尾的表），我收到了有关 runstats 的其他投诉。

做了一些测试，表格似乎可以访问。

然后我分离了旧分区，例如：

for t in $(db2 -x "select rtrim(tabschema) || '.' || rtrim(tabname) from SYSCAT.DATAPARTITIONS where tabname like '%_LOG' group by tabschema, tabname having COUNT(datapartitionname) > 1"); do
    for p in part{0..18}; do 
        db2 "alter table $t detach partition $p into ${t}_$p"; 
        db2 "drop table ${t}_$p"; 
    done 
    # db2 "reorg table $t";
    db2 "runstats on table $t with distribution and sampled detailed indexes all"
done

仍然可以访问所有表，但是如果我查询：

db2 "SELECT substr(tabschema,1,20), substr(tabname,1,60), substr(VALUE,1,10) FROM SYSTOOLS.ADMIN_MOVE_TABLE WHERE KEY='STATUS'"

所有表的值都是 CLEANUP。我离开了几个小时，数据库中没有任何活动，但表保持不变。平均而言，我可能删除了这些表中 50% 的行，但大小根据：

db2 "CALL GET_DBSIZE_INFO(?, ?, ?, -1)"
...
Parameter Name  : DATABASESIZE
Parameter Value : 769891516416 

没有减少。

由于缺乏想法，我遍历了表并重新组织了每个表和所有索引，但它似乎没有改变任何东西。

表长时间处于这种状态是否正常？在迁移下一个表之前等待 CLEANUP 会有所帮助吗？

我正在使用 docker 和 db2，但是当我尝试以用户 db2inst1 的身份将命令执行到正在运行的容器中时，我遇到了麻烦。我将容器启动为（它是 1 行，但为了便于阅读，我将其拆分）：

docker run -itd --name mydb2 --privileged=true -p 50000:50000 
  -e LICENSE=accept 
  -e DB2INST1_PASSWORD=pelle_paltnacke 
  --mount type=volume,dst=${backupdir},volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=${addr}\",volume-opt=device=:${device} 
  -v /etc/passwd:/etc/passwd 
  -v /etc/group:/etc/group 
  -v /opt/nya/users/db2inst1:/opt/nya/users/db2inst1 
  -v /home/system/db2fenc1/:/home/system/db2fenc1/ ibmcom/db2

现在，如果我尝试这样做：

docker exec --user db2inst1 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
unable to find user db2inst1: no matching entries in passwd file

作为root没有问题：

docker exec -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

而且 --user root 也可以正常工作：

docker exec --user root -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

所以我尝试使用挂载的 passwd 文件中的 uid：

docker exec --user 422 -ti mydb2 bash -c "cat /etc/passwd | grep db2inst1"
db2inst1:x:422:422:DB2 Instance Administrator 1:/opt/nya/users/db2inst1:/bin/bash

/etc/passwd 对每个人都是可读的。无论如何，使用 uid 并没有让我走得太远：

docker exec --user 422 -ti mydb2 bash -c "db2licm -l"
bash: db2licm: command not found

所以我尝试：

docker exec --user 422 -ti mydb2 bash -c "whoami; . ~db2inst1/sqllib/db2profile; 
db2licm -l"
db2inst1
bash: /opt/nya/users/db2inst1/sqllib/adm/db2licm: Permission denied

这只是我为演示问题而运行的几个命令。有没有人解释为什么 --user db2inst1 不能执行它们？

FWIW，我尝试不使用 nfs-mount 但我得到了相同的行为。

容器本身似乎工作正常。如果我如上所述启动容器并且：

#> docker exec -ti mydb2 bash
[root@0ee67959246f /]# mkdir -p /data/db/db2
[root@0ee67959246f /]# chown db2inst1:db2iadm1 /data/db/db2/
[root@0ee67959246f /]# su - db2inst1
[db2inst1@0ee67959246f ~]$ cd /data/backup/db2/wb11/MD000I11/
[db2inst1@0ee67959246f MD000I11]$ db2 "restore db MD000I11 incremental auto taken at 20220307141244 to /data/db/db2 into WD000I11"
DB20000I  The RESTORE DATABASE command completed successfully.

编辑：一个有趣的观察是：

docker exec --user 422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=0(root) groups=0(root)

docker exec --user 422:422 -ti mydb2 bash -c "id"
uid=422(db2inst1) gid=422(db2iadm1) groups=422(db2iadm1)


docker exec --user 422:422 -ti mydb2 bash -c "whoami; . 
~db2inst1/sqllib/db2profile; db2licm -l"

db2inst1
Product name:                     "DB2 Community Edition"
License type:                     "Community"
...

不幸的：

docker exec --user db2inst1:db2iadm1 -ti mydb2 bash -c "id"
unable to find user db2inst1: no matching entries in passwd file

我不认为我曾经对此进行过反思，但我目前正在从游标加载表格并列出实用程序显示：

  Phase Number               = 3
  Description                = BUILD
  Total Work                 = 46 indexes
  Completed Work             = 0 indexes
  Start Time                 = Not Started

在当前模式中，有 4 个索引 + 一个 XML 列（根据 syscat.indexes 似乎贡献了 2 个）。起初我认为这可能是一个错误，计算不同模式中相同表名的索引，但这也不算数，因为有 10 个模式具有这样命名的表。

我只是好奇这个阶段的“总工作量”是什么意思？

我正在考虑将我们的一些大型日志表移动到范围分区，以便于归档它们。它们很少用于查询，除了支持和相关的东西。假设我最旧的数据来自 2013 年，我每年将使用 1 个分区。如果我提前几年（比如到 2025 年）添加分区，会有什么负面影响？此外，是否可以使用时间戳列作为分区键，或者使用一年生成的列有什么优势？

我正在尝试将 Access 用作 SQL Server 2017 数据库的前端。我感兴趣的对象是 6 个临时表和一个加入它们的视图。我创建了一个 ODBC 用户数据源并链接了表和视图。对于视图，我创建了一个更新基础表的而不是更新触发器，它工作得很好。

由于基础表的主键是标识，我认为直接针对基础表而不是通过视图插入/删除会更容易（SET IDENTITY_INSERT ON通过 SQL 操作视图时我必须这样做）。

我可以毫无问题地向其中一个表添加一行，但是当我尝试删除或更新表中的一行时，我收到一条错误消息“Reserverat fel (-7776). Det finns inget meddelande för felet”。粗略地翻译为“保留错误（-7776）。没有错误消息”。

我每隔 20 年左右定期访问 Windows 世界，所以我不知道从哪里开始寻找可能是什么错误的任何线索。有什么见解吗？

有趣的是，如果我创建一个连接两个表的视图（其中一个表的主键在视图中也是唯一的），我可以更新视图，并且基础表也更新（没有代替触发器必要的）。

也可以插入一个新行（对于删除，我似乎需要一个而不是触发器）。所以我想这是一种解决方法，但我可以更新视图而不是表格似乎很奇怪。

我找到了我 2011 年的一些旧笔记，并且我还重新阅读了 @lukas-eder 的优秀文章10 Cool SQL Optimisations That do not Depending the Cost Model。所以我想我会再记笔记。场景很简单Fiddle

create table emp ( 
    emp_no int not null primary key, 
    title varchar(10) not null, 
    salary int not null, 
        check (emp_no > 0), 
        check (title in ('BOSS','WORK'))
);

insert into emp with recursive t (n) as (
    values (1) 
    union all 
    select n+1 from t where n+1 < 1000
) select n, case when mod(n,10) = 0 then 'BOSS' else 'WORK' end, 
            case when mod(n,10) = 0 then 110 else 0 end + mod(n,90) 
from t;

现在，给定规则：

 (TITLE = BOSS) implies (SALARY > 100)

和

 (TITLE = WORK) implies (SALARY <= 100)

可以实现为：

-- (TITLE = BOSS) => (SALARY > 100)
alter table emp add constraint cc1 
    CHECK ( (title <> 'BOSS' OR salary > 100) );
-- (TITLE = WORK) => (SALARY <= 100)
alter table emp add constraint cc2
    CHECK ( (title <> 'WORK' OR salary <= 100) );

和查询：

select * 
from emp 
where title = 'BOSS' and salary <= 100

DBMS 能否发现矛盾，并在不接触数据的情况下返回空结果集？

Let A = ( title = ’BOSS’ ), B = ( salary > 100 )

select * from emp where (A ^ ~B)                    
select * from emp where (A ^ ~B) ^ (~A v B)           # by cc1 
select * from emp where (A ^ ~B ^ ~A) v (A ^ ~B ^ B)    
select * from emp where (FALSE ^ ~B) v (A ^ FALSE)      
select * from emp where (FALSE) v (FALSE)           
select * from emp where (FALSE)

我试过 Postgres 13（见上面的小提琴）

Seq Scan on emp  (cost=0.00..26.50 rows=2 width=46) (actual time=0.134..0.134 rows=0 loops=1)
  Filter: ((salary <= 100) AND ((title)::text = 'BOSS'::text))
  Rows Removed by Filter: 999
Planning Time: 0.312 ms
Execution Time: 0.149 ms

和 DB2 11.5.4.0：

Optimized Statement:
-------------------
SELECT 
  Q1.EMP_NO AS "EMP_NO",
  Q1.TITLE AS "TITLE",
  Q1.SALARY AS "SALARY" 
FROM 
  DB2INST1.EMP AS Q1 
WHERE 
  (Q1.SALARY <= 100) AND 
  (Q1.TITLE = 'BOSS')

Access Plan:
-----------
        Total Cost:             51.8267
        Query Degree:           1


      Rows 
     RETURN
     (   1)
      Cost 
       I/O 
       |
     90.2441 
     TBSCAN
     (   2)
     51.8267 
        4 
       |
       999 
 TABLE: DB2INST1
       EMP
       Q1

但两者都没有这样做。任何其他可以发现矛盾并采取行动的 DBMS？这当然比现实世界的问题更有趣，但仍然如此。

编辑：@federico-razzoli 在他的回答中建议的约束也不起作用：

alter table emp add constraint cc1
    check ((title = 'BOSS' and salary > 100) or 
           (title = 'WORK' AND salary <= 100));

并且相同的查询仍然会导致表访问

 Rows 
 RETURN
 (   1)
  Cost 
   I/O 
   |
 90.2441 
 TBSCAN
 (   2)
 51.8267 
    4 
   |
   999 

表：DB2INST1 EMP Q1

我正在为一个在 docker 容器内运行的小型 postgres 12.2 数据库创建一个备份/恢复脚本。备份看起来像：

docker exec -e PGPASSWORD=${passwd} ${container} \
   pg_dump -h ${host} -U ${username} ${db} \
   -Fc > ${backupdir}${db}_$(date +"%Y-%m-%d-%H.%M.%S.%N").pgdump

然后我创建一个新数据库，并尝试将其还原为：

docker exec -i ${container} pg_restore -Fc --verbose --clean \
   --no-acl --no-owner -U ${username} \
   -d ${testdb} < ${backupdir}${db}_ ...

这似乎适用于许多表，然后每次都冻结在一个特定的表上。尽管 Postgres 正在使用 80% 的 CPU，但似乎什么也没发生。我让它运行了 10 个小时而没有完成。

有问题的表包含约 1E6 行，一个 3 倍大的表在大约 10 秒内恢复。该表包含一个生成的列：

CREATE TABLE MIND.FILER
( DOKUMENT_UUID UUID NOT NULL   -- document_uuid
, SIDNUMMER INTEGER NOT NULL    -- page number
, FILTYP TEXT NOT NULL          -- file type
, TILLSTAND SMALLINT NOT NULL   -- state 
, FILNAMN TEXT NOT NULL         -- name of file
, FULLSTANDIGT_FILNAMN TEXT GENERATED ALWAYS AS -- complete file name including path 
    (mind.uuid_2_path(dokument_uuid) || rtrim(filnamn)) STORED
,   CONSTRAINT PK_FILER PRIMARY KEY (DOKUMENT_UUID, SIDNUMMER, FILTYP)
,   CONSTRAINT FK_SIDOR
        FOREIGN KEY (DOKUMENT_UUID, SIDNUMMER)
            REFERENCES MIND.SIDOR (DOKUMENT_UUID, SIDNUMMER)
                ON DELETE CASCADE
                ON UPDATE CASCADE
,   CONSTRAINT FK_FILTYPER
        FOREIGN KEY (FILTYP)
            REFERENCES MIND.FILTYPER (FILTYP)
                ON DELETE CASCADE
                ON UPDATE CASCADE
);

但我的印象是，这不应该影响恢复，至少不会影响到这个程度。

函数 MIND.UUID_2_PATH 根据使用的 UUID 版本定位文件系统中的挂载点。

CREATE OR REPLACE FUNCTION MIND.UUID_2_PATH(DUID UUID)
    RETURNS TEXT AS $$
    DECLARE s text;
    DECLARE ss text;
    DECLARE uuid_v int;
BEGIN
    SELECT substr(DUID::text,15,1) into uuid_v;
    IF uuid_v = 4 THEN
        SELECT REPLACE(CAST(DUID AS TEXT),'-','') INTO s;
        SELECT monteringspunkt
                  ||SUBSTR(s,1,4)||'/'
                  ||SUBSTR(s,5,4)||'/'
                  ||SUBSTR(s,9,4)||'/'
                  ||SUBSTR(s,13,4)||'/'
                  ||SUBSTR(s,17,4)||'/'
                  ||SUBSTR(s,21,4)||'/'
                  ||SUBSTR(s,25,4)||'/'
                  ||SUBSTR(s,29,4)||'/' INTO ss
        FROM mind.filsystemsmonteringar
        WHERE uuid_version = 4;
    ELSE -- uuid_v = 3
        SELECT lpad(dokument_id::text, 10,'0') into s FROM MIND.DOKUMENT where dokument_uuid = DUID;
        SELECT monteringspunkt
                  ||SUBSTR(s,1,3)||'/'
                  ||SUBSTR(s,4,3)||'/'
                  ||SUBSTR(s,7,2)||'/'
                  ||s||'/' INTO ss
        FROM mind.filsystemsmonteringar
        WHERE uuid_version = 3;
    END IF;
    RETURN ss;
end;
$$
LANGUAGE plpgsql
IMMUTABLE
RETURNS NULL ON NULL INPUT;

这可能不是最有效的方法，但使用 \copy 将数百万行加载到表中执行得不错。

时不时有类似的条目：

2020-10-06 12:36:17.078 UTC [27] LOGG:  checkpoint starting: time
2020-10-06 12:38:47.123 UTC [27] LOGG:  checkpoint complete: wrote 689 buffers (4.2%); 0 WAL file(s) added, 0 removed, 10 recycled; write=149.943 s, sync=0.000 s, total=150.045 s; sync files=79, longest=0.000 s, average=0.000 s; distance=163338 kB, estimate=163338 kB
2020-10-06 12:41:17.223 UTC [27] LOGG:  checkpoint starting: time
2020-10-06 12:41:17.743 UTC [27] LOGG:  checkpoint complete: wrote 5 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.503 s, sync=0.013 s, total=0.519 s; sync files=4, longest=0.012 s, average=0.003 s; distance=369 kB, estimate=147041 kB

在日志中。据我所知，Postgres 配置并没有做太多事情。我不得不增加 shm，但除此之外，它是普通的香草。我不确定哪些内存区域/配置可以提高 pg_restore 的性能。正如你所知道的，我是 postgres 的新手（在 docker 上做一个白痴似乎也无济于事 ;-)。因此，任何有关可能导致此“冻结”的原因或在哪里寻找更多信息的提示将不胜感激。

编辑：在@laurenz-albe 提供的帮助下，我可以取消较旧的恢复，瞧，剩余的恢复在几分钟内完成。

然后我删除了数据库，再次创建它并检查了以下查询，结果为 0 行：

select pid, application_name, backend_start, state_change, backend_type 
from pg_stat_activity 
where datname = 'testdb';

然后我像以前一样开始新的恢复并再次检查查询。结果是 1 个客户端后端和 2 个并行工作人员，工作人员似乎不时重启，但恢复似乎卡住了。

查看查询：

select backend_type, query 
from pg_stat_activity 
where datname = 'testdb';

表明：

client backend  | COPY mind.filer (dokument_uuid, sidnummer, filtyp, tillstand, filnamn) FROM stdin;         +
                 | 
 parallel worker | SELECT lpad(dokument_id::text, 10,'0')        FROM MIND.DOKUMENT where dokument_uuid = DUID
 parallel worker | SELECT lpad(dokument_id::text, 10,'0')        FROM MIND.DOKUMENT where dokument_uuid = DUID

因此工作人员正在从生成的列中使用的函数运行查询。pg_restore 是否有可能由于对另一个表的依赖而锁定自己？

是否可以在 \copy 期间让 pg_restore 转为生成的表达式？在转储中已经存在所有值之后，我得到的印象是这是默认值。

杀死工人后：

postgres=# select pg_cancel_backend(pid) 
    from pg_stat_activity 
    where datname = 'testdb' and backend_type = 'parallel worker';
 pg_cancel_backend 
-------------------
 t
 t
(2 rader)

恢复继续，但恢复后表为空

鉴于以下情况：

DB1:
EXPORT TO T.IXF OF IXF ... modified by codepage=... SELECT * FROM T;

DB2:
CREATE TABLE T (...) COMPRESS YES ADAPTIVE ORGANIZE BY ROW;
CREATE INDEX ... ON T (...) COMPRESS YES;
...
LOAD FROM T.IXF OF IXF INSERT INTO T (...);

DB1 和 DB2 中的索引是相同的，除了在 DB2 中被压缩之外，DB1 中的集群比率似乎还可以（不确定这是否重要）。DB1 和 DB2 之间的代码页不同

加载后进行重组有什么意义吗？我发现 Z 的一些文章似乎表明数据的导出方式很重要（因为 Z 没有仔细阅读，所以我不知道这是否与 Z 和/或 LUW 相关） .

我尝试了相当多的表，并在加载后执行了 REORGCHK，一切似乎都很好。比较CALL GET_DBSIZE_INFO(?, ?, ?, 0)REORG 之前和之后显示大小略有下降 (<1%)，但我不知道这是否是巧合。

在加载到空表后，是否存在 REORG 有益的特殊情况？

这只是我开始考虑的一个愚蠢的例子，但似乎无法提出一个优雅的解决方案。假设一个日历表（我将使用 Db2 语法）：

create table calendar
( dt date not null primary key
);

insert into calendar (dt)
with t (dt) as ( values cast('2020-01-01' as date)
                 union all
                 select dt + 1 day from t where dt < '2020-01-11')
select dt from t                 
;

和一个保持平衡的表：

create table balance 
( dt date not null
, amount int not null
,     primary key (dt)
);

insert into balance (dt, amount)
values ('2020-01-03',100) ,('2020-01-05', -50);

如果我们想复制最后一个已知余额，我们可以使用 LAST_VALUE 和 'IGNORE NULLS'，例如：

select c.dt, last_value(b.amount, 'IGNORE NULLS') over (order by c.dt)
from calendar c
left join balance b
    on c.dt = b.dt;

但是，如果我们添加一个维度，比如 cid (customer_id)，那么 last_value 的含义就不再明显了。通常我们会按 cid 进行分区，但 cid 由于左连接而丢失：

create table balance1 
( cid int not null
, dt date not null
, amount int not null
, primary key (cid, dt)
);

insert into balance1 (cid, dt, amount)
values (1, '2020-01-03',100) ,(1, '2020-01-05', -50)
     , (2, '2020-01-04',75), (2, '2020-01-08',55), (2, '2020-01-10', -35);


select c.dt, last_value(b.amount, 'IGNORE NULLS') over (partition by ? 
                                                        order by c.dt)
from calendar c
left join balance b
    on c.dt = b.dt;

我能想到的最好办法是在日历和余额中的不同客户之间使用笛卡尔积：

select cid, dt, last_value(amount, 'IGNORE NULLS') over (partition by cid order by dt)
from (
  select cid, dt, amount from balance1
  union
  select distinct b.cid, c.dt, null 
  from balance1 b
  cross join calendar c
  where not exists (
    select 1 from balance1 
    where dt = c.dt and cid = b.cid
  )
) t  
order by dt, cid
;

不是那么漂亮，我正在寻找一个更优雅的解决方案。我在上面和这个Fiddle中使用了 Db2 语法，但这是我所追求的原则，所以任何供应商语法都可以。

用户 U 运行的批处理删除并创建工作表 T。简化设置：

用户 U 的权限

db2 grant dataaccess on database to user U
db2 grant all on table T to user U
db2 transfer ownership of table T to user U 

由于代码是从多个地方调用的，我认为最好从过程 P 中删除并创建表，以避免不同的代码为表创建不同的外观。

db2 -td@ -f "create procedure P()
   LANGUAGE SQL
   BEGIN
       BEGIN
           -- do nothing if drop table fails
           DECLARE CONTINUE HANDLER FOR SQLSTATE '42704'
           BEGIN
           END;
           execute immediate 'drop table T';
       END;
       execute immediate 'CREATE TABLE T (x int)';
END @"

但是，当用户 U 调用此过程时，它会失败并显示：

db2 "call P()"
SQL0551N  The statement failed because the authorization ID does not have the 
required authorization or privilege to perform the operation.  Authorization 
ID: "U". Operation: "CREATE TABLE". Object: T SQLSTATE=42501

是否可以向用户 U 授予权限（除了 dbadm 或其他核选项:)，以便它可以成功执行过程 P？

我正在将一些数据库迁移到 UTF-8，并且刚刚发现了我不知道的现象。选择数据到终端时，将额外的字节添加到输出中。例子：

~]$ x=$(db2 -x "values 'a'")
~]$ echo "${x}b"
a b

后一个额外的空格

~]$ x=$(db2 -x "values 'aa'")
echo "${x}b"
aa  b

aa 后面的两个额外空格

一个字符在 utf8 中占用多少字节似乎并不重要：

~]$ x=$(db2 -x "values '?'")
~]$ echo "${x}b"
? b

g-谱号后加一个空格

~]$ x=$(db2 -x "values '??'")
~]$ echo "${x}b"
??  b

g-clef 后的两个额外空格 g-clef

数据库配置文件：

Database territory                                      = SE
Database code page                                      = 1208
Database code set                                       = UTF8
Database country/region code                            = 46
Database collating sequence                             = SYSTEM_819_SE

终端具有编码 UTF8（尝试过终止符和 gnome-terminal），并且在连接到数据库之前我做了：

export LC_CTYPE=sv_SE.utf8

上面当然只是愚蠢的例子，但我在类似的脚本中有相当多的测试：

dbtype=`db2 -x "values nya.get_db_type()"`
if [ "${dbtype}" = "N" ]; then
    ...

我需要以一种或另一种方式更改测试的地方。

关于配置的任何想法，可以摆脱额外的字节？

~]$ uname -a
Linux nya-ladok3-release 3.10.0-1062.9.1.el7.x86_64 #1 SMP Mon Dec 2 08:31:54 EST 2019 x86_64 x86_64 x86_64 GNU/Linux
~]$ db2level
DB21085I  This instance or install (instance name, where applicable: 
"db2inst1") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V11.5".

编辑：我通过将属性与元素混淆来证明我的无知，我更新了我的问题。对不起。为了澄清，我正在寻找元素代码的存在：

<conditionmessage:code>MYCODE</conditionmessage:code>

我有一堆模式，其中有一个包含 XML 列的表。每列都有一些 XML 索引。我很确定 SQL 模式之间的 XML 模式不同，但是，每个模式中都存在相同的 XML 索引。我怀疑复制/粘贴，我似乎无法找到 XML 模式的任何文档。所以我想到了一种更实用的方法，即遍历 XML 列并检查每个元素是否存在。这些表格已经存在了一段时间，所以现在所有可能的元素都应该在那里。

现在的问题是，无论价值如何，检查元素是否存在的最佳方法是什么？不幸的是，我的大脑与 XPATH/XQUERY 不兼容，每次我都必须努力让自己相信查询完成了它应该做的事情。我目前的方法似乎有效，但我很好奇是否有更好的方法。最小表的基数约为 100.000 行，最大的表约为 100.000.000 行：

import ibm_db
import ibm_db_dbi
...
conn = ibm_db_dbi.connect("...")
c1 = conn.cursor()

for schema in [ "S1", "S2", ... ]:
    for attribute in [ "a1", "s2", ...]:
        sql = f"""
            select * from {schema}.ATOM_ENTRY
            WHERE XMLEXISTS('$d//*:{attribute}[fn:matches(text(), $p, "i")]' 
                PASSING ENTRY_XML AS "d", CAST('\S*' AS VARCHAR(128)) as "p")
            fetch first 1 rows only
            optimize for 1 rows"""
        c1.execute(sql)
        exists = False
        for row in c1.fetchall():
            exists = True
        print(f"{schema}.ATOM_ENTRY -> {attribute} : {exists}")

作为迁移的一部分，我创建了一个新的缓冲池——比如 BP8K——大小为 8K，以及一个使用该 bp 的表空间，以及该表空间中的一个表，该表加载了数据。但是，我得到一个：

 SQL1218N There are no pages currently available in bufferpool "4097"

在那个过程中。看起来db2top好像使用默认缓冲池 IBMSYSTEMBP8K 而不是 BP8K 来解释这种现象。

当没有足够的共享内存来启动缓冲池时，我看到过类似的情况，但在这种情况下，BP8K 出现在db2top, 和db2pd -d ... -bufferpools. 也可以更改 bp 的大小，在内存不足的情况下，通常会导致缓冲池未启动的警告。

Adb2stop; db2start解决了问题，但这真的有必要吗？迁移是一个从升级框架运行的 sql 脚本，所以我宁愿不添加一些强制所有应用程序的钩子。想法？

db2level
DB21085I  This instance or install (instance name, where applicable: 
"db2inst1") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V11.5".

db2licm -l
Product name:                     "DB2 Enterprise Server Edition"
License type:                     "Restricted"
Expiry date:                      "Permanent"
Product identifier:               "db2ese"
Version information:              "11.5"
Max amount of memory (GB):        "128"
Max number of cores:              "16"

cat /proc/meminfo 
MemTotal:       164759044 kB
MemFree:         4267032 kB
MemAvailable:   131089520 kB

Mark Ba​​rinstein帮我确定缓冲池毕竟没有启动：

ADM6073W  The table space "TBSPC8K" (ID "9") is configured to use 
          buffer pool ID "3", but this buffer pool is not active at this time. 
          In the interim the table space will use buffer pool ID "4097".

大多数内存都设置为AUTOMATIC包括新的 BP，所以我不确定它为什么无法启动它。服务器上有大量可用内存，并且 db 正在使用 ~1.8Gb（主要是缓冲池）所以我不确定为什么 Db2 无法启动新的缓冲池。我尝试在创建 bp、tbspace 之后添加提交，但这没有帮助。

现在问题变成了：为什么 Db2 不能启动这个 BP。根据文档：

如果有足够的可用内存，缓冲池可以立即变为活动状态。默认情况下，使用 IMMEDIATE 关键字创建新的缓冲池，并且在大多数平台上，数据库管理器能够获取更多内存。

服务器上似乎有足够的内存可用。数据库在创建新表空间之前大致分配了 1.8Gb 内存。创建 bp 的语句如下所示：

CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K @
CREATE BUFFERPOOL BP16K SIZE AUTOMATIC PAGESIZE 16K @
CREATE BUFFERPOOL BP32K SIZE AUTOMATIC PAGESIZE 32K @
CREATE LARGE TABLESPACE TBSPC8K PAGESIZE 8K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP8K @
CREATE LARGE TABLESPACE TBSPC16K PAGESIZE 16K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP16K @
CREATE LARGE TABLESPACE TBSPC32K PAGESIZE 32K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP32K @

我在创建 bp、tbspace 后停止了脚本，强制所有应用程序，然后运行其余部分，结果很好。我没有从文档中得到那种印象，但也许必须这样做。

我db cfg memory config根据以下更新：

db2 update db cfg for <db> using SELF_TUNING_MEM ON
db2 update db cfg for <db> using DATABASE_MEMORY AUTOMATIC
db2 update db cfg for <db> using SORTHEAP AUTOMATIC
db2 update db cfg for <db> using SHEAPTHRES_SHR AUTOMATIC
db2 connect reset
db2 connect to <db>

并检查SEL_TUNING_MEMORY是否处于活动状态：

db2 get db cfg for <db> show detail | grep SELF

但我仍然遇到同样的问题。

恢复数据库后（即所有内存设置），我做了一个小测试：

~]$ cat test.sh 
#!/bin/sh

OPTS=`getopt -o d:u:p: -- "$@"`
eval set -- "$OPTS"

user=""
passwd=""
while true ; do
    case "$1" in
        -d) db="$2"; shift 2;;
        -u) user="$2"; shift 2;;
        -p) passwd="$2"; shift 2;;
        --) shift; break;;
    esac
done

db2 connect to $db user $user using $passwd
if [ $? -ne 0 ]; then
    exit 1
fi

db2diag -A

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K';
END
@"

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'CREATE LARGE TABLESPACE TBSPC8K PAGESIZE 8K MANAGED BY AUTOMATIC STORAGE BUFFERPOOL BP8K';
END
"

db2 +c -td@ "BEGIN
  DECLARE EXIT HANDLER FOR SQLWARNING
    SIGNAL SQLSTATE '75001' SET MESSAGE_TEXT = 'The bufferpool BP8K is not allocated';

  EXECUTE IMMEDIATE 'COMMIT';
END
"

db2diag -A

然后我运行了这个测试：

db2diag: Moving "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log"
         to     "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57"

DB20000I  The SQL command completed successfully.
DB20000I  The SQL command completed successfully.
DB20000I  The SQL command completed successfully.
db2diag: Moving "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log"
         to     "/opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57"

所以所有3条sql语句都成功了，但在diaglog中我发现：

2020-03-28-12.20.57.162214+060 I1800E409             LEVEL: Event
PID     : 5301                 TID : 140165787223936 PROC : db2diag
INSTANCE: db2inst1             NODE : 000
HOSTNAME: gollum
FUNCTION: DB2 UDB, RAS/PD component, pdDiagArchiveDiagnosticLog, probe:88
CREATE  : DB2DIAG.LOG ARCHIVE : /opt/nya/users/db2inst1/sqllib/db2dump/DIAG0000/db2diag.log_2020-03-28-12.20.57 : success
IMPACT  : Potential

2020-03-28-12.20.57.228408+060 E2210E868             LEVEL: Warning
PID     : 17468                TID : 140189351536384 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : STUDERA
APPHDL  : 0-637                APPID: *LOCAL.db2inst1.200328112127
UOWID   : 1                    ACTID: 4
AUTHID  : DB2INST1             HOSTNAME: gollum
EDUID   : 2442                 EDUNAME: db2agent (STUDERA) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbAssignBufferPool, probe:2
MESSAGE : ADM6073W  The table space "TBSPC8K" (ID "9") is configured to use 
          buffer pool ID "3", but this buffer pool is not active at this time. 
          In the interim the table space will use buffer pool ID "4097".  The 
          inactive buffer pool should become available at next database startup 
          provided that the required memory is available.

2020-03-28-12.20.57.272773+060 I3079E557             LEVEL: Info
PID     : 17468                TID : 140189351536384 PROC : db2sysc 0
INSTANCE: db2inst1             NODE : 000            DB   : STUDERA
APPHDL  : 0-637                APPID: *LOCAL.db2inst1.200328112127
UOWID   : 1                    ACTID: 5
AUTHID  : DB2INST1             HOSTNAME: gollum
EDUID   : 2442                 EDUNAME: db2agent (STUDERA) 0
FUNCTION: DB2 UDB, buffer pool services, sqlbCreateBufferPoolAct, probe:98
MESSAGE : Creating bufferpool "BP8K" Size: "1000"  <automatic>

底线，我不知道如何检测缓冲池是否启动。

test.sh在（以及我的原始脚本）中提交每个语句，成功，并且在 diaglog 中没有条目。尽管这似乎解决了问题，但我还在创建缓冲池后添加了延迟：

CREATE BUFFERPOOL BP8K SIZE AUTOMATIC PAGESIZE 8K @

-- delay commit
BEGIN
    DECLARE now TIMESTAMP;
    DECLARE end TIMESTAMP;
    SET now = TIMESTAMP(GENERATE_UNIQUE());
    SET end = now + 5 seconds;
    WHILE (now < end) DO
        SET now = TIMESTAMP(GENERATE_UNIQUE());
    END WHILE;
END @

这是我的实验室机器，上面几乎没有其他活动。

我正在研究自适应压缩。我似乎找不到任何关于在压缩表然后重新组织时 HADR 受到影响的信息：编辑。例子

t=mytable
db2 "alter table $t compress yes adaptive";
for i in $(db2 -x "select rtrim(indschema) || '.' || rtrim(indname) from syscat.indexes where rtrim(tabschema) || '.' || rtrim(tabname) = '${t}' order by 1"); do
    db2 "alter index $i compress yes"
done

db2 "reorg table $t resetdictionary";
db2 "reorg indexes all for table $t"
db2 "runstats on table $t with distribution and sampled detailed indexes all";

问题是我是否需要在此过程中关闭 HADR 并在完成后重新启动它，还是在日志中捕获所有内容，以便 HADR 可以继续？

似乎只有前 n 个字符用作 varchar/vargraphic 列的 colvalue。从我下面的测试来看，它似乎是 33/16。长度是否记录在某处？我试图搜索文档，但找不到任何东西（可能是搜索错误的东西）

简单的测试用例：

DROP TABLE LEJO0004.T;
CREATE TABLE LEJO0004.T (
        ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY 
            ( START WITH 1 INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 NO CYCLE CACHE 20 NO ORDER ),
        TCOL_C VARCHAR(64) NOT NULL,
        TCOL_G VARGRAPHIC(64) NOT NULL
);

insert into LEJO0004.T (tcol_c, tcol_g)
with n100 (n) as ( values 0 union all select n+1 from n100 where n<100 )
   , n10  (n) as ( values 0 union all select n+1 from n10 where n<10 )
   , n1   (n) as ( values 0 )
select 'commons.domain.regel.avbrottsregel'
     , 'commons.domain.regel.avbrottsregel'
from n100
union all
select 'commons.domain.regel.grupp.overfors.nya.endast.som.merit'
     , 'commons.domain.regel.grupp.overfors.nya.endast.som.merit'
from n10
union all
select 'commons.domain.regel.ingar.i.grupp.overfors.till.nya'
    ,  'commons.domain.regel.ingar.i.grupp.overfors.till.nya'
from n1;

runstats on table lejo0004.T with distribution on all columns;

select cast(colname as varchar(15))
    ,  type
    ,  seqno
    ,  cast(colvalue as varchar(40))
    ,  valcount
from sysstat.COLDIST
where tabschema = 'LEJO0004'
  and tabname = 'T'
  and colname in ('TCOL_C', 'TCOL_G')
  and colvalue is not null
  and type = 'F'
order by type, colname, seqno;

结果是：

TCOL_C  F 1 'commons.domain.regel.avbrottsrege' 101
TCOL_C  F 2 'commons.domain.regel.grupp.overfo'  11
TCOL_G  F 1 g'commons.domain.r'                 113

Q似乎是一样的

values char_length(g'commons.domain.r' using codeunits32)
16

values char_length('commons.domain.regel.avbrottsrege' using codeunits32)
33

测试：

db2level
DB21085I  This instance or install (instance name, where applicable: 
"lejo0004") uses "64" bits and DB2 code release "SQL11050" with level 
identifier "0601010F".
Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", 
and Fix Pack "0".
Product is installed at "/home/lejo0004/sqllib".

在尝试回答从现有字符串列（整数编码？）创建整数 id 列时，结果发现我需要自己的 postgres 版本才能使用。我已经安装了一个不错的 postgres 版本：

stack=# select version();
                                                version                         

--------------------------------------------------------------------------------
------------------------
 PostgreSQL 11.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (R
ed Hat 9.1.1-1), 64-bit

但它没有 pgcrypto 模块：

stack=# CREATE EXTENSION pgcrypto;
ERROR:  could not open extension control file "/usr/pgsql-11/share/extension/pgcrypto.control": No such file or directory

所以我安装了：

sudo dnf install postgresql-contrib 

但我仍然得到同样的错误。如果我查看：

]$ ls /usr/pgsql-11/share/extension/
plpgsql--1.0.sql  plpgsql.control  plpgsql--unpackaged--1.0.sql

我需要安装任何其他软件包，还是我缺少其他东西？

更新：

rpm -qa postgresql\* 
postgresql-contrib-11.3-1.fc30.x86_64 
postgresql11-11.4-1PGDG.f30.x86_64 
postgresql-11.3-1.fc30.x86_64 
postgresql11-server-11.4-1PGDG.f30.x86_64 
postgresql11-libs-11.4-1PGDG.f30.x86_64 

我收到 dnf install postgresql11-contrib 错误：

[...] 无法同步 repo 'fedora-modular' 的缓存错误：无法同步 repo 'fedora-modular' 的缓存

pdgd 似乎是最新可用的：

rpm -qa | grep pgdg-fedora
pgdg-fedora-repo-42.0-4.noarch

更新2：

显然有些事情暂时停止了，它现在可以：

sudo dnf install postgresql11-contrib
[...]
Downloading Packages:
postgresql11-contrib-11.4-1PGDG.f30.x86_64.rpm  285 kB/s | 602 kB     00:02    

rpm -qa postgresql\*
postgresql-contrib-11.3-1.fc30.x86_64
postgresql11-11.4-1PGDG.f30.x86_64
postgresql11-contrib-11.4-1PGDG.f30.x86_64
postgresql-11.3-1.fc30.x86_64
postgresql11-server-11.4-1PGDG.f30.x86_64
postgresql11-libs-11.4-1PGDG.f30.x86_64

stack=# CREATE EXTENSION pgcrypto;
CREATE EXTENSION