/*+ APPEND PARALLEL */ implementation in a oracle SQL [closed] - sql

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I will like to understand what does exactly the /*+ APPEND PARALLEL(TEST,12) */, it is a improve but I'm not really sure what it does.
--FIRST SQL
insert into TEST
select ORDER_DATE , ORDER_NO , ORDER_INV_LINE , CUSTOMER_NO , ORDER_INV_LINE_TYPE , ORDER_INV_LOC_CD , CUST_REF_NO , GROUP_ACCT_NO , SELL_STYLE , RCS_CD , GRADE
, INV_STYLE_NO , DISCOUNT_CD , CREDITED_SELL_CO , DELI_VEHICLE_CD , QUANTITY , GROSS_AMT , REBATE_NET_AMT , nvl(TERM_SAVG_AMT,TERMS_AVG_AMT) , TERMS_AMT , UNIT_PRICE , DISCOUNT_AMT
, COMM_LOAD , DELIVERED_FRT_AMT , CREDITED_DISTRICT_ID , INVOICE_NO , INVOICE_DATE , INVOICE_MONTH , SELL_COLOR , WIDTH_FT , WIDTH_IN , LENGTH_FT , LENGTH_IN , ROLL_NO
, ACTUAL_DUTY , GST_AMT , BROKERAGE_FEE , CRED_REGION_ID , TERMS_PCT , CRED_TERRITORY_ID , WHSE_UPCHARGE , OVERBILL_A_AMOUNT , OVERBILL_B_AMOUNT , OVERBILL_C_AMOUNT , OVERBILL_D_AMOUNT
, OVERBILL_E_AMOUNT , OVERBILL_F_AMOUNT , OVERBILL_G_AMOUNT , OVERBILL_H_AMOUNT , OVERBILL_I_AMOUNT , TERMS_CD , ORDER_LINE_STATUS_CD , NET_UNIT_PRICE , INV_FOB_COST , NET_SALES_AMT_CCA
, NET_UNIT_PRICE_CCA , INVOICE_PAID_FLAG , DISC_FLAG , NVL(BUILDER_NO,BUILDER_NUMBER) , BUILDER_NAME , SUB_DIVISION , BLOCK_NBR , LOT , PROJECT_NAME , INV_PRICING_UOM , PRO_ROLL_OVB , PRO_CUT_OVB , EFF_DATE
, EXP_DATE, CCA_PROGRAM, OVBG_FLAG, REBATE_NET_AMTCN, sysdate as ARCHIVE_DATE, ENDUSER_CODE, ENDUSER_NAME, SELL_BUSINESS_GRP, SALES_MIX_GRP, BUSINESS_GRP_CAT, MIX_GRP_CAT, BDF_GROUP
FROM SCHEMA.prestg_order_invoices poi
WHERE NOT EXISTS (
SELECT 1
FROM SCHEMA.TEST ar
WHERE ar.order_no = poi.order_no
and nvl(ar.invoice_no, 'XYZ') = nvl(poi.invoice_no, 'XYZ')
and ar.order_inv_line = poi.order_inv_line)
----
--SQL MODIFIED
insert /*+ APPEND PARALLEL(TEST,12) */ into TEST
select /*+ PARALLEL(poi,12) */ ORDER_DATE , ORDER_NO , ORDER_INV_LINE , CUSTOMER_NO , ORDER_INV_LINE_TYPE , ORDER_INV_LOC_CD , CUST_REF_NO , GROUP_ACCT_NO , SELL_STYLE , RCS_CD , GRADE
, INV_STYLE_NO , DISCOUNT_CD , CREDITED_SELL_CO , DELI_VEHICLE_CD , QUANTITY , GROSS_AMT , REBATE_NET_AMT , nvl(TERM_SAVG_AMT,TERMS_AVG_AMT) , TERMS_AMT , UNIT_PRICE , DISCOUNT_AMT
, COMM_LOAD , DELIVERED_FRT_AMT , CREDITED_DISTRICT_ID , INVOICE_NO , INVOICE_DATE , INVOICE_MONTH , SELL_COLOR , WIDTH_FT , WIDTH_IN , LENGTH_FT , LENGTH_IN , ROLL_NO
, ACTUAL_DUTY , GST_AMT , BROKERAGE_FEE , CRED_REGION_ID , TERMS_PCT , CRED_TERRITORY_ID , WHSE_UPCHARGE , OVERBILL_A_AMOUNT , OVERBILL_B_AMOUNT , OVERBILL_C_AMOUNT , OVERBILL_D_AMOUNT
, OVERBILL_E_AMOUNT , OVERBILL_F_AMOUNT , OVERBILL_G_AMOUNT , OVERBILL_H_AMOUNT , OVERBILL_I_AMOUNT , TERMS_CD , ORDER_LINE_STATUS_CD , NET_UNIT_PRICE , INV_FOB_COST , NET_SALES_AMT_CCA
, NET_UNIT_PRICE_CCA , INVOICE_PAID_FLAG , DISC_FLAG , NVL(BUILDER_NO,BUILDER_NUMBER) , BUILDER_NAME , SUB_DIVISION , BLOCK_NBR , LOT , PROJECT_NAME , INV_PRICING_UOM , PRO_ROLL_OVB , PRO_CUT_OVB , EFF_DATE
, EXP_DATE, CCA_PROGRAM, OVBG_FLAG, REBATE_NET_AMTCN, sysdate as ARCHIVE_DATE, ENDUSER_CODE, ENDUSER_NAME, SELL_BUSINESS_GRP, SALES_MIX_GRP, BUSINESS_GRP_CAT, MIX_GRP_CAT, BDF_GROUP
FROM SCHEMA.prestg_order_invoices poi
WHERE NOT EXISTS (
SELECT 1
FROM SCHEMA.TEST ar
WHERE ar.order_no = poi.order_no
and nvl(ar.invoice_no, 'XYZ') = nvl(poi.invoice_no, 'XYZ')
and ar.order_inv_line = poi.order_inv_line)

Answer 1

APPEND or PARALLEL hints invoke direct path load. This means blocks are allocated from above the HWM (high water mark). That is, blocks that do not, and never have had any rows in them. For that reason, Oracle does not generate UNDO. (There's no need for a 'before image', since the 'before image is that the block didn't exist in the segment.) Redo is still generated for direct path load, unless NOLOGGING is also set.
it isn't necessarily always faster in general. It does a direct path load to disk - bypassing the buffer cache. There are many cases - especially with smaller sets - where the direct path load to disk would be far slower than a conventional path load into the cache.
Also, you cannot query a table after direct pathing into it until you commit or rollback. And also consider the fact that one and only one user can direct path into a table at a time. It would cause all modifications to serialize. No one else could insert/update/delete or merge into this table until the transaction that direct paths commits.