Reputation: 93
I have just moved from SQL Server to ORACLE, and I am working on a script (SQL Server style). In SQL Server, we use BEING TRAN - END TRAN after applying some logic in a script. And this can be done inside a BEGIN-END block. In Oracle, I am finding this a bit difficult. After a lot of Googling and searching on this site, I am still not clear on how can I met this requirement.
When I ran the script (pasted below), this ran as one transaction. And DBMS_OUTPUT.Put_line also displays once the whole script is executed. Is there any way to print the DBMS_OUTPUT.Put_line after each and every commit?
Also, I am open to ideas, if there's any other way to work on this script, so that every sub-query commits before the script moves to the next sub-query... Please let me know.
Here's my script:
SET SERVEROUTPUT ON;
--spool Consolidated.log;
WHENEVER SQLERROR EXIT SQL.SQLCODE;
SET DEFINE OFF;
ALTER SESSION SET GLOBAL_NAMES=FALSE;
DECLARE
ExtractType NUMBER(9);
RecordsExtracted NUMBER(9);
CurStatus NUMBER(9);
StartDate date;
ErrorMessage NVARCHAR2(1000);
LastExtrctTimestamp DATE;
BEGIN
-- AgreementTradeTypes
StartDate := sysdate;
ExtractType := 44;
DELETE FROM AgreementTradeTypes;
INSERT INTO AgreementTradeTypes (AgreementId,AgreementName,PrincipalId,Principal,CounterpartyId,Counterparty, TradeTypeId,TradeTypeName,BusinessLine,AdditionalCriteria)
-- From CORE DB
SELECT
IATT.AgreementId, AG.AgreementName, IATT.PRINCIPALID, Principal.ENTITYNAME Principal,
IATT.COUNTERPARTYID, Cpty.ENTITYNAME Counterparty,
IATT.TradeTypeID, TT.TradeTypeName, BusLine.ENUMTEXT BusinessLine, IATT.ADDITIONALCRITERIA
FROM IncludedAgreementTradeTypes@RPTCORE IATT
INNER JOIN Entities@RPTCORE Principal ON IATT.PRINCIPALID = Principal.ENTITYID
INNER JOIN Entities@RPTCORE Cpty ON IATT.CounterpartyId = Cpty.ENTITYID
INNER JOIN EnumValues@RPTCORE BusLine ON IATT.BusinessLine = BusLine.ENUMVALUE AND BusLine.ENUMTYPE = 'BusinessLine'
INNER JOIN Agreements@RPTCORE AG ON IATT.AGREEMENTID = AG.AgreementID
INNER JOIN TradeTypes@RPTCORE TT ON IATT.TRADETYPEID = TT.TradeTypeID
ORDER BY IATT.AgreementId;
RecordsExtracted := SQL%RowCount;
DBMS_OUTPUT.put_line('AgreementTradeTypes Records Extracted:' || RecordsExtracted);
-- On Success
CurStatus := 2;
ErrorMessage := 'AgreementTradeTypes Complete';
INSERT INTO ExtractRecords(ExtractType, RecordsExtracted, Status, ExtractTimestamp, StartDate, EndDate, ErrorMessage)
VALUES (ExtractType, RecordsExtracted, CurStatus, SysDate, StartDate, SysDate, ErrorMessage);
INSERT INTO LoadRecords (LoadType,Status,LoadTimestamp,StartDate,EndDate)
VALUES (ExtractType, CurStatus, SysDate, StartDate, SysDate);
COMMIT; /* Committing first Block */
-- INTEREST PAYMENT PERIODS
StartDate := sysdate;
ExtractType := 57;
DELETE FROM InterestPaymentPeriods;
INSERT INTO InterestPaymentPeriods (InterestPaymentPeriodId,AgreementId,AgreementName,CurrencyId,CurrencyName,InstrumentId,InstrumentName,PositionType,CollateralMarginType,PeriodStart,PeriodEnd,NextPeriodEnd,AccruedInterest,OpeningBalance,EndingBalance,MarketIndexId,MarketIndexName,Spread,DayCountConvention,CalculationType,ManagingLocation,BusinessLine)
-- From CORE DB
SELECT
IPP.INTERESTPAYMENTPERIODID, IPP.AGREEMENTID, AG.AGREEMENTNAME, IPP.CURRENCYID, CUR.CODE CurrencyName, IPP.INSTRUMENTID,
Instruments.DESCRIPTION InstrumentName, PosType.ENUMTEXT PositionType, CollMargType.ENUMTEXT CollateralMarginType,
IPP.PERIODSTART, IPP.PERIODEND, IPP.NEXTPERIODEND, IPP.ACCRUEDINTEREST, IPP.OPENINGBALANCE, IPP.ENDINGBALANCE,
IPP.MARKETINDEXID, MI.MARKETINDEXNAME, IPP.SPREAD, DCC.ENUMTEXT DayCountConvention, CalcType.ENUMTEXT CalculationType,
Cty.CITYNAME ManagingLocation, BusLine.ENUMTEXT BusinessLine
FROM
INTERESTPAYMENTPERIODS@RPTCORE IPP
INNER JOIN Agreements@RPTCORE AG ON IPP.AGREEMENTID = AG.AGREEMENTID
LEFT OUTER JOIN Currencies@RPTCORE CUR ON IPP.CURRENCYID = CUR.CURRENCYID
LEFT OUTER JOIN Cities@RPTCORE Cty ON IPP.MANAGINGLOCATIONID = Cty.CITYID
LEFT OUTER JOIN MarketIndexes@RPTCORE MI ON IPP.MARKETINDEXID = MI.MARKETINDEXID
LEFT OUTER JOIN Instruments@RPTCORE ON IPP.INSTRUMENTID = Instruments.INSTRUMENTID
LEFT OUTER JOIN EnumValues@RPTCORE PosType ON IPP.POSITIONTYPE = PosType.ENUMVALUE AND PosType.ENUMTYPE = 'PositionType'
LEFT OUTER JOIN EnumValues@RPTCORE CollMargType ON IPP.COLLATERALMARGINTYPE = CollMargType.ENUMVALUE AND CollMargType.ENUMTYPE = 'CollateralMarginType'
LEFT OUTER JOIN EnumValues@RPTCORE DCC ON MI.DAYCOUNTCONVENTION = DCC.ENUMVALUE AND DCC.ENUMTYPE = 'DayCountConvention'
LEFT OUTER JOIN EnumValues@RPTCORE CalcType ON IPP.CALCULATIONTYPE = CalcType.ENUMVALUE AND CalcType.ENUMTYPE = 'CalculationType'
LEFT OUTER JOIN EnumValues@RPTCORE BusLine ON IPP.BUSINESSLINE = BusLine.ENUMVALUE AND BusLine.ENUMTYPE = 'BusinessLine';
RecordsExtracted := SQL%RowCount;
DBMS_OUTPUT.put_line('InterestPaymentPeriods Records Extracted:' || RecordsExtracted);
-- On Success
CurStatus := 2;
ErrorMessage := 'Interest_Payment_Periods Complete';
INSERT INTO ExtractRecords(ExtractType, RecordsExtracted, Status, ExtractTimestamp, StartDate, EndDate, ErrorMessage)
VALUES (ExtractType, RecordsExtracted, CurStatus, SysDate, StartDate, SysDate, ErrorMessage);
INSERT INTO LoadRecords (LoadType,Status,LoadTimestamp,StartDate,EndDate)
VALUES (ExtractType, CurStatus, SysDate, StartDate, SysDate);
COMMIT; /* Committing Second Block */
END;
--spool off;
/
Upvotes: 1
Views: 20081
Reputation: 10541
The results of DBMS_OUTPUT will only be displayed after completion of the PL/SQL block. DBMS_OUTPUT and COMMIT are not related to one another. If you can split your script into multiple blocks you can get the results of each block committed and printed before the next block starts.
begin
-- step 1
insert
commit ...
dbms_output ...
end;
/
begin
-- step 2
insert...
commit ...
dbms_output ...
end;
/
Upvotes: 0
Reputation: 191435
The data will be committed in two stages. The DECLARE
/BEGIN
/END
denote the start and end of an anonymous PL/SQL block, not a transaction. If you didn't have a commit inside the block (which would be more normal; it's somewhat unusual to have transaction control inside a block) at all, then after the block completes none of your changes would have been committed - you could still roll back if you wanted to.
Your DBMS_OUTPUT calls put messages into a buffer, which the client (e.g SQL*Plus) retrieves and displays after the block completes. There is no way around that - you can't get 'live' updates using that mechanism. There are alternatives, such as using UTL_FILE
or setting module information for the session that can be viewed from another session, but that's probably overkill for what you seem to be doing.
If you just want to see the message after each section you can split it into two anonymous blocks. The downside of that is perhaps having to declare variables twice, and that they will go out of scope between the blocks - so something you set in the first block won't be visible in the second. You could perhaps work around that using bind variables, via the SQL*Plus variable
command.
You don't really seem to need to do this in PL/SQL at all, at least in this example, though you said you would be applying some logic in the script at well. If that's not really the case then you could use simple SQL statements, substitution variables and prompt to achieve this, without using PL/SQL at all. Apart from the row counts, which are a little tricky unless you're happy just with the normal set feedback on
display, like '3 rows inserted'.
Upvotes: 1
Reputation: 52376
The usual practice in Oracle is to commit only when the business transaction is complete, so that a transaction is not part-processed. This differs from some others systems because Oracle's multiversioning and locking systems ensure that writers do not block readers and readers do not block writers.
For the DBMS_Output issue, no you cannot get a response from the server through DBMS_Output partway through the block's execution. You might like to look at writing data to a serverside file using Utl_File for that.
Other thoughts:
Consider using TRUNCATE instead of DELETE if you're deleting every row AND you do not need to use foreign keys against that table. TRUNCATE has an implicit commit associated with it, so apply all your truncates at the beginning of the procedure.
Consider using the APPEND hint on the inserts to invoke direct path insert if you are loading bulk data, have indexes to maintain, and do not need to allow multiple simultaneous inserts into the table.
I'm guessing that the ORDER BY on the inserts is there for a reason -- usually in Oracle it would be to ensure that data rows are physically clustered on the order-by column(s), which leads to greater efficiency on index-based access via those columns. Using a direct path insert would help guarantee physical row ordering, but if you don't need that clustering then remove the ORDER BY
Upvotes: 5