database - HANA 中的 ADBC 临时表
问题描述
我在 ABAP 中使用 ADBC 创建了一个临时表,并用所需的数据填充它们,而不是使用内部表,因为我们正在为报告处理大数据导致性能问题。处理后,我总是删除我创建的临时表。我的问题是,如果我们经常使用这种方法,服务器会有什么问题吗?
就像 100 名员工使用同时处理 350,000 多条记录的程序时,这对服务器是否有害?请赐教。
提前致谢!
编辑:
记录将显示在 ALV
代码如下: tmp_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 } | ).
解决方案
您的代码不会将临时表创建为数据库对象。相反,它会创建一个常规表和一个序列。
虽然这样的代码可以工作,但它几乎没有必要并且有几个缺点。
表名必须是唯一的,以避免与并行运行的代码实例发生冲突。
由于这是一个常规数据库表(而不是临时表,该表将包含在数据库目录和事务处理中。这意味着,它将创建重做日志,这是完全没有必要的,因为该表永远不必恢复了。
当您的系统在 HANA 上运行时,您可以使用数据库管理程序来执行海量数据处理。实际上,您可以在过程中使用包含表变量的HANA SQLScript 。使用表变量,HANA 不需要创建内存中的表结构,不需要处理更改的表名,不需要跟踪使用同一个表的多个会话等。使用表变量是这里更好的方法。
简单地枚举中间结果集中的记录,创建一个序列对象完全是无稽之谈。为此,您可以简单地使用
ROW_NUMBER()
窗口函数。由于您当前的代码在处理后还会销毁创建的对象,因此所有已解析的 SQL 语句都将失效。并且下次执行代码时将需要对语句进行新的解析/编译。
使用该
CREATE TABLE
语句,代码没有指定这应该是 COLUMN 表还是 ROW 表。由于这在 HANA 中具有相当大的影响(您几乎总是需要一个 COLUMN 表),因此强烈建议您指定它。使用没有表类型规范的 HANA 1 和 HANA 2 CREATE TABLE 将创建一个 ROW 表。不要把它留给机会。
您提到,实际的处理代码将UPDATEs
针对中间表运行。在绝大多数情况下,anUPDATE
可以替换为 aSELECT
并赋值给一个新的表变量。这通常会导致代码更清晰、更快,并避免“逐行/逐个慢”处理。
所以,是的,当前代码将对最终用户性能和服务器资源利用率产生负面影响。
推荐阅读
- mysql - SQL:使用单个查询依靠不同的 where 案例
- java - Java servlet:RequestDispatcher 不工作不重定向路径
- c++ - C++ 结构数组
- dart - 右对齐而不调整父级
- html - (CSS) 如何更改多级列表中每隔一个元素的样式规则?
- mysql - 如何在不输入root密码的情况下登录mysql?
- python - 使用经过训练的 RNN 进行预测时出现“内核已使用”错误
- android - Android O 蓝牙扫描限制已达到问题
- python - 如何在 mac 上的 python 中导入非标准包?此软件包不支持 pip install
- c - 相等比较 DBL_MIN 或 DBL_MAX 是否安全?