Standard template for internal and external presentations Journal on i/OS

108 pages
12 views

Please download to get full document.

View again

of 108
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Standard template for internal and external presentations Journal on i/OS. 2009.10.15 김 교 석 MTS, IBM Korea. Journal 개요. Journal Basic. Journal Objects DB Objects: Physical Files, Access Paths Data Areas, Data Queues IFS Objects Journal 마치 깔때기와 같은 역할
Transcript
Standard template for internal and external presentationsJournal on i/OS2009.10.15김 교 석MTS, IBM KoreaJournal 개요 Journal Basic
  • Journal Objects
  • DB Objects: Physical Files, Access Paths
  • Data Areas, Data Queues
  • IFS Objects
  • Journal
  • 마치 깔때기와 같은 역할
  • 각각의 object들과 journal entry들의 연결고리
  • 그 크기가 증가하지는 않는다,
  • Journal Receiver
  • Journal entry들을 저장하는 곳
  • Audit관련 내용을 제공
  • 크기가 증가함에 따라 관리 필요
  • SMAPP
  • SMAPP (System Managed Access Path Protection)
  • System이 자동으로 지정된 Access Path Rebuild Time에 따라 커다란 AP들을 Journaling하는 기능
  • System의 Outage시 새로 Rebuild하는 대신 Journal을 이용해 Access Path들을 복구
  • Runtime vs. IPL (IASP vary-on)
  • EDTRCYAP 명령어를 이용해 원하는 AP 복구시간을 지정할 수 있다.
  • SMAPP 고려사항
  • Rebuild Time을 너무 크게 지정하지 말 것
  • 만약 PF가 Journal되고 있다면, AP entry는 User Journal에 저장된다.
  • User Journal에 쌓이는 SMAPP entry에 의해 사용되는 량을 줄이기 위해서 RCVSIZOPT(*RMVINTENT)를 사용한다
  • Minimize Aps that are ineligible for SMAPP
  • EDTRCYAPRemote Journal
  • Source에서 Target으로 Journal entry를 빠르고 효과적으로 보낸다.
  • O/S의 SLIC Layer에서 수행되는 기능
  • Remote Journal이 적용되면, Receiver에 있던 모든 Entry들이 가장 효율적인 “Catch-up” Mode로 보내진다.
  • 일단 Catch-up되어진 후, Synchronous또는 Asynchronous 전달Mode를 이용해 전송된다.
  • Remote Journal
  • Asynchronous Mode
  • Source쪽의 Disk에 entry를 저장한 후 Target에 보낸다.
  • Sending task는 충분하지 않은 Communication Bandwidth등의 이유로 실패할 수도 있는데, 이럴 경우는 좀더 효율적인 Mode로 자동으로 보내게 된다.
  • 만약 Source쪽이 Crash되었을 경우, 각 Entry가 제대로 Target에 적용되었는지 확실하지 않다.
  • Target System에 Entry들을 보내는 작업이 지연된다 하여도 Source System의 성능에는 영향이 없다.
  • Synchronous Mode
  • Source System에서 Entry를 Disk에 쓰기 전에, Target에 Entry를 보내고 Response를 받는다.
  • 따라서, Source가 Crash되더라도 Entry들이 Target에 적용되었음을 Guarantee할 수 있다.
  • Target never falls behind
  • Source system performance can be impacted if insufficient communication bandwidth
  • Remote Journal
  • Remote Journal사용시 고려사항
  • 두 시스템간의 Communication bandwidth가 충분해야 한다.
  • To test the throughput between systems, activate remote journal with an existing journal receiver which will run in “catch-up” mode and give an upper bound on the rate of transfer between systems
  • Internal SMAPP Entries의 전송을 막기 위해 RCVSIZOPT(*RMVINTENT)로 Setting
  • Network문제로 인해 remote journal이 중단되거나 비효율적으로 작동할 수 있으므로 NETSTAT command를 사용하여 Retransmissions이 얼마나 일어나나 확인한다.
  • Journal Attribute
  • 모든 journals에 대해 아래 값들을 설정하도록 한다.
  • RCVSIZOPT(*RMVINTENT)
  • User journal에서 internal SMAPP entries에 의해 사용되는 공간을 최소화
  • Remote Journal을 사용할 경우 Internal SMAPP Entries를 보내는 overhead를 줄일 수 있다.
  • RCVSIZOPT(*MAXOPT2)
  • 좀 더 큰 maximum sequence number
  • 좀 더 큰 maximum receiver size
  • 좀더 많은 Disk Arm들에 Receiver의 Data들을 분산시킬 수 있다.
  • Internal entries의 재 사용을 위한 추가 space를 제공한다.
  • 성능 개선효과 및 다른 function들의 maximums을 증가시킬 수 있다.
  • Journal 성능 관련 10가지 질문 과연 Journal을 제대로 알고 사용하고 있는가 !Block들을 쌓는 것과 같다... Larry그리고 함께 사용할 2개의 Tool들...C ProgramsSQLQueries사용할 3개의 Block들은...때론 이것들을 함께 묶어서...Collection ServicesPex TracesDSPJRNi5/OS has a richer journal Journal Optimization에 사용될 Block들
  • DSPJRN to an OUTFILE
  • DSPJRN JRN(LIB/JRN) OUTPUT(*OUTFILE) OUTFILFMT(*TYPE5)
  • OUTFILE(LIB/OUTFILE)
  • Run Collection Services
  • Performance Tools(5722-PT1)이 설치되어 있다면 Collection Services 시작
  • GO PERFORM
  • Select Option 1 to start collection services.
  • API CALL
  • CALL QYPSSTRC PARM('*PFRxxxxxx' '*STANDARDP' X'00000000') (xxxxxx는 Space 6자리)
  • Run Performance Explorer
  • 1) Use the ADDPEXDFN command to add a PEX definition which will collect Journal Events2) Start PEX using the STRPEX command and specify the PEX definition you created3) Run workload to be analyzed4) End PEX with the ENDPEX command and specify to output the data a user library5) Run the PARSEJOPEX program to parse the Journal Trace Point information이 Session에서 소개드릴 Tool및 Program source는 아래 URL에서 download가능합니다.: http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html아래와 같은 10가지 질문에 어떻게 답할 것인가? TopicClassic QuestionHow do I get Journal to use all my disk arms ?Disk ArmsDo I have enough to make Journal happy ?IOA Write CacheAre my settings and applications Journal-friendly ?BundlingHow can I tame the Commit tiger ?CommitToo may files serviced by a single journal ?BulliesHave I got journal entries I don’t need ?Discarding ChaffHow can I send less data to disk and target machine ?Skinny Jrn EntriesAm I failing to exercise good Jrn Housekeeping ?Full ClosesAre my Jrn background tasks gasping for breath ?Jrn Recovery RatioAre my Remote Jrn ASYNC sending tasks falling behind?Remote JournalQ1. Disk Arms– Journal이 Disk Arm들을 적절히 사용하고 있는가?일반적으로 Jrn Rcvr들은 여러 Disk Arms에 골고루 퍼져서 분포하지만, 과연 몇 개나 사용하고 있는가?JournalReceiverUser ASPJournal Receiver armsRound-robin use of disk arms..12.21Arm Number사용중인 Disk Arm은...
  • 현재 journal receiver가 몇 개의 disk arm을 사용하고 있는가?
  • Requirements
  • Journal Receiver should contain a sufficient number of entries to analyze
  • Journal Receiver가 사용하는 disk arm 갯수를 알아 내는 방법
  • 1) DSPJRNto an OUTFILE using *TYPE5 to obtain arm information
  • 2) Run the following SQL query to determine number of arms being used:
  • SELECT MAX(JOARM) from lib/outfile
  • ?Output:Number of Arms used for the ReceiverDSPJRN w/ *TYPE5Display Data Data width . . . . . . : 862 Position to line . . . . . Shift to column . . . . . . ...40....+...41....+...42....+...43....+...44....+...45....+...46....+...47.... RCVARM THREAD ADDRESS REMOTE REMOTE ASP NUMBER ID FAMILY PORT ADDRESSHEX 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 120000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 130000000000000000 0 0 1 3 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 14 0000000000000000 0 0 More... F3=Exit F12=Cancel F19=Left F20=Right F21=Split {{Query output Display Data Data width . . . . . . : 13 Position to line . . . . . Shift to column . . . . . . ....+....1... MAX ( JOARM )11 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Quantity of arms사용중인 Disk Arm은...
  • 왜 내가 생각한 만큼의 disk arm을 사용하지 않을까?
  • 아래 값들이 충분하지 않을 경우:
  • 1. Journal Threshold
  • 2. RcvSizOpt Setting을 MaxOpt1 로… (or higher)
  • ?충분한 Threshold를 가지고 있지 않다면 새 disk drive들은 사용하지 않고 남아있게 된다.만약 Journal Threshold가 너무 작다면??PFJournalThresholdIOP1Write CacheSystem ASPUser ASPUnusedAPJrn Rcvr armsPFJournal Receiver Thresholds
  • CRTJRNRCV ... THRESHOLD(1800000) { Means 1.8 Gig }
  • Note: Threshold 는 Kilobytes단위
  • 높은 Threshold로 Setting하게 되면:
  • 좀 더 많은 disk arms을 사용하게 된다.
  • 즉, Threshold의 매 64 Meg가 추가될 때마다 추가 disk arm을 사용하게 된다.
  • 그리고 좀 더 큰 bandwidth를 가지고 achieve 가능.
  • Capacity = *MaxOpt1ThresholdJournal Receiver Threshold와 Disk Arm의 상관관계Threshold# of Disk armsRcvSizOpt(*MaxOpt1)< 640 MBUp to 10Min704 MB11778 MB12.........100Max6.4 Gig100Threshold의 64MB 증가마다 additional arm이 더 사용됨Example:
  • CRTJRNRCV JrnRcv(MyLib/Rcv2) Threshold(70000000) { 70 Gig }
  • CRTJRN Jrn(MyLib/Jrn2) JrnRcv(MyLib/Rcv2) RcvSizOpt(*MaxOpt1) { Rqsts 1 TB max }
  • Journal Receiver thresholdsTakes bothCapacity = *MaxOpt1ThresholdBACKSystem의 IOA Write Cache를 가장 많이 사용하고, 최대 수혜자는 바로 Journal…Q2. IOA Write Cache – Journal에서 사용할 만큼 충분한가?PFJournalMemoryIOAWrite CacheSystem ASPUserASPAPJrn Rcvr armsPFIOA Write Cache Slower WriteOver Threshold DestageFast WriteMemoryDemand (and wait)ThresholdWrite Cache MemoryBackgroundDestageDASDDASDContinuousTrickleWrite Cache에 대해 너무 인색하지 말 것… ModelWrite CacheJournal(older) 276310 Meg278240MegReceiver(older) 277826 (104) Meg2757235 (757) MegIOAWrite Cache. . .Physical quantityFeels likeNeed enough ArmsIOA write cache?
  • IOA write cache는 충분한가?
  • Requirements
  • The performance tools (5722PT1) to start collection services
  • Fast disk write의 사용률을 알아내는 방법
  • 1. Start collection services
  • 2. Collect data for at least 5 minutes (disk statistics are gathered at this interval).
  • 3. Dump the statistics to a database table using the following CL command:
  • CRTPFRDTA FROMMGTCOL(*ACTIVE) TOLIB(LIB) CGY(*DISK)
  • - This will create a file called QAPMDISK.
  • 4. Query the resulting file.
  • The interesting data is in columns DSCCFW (fast writes) and DSWRTS (total writes)
  • SELECT 100 * SUM(DSCCFW) / SUM(DSWRTS) FastWrtPrcnt
  • from QMPGDATA/qapmdisk
  • where dsasp = 2  replace with correct ASP #
  • Output:% of Fast WritesPercentage of fast disk writes Display Data Data width . . . . . . : 42 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4.. FASTWRTPRCNT99 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split 85Rule of Thumb: Journal needs 99% fast writesBACKQ3. Journal Bundling – Application이나 Setting이 Journal-Friendly한가?PF 3Batch Job #1Batch Job #2Batch Job #3PF 2PF 1Main Memory Buffer128K Buffer Bundle JournalJournal ReceiverIOAUser ASPWrite CacheJournal Bundling
  • Bundles을 크게 하면:
  • Disk에 Write하기 위한 Activity를 좀 더 효율적으로
  • 또한 Remote Journal을 좀 더 효율적으로
  • 그렇다면, 현재 내 System의 Journal bundles은 얼마나 될까? 어떻게 해줘야 할 것인가? ?Bundling이 어떻게 되고 있는가?
  • Journal은 Round-Robin방식으로 entry들을 저장한다
  • 아래의 output을 이용해 Journal의 평균 Bundle Width를 알 수 있다
  • DSPJRN Format *TYPE5를 이용
  • Journal Entry당 사용한 Disk Arm #을 알 수 있다.
  • J Ent. . .Bundle #10Bundle #2Bundle #1Arm #10Arm #1Round RobinJournal Bundling?그렇다면, 현재 내 System의 Journal bundles은 얼마나 될까? Requirements
  • Journal Receiver가 1개 이상의 disk arm으로 구성된 ASP에 존재해야 한다.
  • 아래 예와 같이 Journal Receivers의 내용을 DSPJRN TYPE5와 INCHIDENT(*YES) options을 사용하여 output을 생성한다.
  • Example: DSPJRN JRN(mylib/myjrn) OUTPUT(*OUTFILE) INCHIDENT(*YES) OUTFILFMT( *TYPE5 ) OUTFILE(mylib/myoutfile)DSPJRNDisplay Data Data width . . . . . . : 862 Position to line . . . . . Shift to column . . . . . . ...40....+...41....+...42....+...43....+...44....+...45....+...46....+...47.... RCVARM THREAD ADDRESS REMOTE REMOTE ASP NUMBER ID FAMILY PORT ADDRESSHEX 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 1 2 0000000000000000 0 0 120000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 3 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 4 0000000000000000 0 0 1 40000000000000000 0 0 More... F3=Exit F12=Cancel F19=Left F20=Right F21=Split Arm changeJournal Bundling
  • Tool
  • 1) Display set of Journal Receivers to an OUTFILE using DSPJRN TYPE5 and INCHIDENT(*YES) options
  • 2) Run BUNDLE programon this outfile
  • (Source code http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html )
  • Get next EntryUpdate stats for current bundleYESYESNOIs Entry on same Arm as previous Entry?Update overall stats and reset current bundle statsDo More Entries Exist?
  • Output:
  • Average Bundle Size
  • Maximum Bundle Size
  • Minimum Bundle Size
  • NOOutput ResultsRule of Thumb: 128k is optimalBUNDLE program output... number of entries = 530730 Total size of all entries = 354982052 Number of bundles = 2298Average bundle size = 124474bytes max bundle size = 317170 bytes min bundle size = 609 bytes The optimal bundle size is 128 KB or widerF3=Exit F4=End of File F6=Print F9=Retrieve F17=Top F18=Bottom F19=Left F20=Right F21=User Window 그럼, 이제 Bundling Width를 어떻게 늘릴 것인가? If you’re willing to make application changes...
  • Application입장에서는 간단하게 Database Override 통해 가능하다…
  • Working storage of applicationHow can I get bigger bundles ?Jrn EntOverrides를 사용하면 이 부분이 달라집니다.My ODPJournal Bundling - Methodology
  • Tool
  • 1) Display set of Journal Receivers to an OUTFILE
  • 2) Run SEQONLY program on this outfile
  • (Source code http://www-03.ibm.com/systems/i/software/db2/journalperfutilities.html )
  • Get next pairGood candidate: SEQONLYOutput file/job pair identityYESYESDetermine # of Updates and Deletes for file/job pairObtain list of distinct file/job pairsDo more pairs Exist?Does file/job pair have only Inserts?Determine # of Inserts for file/job pairNONO
  • Output:
  • Files which should be considered for SEQONLY(*YES)
  • EndSelect * from lib/output Display Data Data width . . . . . . : 62 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4....+....5....+....6.. OBJ LIB MBR JOB NUMPTS PROD_TRANS CKRJTEST PROD_TRANS CKRJTEST 136,040 STOR_TRANS CKRJTEST STOR_TRANS CKRJTEST 100,014 ******** End of data ******** Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Good candidatesNumber of putsJournal Bundling - Application
  • ODP Buffer를 효과적으로 사용
  • OVRDBF …. SEQONLY(*YES)
  • 다른 방법은 또 없을까?
  • Program에 각각의 File당 하나의 View만을 사용해야 한다는 생각은 버리자…
  • 때론 하나보단 두 개가 나을 때도…
  • Use a job with two "views"Regular ODPUPPFPTODP 1PTPTPure InsertsODP 2ODP 2는 EXTRA "view“를 사용한 경우.이 instance는 File Open시 SEQONLY(*YES)를 이용하였다.JournalActiveIOP128K BufferWrite CacheSystem ASPUser ASPJrn Rcvr armsAPPFJournal Bundling – Journal Cache
  • Application 수정 이외에 좀 더 편하게 Bundle Width를 늘릴 방법은 없을까?
  • Journal CachingCHGJRN ... JrnCache(*Yes)PFODP BufferBatch ApplicationCache-enabledJournalReceiverMain memory cacheIOA128K Buffer128K BufferWrite CacheOne per disk armSystem ASPUser ASPAPPFJournal Cache의 성능 이점
  • Batch Job의 경우
  • 5 Million DB operations (10% Adds, 90% Updates)
  • 9 Million resulting Journal entries (captured both before and after images)
  • Elapsed TimeOriginal Batch run, no Journaling1118 SecOrdinary Journaling enabled9773 Sec약 6배 향상Using the new Journal cache option1433 SecJournal Cache의 성능 이점
  • Remote Journal을 사용할 경우
  • Target System이 Keep-Up Mode일 경우
  • Keep up rate on Target machinew/o Caching600,000 transactions/HrWith Caching on target2,400,000 transactions/HrSource SystemTarget SystemCache.JournalJournal Caching Option
  • A priced feature of the Operating System
  • Option 42
  • CHGJRN JRN(MYLIB/MYJRN) JRNCACHE(*YES)
  • Journal Cache Option이 도움이 될지 안될지 판단하기 위해서는 아래와 같은 방법을 사용하여 알아본다.
  • Tool1) Display set of Journal Receivers to an OUTFILE 2) Run the following query against the OUTFILEselect count(*) as NumEntEligible, sum(JOENTL) as TotalBytes from lib/file where JOCCID = 0 and ((JOENTT = 'PT' OR JOENTT = 'PX' OR JOENTT = 'DL' OR JOENTT = 'UP') and JOCODE = 'R')
  • Output:
  • Number of entries eligible to be Cached
  • Number of bytes eligible to be Cached
  • Looking for bundle-eligible journal entriesDisplay Data Data width . . . . . . : 58 Position to line . . . . . Shift to column . . . . . . ....+....1....+....2....+....3....+....4....+....5....+... NumEntEligibleTotalBytes 38,197 6,910,903 Bottom F3=Exit F12=Cancel F19=Left F20=Right F21=Split Quantity of Journal entriesNumber of bytes만약 Commit User라면…일단은 V5R4으로...
  • Tool
  • 1) Display set of Journal Receivers to an OUTFILE
  • 2) Run the following query on the OUTFILE
  • select count(*) as NumEntEligible,
  • sum(JOENTL) as TotalBytes
  • from lib/file
  • where JOCCID = 0
  • and ((JOENTT = 'PT' OR JOENTT = 'PX' OR JOENTT = 'DL' OR JOENTT = 'UP') and JOCODE = 'R')
  • V5R4에서 “soft” commit을 사용할 수 있습니다.Drop this line
  • Output:
  • Number of entries eligible to be Cached
  • Number of bytes eligible to be Cached
  • Journal Bundling – 결론 (start)YesGood Performance!Are my Journal Bundles wide?(use Bundle tool)NoYesCan I use SEQONLY(*YES)?(useSEQONLY program)Bigger bundles are betterUse SEQONLY(*YES) if possibleNoYesWill Journal Caching likely help?(use query)Turn on Journal Caching BACKQ4. Commit – Journal을 통해 Commit 길들이기
  • Commitment control과 관련된 entry는 pair로 구성됨
  • BC - Begin Commitment Control
  • EC - End Commitment Control bound all transactions for a Job
  • SC and CM (or RB) serve as bookends for a particular transaction
  • SC – Commit cycle started
  • CM(RB) – Set of record changes committed ( rolled back )
  • Example Application:STRCMTCTLTransaction 1Transaction 2Transaction 3ENDCMTCTL..................BCSCECCMSCSCCMRBCommitRollback많은 Row가 Lock되어있는 것이 과연 나쁜가?
  • Un-locking – transaction동안 잡고 있던 lock를 release 하는 step (time-consuming )
  • Un-do – object를 원래의 state로 되돌리는 step ( actual rollback )
  • 만약 모든 Lock들에 대해 적절한 Memory가 없다면, 성능은…
  • Locks are stored in Main Memory
  • May take a while to unlock (CPU)
  • Even more time if they are paged out (DISK faults)
  • Main Memory PoolRow ChangesLock (hold record)?필요한 만큼의 lock이 수행되지 않으면 성능이 저하됨무심결에 수행한 SQL 한 문장이…delete from mylib/table1 where due_date <= ‘12/31/2003’Your BossProgrammer조심해야 할 Locked Rows
  • 그럼 실제로 Un-Do (Rollback) 과 Un-Lock Time이 얼마나 걸릴지 알 수 있는 방법은?
  • Ouch !This is going to be a long night !Determining rollback progress
  • Commit Status Screen
  • WRKCMTDFN + 5 + F6 + Journal
  • Display Journal Status System: ISERIES1Job: QPADEV001P User: JOEUSER Number: 071957 Commitment definition . . . . . . . . : *DFTACTGRP Type options, press Enter. 5=Display commit cycle entries 6=Display all entries 7=Work with journal attributes Commit Cycle Opt Journal Library Identifier _ MYJRN1 MYLIB1 123 _ MYJRN2 MYLIB2 456 _ MYJRN3 MYLIB3 789 BottomF3=Exit F5=Refresh F6=Display resource status F9=Command line F11=Display rollback status F12=Cancel F23=More options The Rollback Phase Display Journal Status System: RCHASJMBJob: QPADEV001P User: RANDYJ Number: 071957 Commitment definition . . . . . . . . : *DFTACTGRP Type options, press Enter. 5=Display commit cycle entries 6=Display all entries 7=Work with journal attributes -----------Rollback----------- Opt Journal Library Date Time % Complete _ MYJRN1 MYLIB1 100 _ MYJRN2 MYLIB2 08/23/05 12:00:0050 _ MYJRN3 MYLIB3 0 BottomF3=Exit F5=Refresh F6=Display resource status F9=Command line F11=Display unlock status F12=Cancel F23=More options Start time of rollbackThe Unlock Phase Display Journal Status System: RCHASJMBJob: QPADEV001P User: RANDYJ Number: 071957 Commitment definition . . . . . . . . : *DFTACTGRP Type options, press Enter. 5=Display commit cycle entries 6=Display all entries 7=Work with journal attributes ------------Unlock------------- Opt Journal Library Date Time % Complete _ MYJRN1 MYLIB1 100 _ MYJRN2 MYLIB2 08/23/05 10:42:0096 _ MYJRN3 MYLIB3 0 BottomF3=Exit F5=Refresh F6=Display resource status F9=Command line Helps track time spent unlocking lots of RowsLocking LimitsUpper Case OnlyQAQQINI file record lock maximum
  • The QAQQINI file을 이용해 한 Transaction내에서 허용할 maximum number of record locks 을 지정한다.
  • Default값으로 500,000,000 records
  • 대부분의 경우 이 값을 줄여주어야 합니다.
  • COMMITMENT_CONTROL_LOCK_LEVELvalue를 줄이면 된다.
  • 1) CRTDUPOBJ OBJ(QAQQINI) FROMLIB(QSYS) TOLIB(qusrsys) DATA(*YES)2) Update qusrsys/QAQQINI SetQQVAL = 32000 where QQPARM = ‘COMMITMENT_CONTROL_LOCK_LIMIT’Having too many locks can be unpleasant얼마나 많은 Locks이 발생하는지?
  • Journal을 이용해 Commit Cycle내에 Insert, Update, Delete건수를 확인하면 된다.
  • 동일한 Commit ID(CID)를 가진다.
  • Guide Line: Locked Record를 100K 미만이 되도록
  • Avoid too many locksCID = #17Transaction 17CID = #55Transaction 55Jrn Receiver......SCCMSCUPPTCM............CID 55CID 55CID 55CID 17CID 17CID 17Seq #17Seq #55Transaction 17Transaction 55Commit – Excessive Locks얼마나 많은 Locked Rows들이 발생하는지?Requirements Journal ReceiverTool1. Display set of Journal Receivers to an OUTFILE 2. Run the following querys on the OUTFILE// ordered list of number of locked rows in each commit cyclecreate view lib/view2 as (select count(*) as cnt, JOCCID FROM lib/outfile WHERE JOCCID != 0 and JOENTT != 'UB' group by JOCCID)SELECT cnt, JOCCID from lib/view2 order by cnt desc // average number of entries in a commit cycleSELECT avg(cnt) as average from lib/view2 ?Large Number of Entries within commit cyc
    Related Search
    We Need Your Support
    Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

    Thanks to everyone for your continued support.

    No, Thanks