）私は、5000レコードを返すビューを持つ結合（HANA 2 SP2のグラフィックカルビュー）でメモリダンプに入る28mnレコードのテーブルを持っています。私はSQLのユニオンをすべて試しましたが、それはまだ動作しません。ユニオンビューにはロジックがありません。SAP HANA OOMエラー（UNION
テーブル上の選択トップ1000は、<にデータを返し、5kレコードのビューは2秒でデータを返します。これらの2を論理なしで結合すると、集約ノードを投影に切り替えた後でも、まだメモリが足りなくなります。私はここで何が欠けていますか？
トランザクションが内部エラーによってロールバックされました：割り当てに失敗しました。 $ size $ = 2048; $ name $ = SearchAlloc; $ type $ = pool; $ inuse_count $ = 11184979; $ allocated_size $ = 20190632592; $ alignment $ = 16
特に "union"だけでなく "union all"でも多くのメモリを消費する可能性があります。初期のマテリアライゼーションが内部的に使用されるとき。私は数日前に「ユニオンすべて」が130GBの一時メモリを消費したケースを持っていました。組合を2つのステートメントに分割した後、最大メモリ消費量は11GBにまで減少しました！ アプリケーションが許可している場合は、この方法をお試しください。 Larsのアドバイスに従って、planvizとunion allとsplit文を比較してください。参考のためにSAPノートを以下
チェック： https://launchpad.support.sap.com/services/pdf/notes/1999997/E
19 ....これらの操作は、カラムエンジンによって処理など最適化することができない
以外は同様にして「Avgoid UNION ALL、UNION、INTERSECT、 （UNIONまたはUNION ALLの代わりにOR）...
いつものように、後半のマテリアライゼーション（SAPノート1975448）は不可能なので、メモリ要件が大幅に増加する可能性がありますそれはあなたのユースケースなどに依存します。
問合せの実行の違いを理解するための最初の手順は、EXPLAIN PLANと両方の文のPlanViz（トレース）を確認することです。 私の推測では、SELECT TOP 1000のみが最終結果セットに適用され、2つのサブクエリ/ calcのUNION ALLが適用されます。それ以前にビューを完全に実現する必要があります。そのような場合は、UNION操作の前にデータサイズを制限することを検討することがあります。 –