HANA 中的 ADBC 临时 table

ADBC temporary table in HANA

我在 ABAP 中使用 ADBC 创建了一个临时 table 并用所需的数据填充它们而不是使用内部 table 因为我们正在处理的大数据导致性能问题报道。处理后,我总是删除我创建的临时 table。我的问题是,如果我们经常使用这种方法,服务器会不会有问题?

比如当 100 名员工使用同时处理 350,000 多条记录的程序时,这对服务器是否不利? 请赐教。

提前致谢!

编辑:
记录将显示在 ALV

代码如下: tmp_table 是临时 table 名称的变量 autoid是序列名的变量

   sql->execute_ddl( |CREATE SEQUENCE { autoid } | &&
                      |START WITH    00001    | &&
                      |INCREMENT BY   1       | ).

    crte_txt = | CREATE TABLE { tmp_table } |  &&
               |( bid bigint NOT NULL ,   | && 
               |  contract char(50) ,     | && 
               |  swenr char(50),         | && 
               |  smenr CHAR(8),          | &&
               |  saltnr char(20),        | &&
               |  bp char(10),            | && 
               |  spsbp char(10),         | && 
               |  organization char(255), | && 
               |  n_first char(100),      | &&
               |  n_last char(100),       | && 
               |  n_mid char(100),        | && 
               |  addrnumber char(10),    | && 
               |  address char(1250),     | && 
               |  addr_type char(30),     | && 
               |  adr_kind char(10),      | && 
               |  email char(100),        | && 
               |  email2 char(100),       | && 
               |  wsl number(23,2),       | && 
               |  belnr char(10),         | && 
               |  belnr2 varchar(10),     | && 
               |  xblnr char(16),         | &&
               |  gjahr char(4),          | &&
               |  buzei char(3),          | &&
               |  pdescript char(120) null, | &&
               |  vbewa char(4),          | &&
               |  qbshb number(23,2),     | &&
               |  wrbtr1 number(23,2),    | &&
               |  wrbtr2 number(23,2),    | &&
               |  bktxt char(25),         | &&
               |  sgtxt char(50),         | &&
               |  checkno char(20),       | &&
               |  checkamnt number(23,2), | &&
               |  checkdate date,         | &&
               |  receiptdate date,       | &&
               |  role char(6),           | &&
               |  abp char(10),           | && 
               |  intreno char(30),       | &&
               |  agn_first char(100),    | && 
               |  agn_last char(100),     | && 
               |  agn_mid char(100),      | && 
               |  agn_org char(255),      | && 
               |  jv char(10),            | &&
               |  validfrom date,         | &&
               |  validto date,           | &&
               |  objnr char(22),         | &&
               |  condtype char(4),       | &&
               |  unitprice number(23,6), | &&
               |  termnopy char(4),       | &&
               |  ccnetamount number(15,2), | &&
               |  cctaxamount number(15,2), | &&
               |  condguid raw(16),      | &&
               |  PRIMARY KEY (bid) )     | .

 text = | INSERT INTO { dbbuyr } ( bid, contract, bp, addrnumber, adr_kind, swenr, smenr) | &&
             | SELECT ({ autoid }.nextval) as key, a.recnnr AS contract, b.partner AS bp, c.addrnumber, | &&
             | c.adr_kind, e.swenr, e.smenr | &&
             | FROM vicncn AS a | &&
             | INNER JOIN vibpobjrel AS b ON a.intreno = b.intreno | &&
             | INNER JOIN but021_fs AS c ON b.partner = c.partner  | &&
             | INNER JOIN jest AS d ON a.objnr = d.objnr| &&
             | INNER JOIN v_recncne as e on a.recnnr = e.recnnr |  &&
             | WHERE a.recndactiv <> 00000000 | &&
             | AND ( a.recntype = 'ZC01' OR a.recntype = 'ZC02' ) | &&
             | AND b.validfrom <= | && sy-datum && | AND b.validto >=  | && sy-datum &&
             | AND b.role IN ({ cond_role }) | && "( b.role = 'ZBP101' OR b.role = 'ZBP301' ) | &&
             | AND c.valid_to >= | && tmstmp && | AND c.valid_from <= | && tmstmp &&
             | AND d.stat IN ({ cond_stat }) | &&"= 'I0119' | &&
*             | AND e.swenr = '{ swenr }' | &&
             | { sw_cond } { re_cond } { sm_cond } | &&
             | AND e.validto >= { sy-datum } AND e.validfrom <= { sy-datum }| &&
             | AND a.mandt = b.mandt AND b.mandt = c.client AND c.client = d.mandt | &&
             | AND d.mandt = e.mandt AND e.mandt =  { sy-mandt } | .


      sql->execute_update( CONV #( text ) ).

这之后有很多更新语句来获取其他数据

sql->execute_ddl( |DROP SEQUENCE { autoid } | ). 
  sql->execute_ddl( |DROP TABLE { tmp_table } | ).

您的代码不会创建临时table作为数据库对象。 相反,它创建一个常规 table 和一个序列。

虽然这样的代码可以工作,但几乎没有必要,而且有几个缺点。

  1. table 名称必须是唯一的,以避免与代码的并行 运行ning 实例发生冲突。

  2. 因为这是一个常规数据库 table(而不是 临时 table 这个 table 将被覆盖在数据库目录和事务处理中。这意味着它会创建重做日志,这是完全没有必要的,因为这个 table 永远不必恢复。

  3. 作为 HANA 上的系统 运行,您可以使用数据库管理过程来执行海量数据处理。实际上,您可以在程序中使用包含 table 变量 的 HANA SQL脚本。 使用 table 变量,HANA 不需要在内存中创建 table 结构不需要处理变化的 table 名称,不 使用相同的 table 等跟踪多个会话。 使用 table 变量是更好的方法。

  4. 创建序列对象完全是无稽之谈,只是简单地枚举中间结果集中的记录。 为此,您可以简单地使用 ROW_NUMBER() window 函数。

  5. 由于您当前的代码在处理后也会销毁创建的对象,因此所有已解析的 SQL 语句都将失效。并且下次执行代码时将需要新的 parsing/compiling 语句。

  6. 对于 CREATE TABLE 语句,代码没有指定这应该是 COLUMN 还是 ROW table。由于这在 HANA 中有相当大的影响(您几乎总是想要一个 COLUMN table),因此 高度 推荐指定它。对于没有 table 类型规范的 HANA 1 和 HANA 2 CREATE TABLE 将创建一个 ROW table。不要听之任之。

您提到,实际处理代码将 运行 UPDATEs 对抗中间 table。在绝大多数情况下,UPDATE 可以替换为 SELECT 并分配给新的 table 变量。 这通常会导致更清晰和更快的代码,并避免 "row-by-row/slow-by-slow" 处理。

所以,是的,当前代码会对最终用户性能和服务器资源利用率产生负面影响。