<?xml version="1.0" encoding="utf-8"?>
<ManualTopic ID="/baanerp/tf/onlinemanual/cri00app_perf" xml:lang="en">
   <Header>
      <Title>Performance Tuning for Parallel Processing</Title>
      <Keyword type="header" order="d1e1816090">
         <Level1>Performance tuning</Level1>
         <Level2>parallel processing</Level2>
      </Keyword>
      <Keyword type="header" order="d1e1816095">
         <Level1>Parallel processing</Level1>
         <Level2>performance tuning</Level2>
      </Keyword>
   </Header>
   <ConceptSection>
      <Paragraph>This appendix describes performance tuning that can be required
		to run the <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> session using parallel processing.</Paragraph>
   </ConceptSection>
   <GeneralSection>
      <List>
         <ListIntro>The actual performance of <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> depends on a number of factors, including the number
		  of available CPUs, and the setup of application and database servers. The
		  amount of data contained in tables is another major factor. In general, the
		  following tables contain large amounts of data:</ListIntro>
         <ListItem>Integration Transactions (tfgld482)</ListItem>
         <ListItem>Reconciliation Data (tfgld495)</ListItem>
         <ListItem>Finalized Transactions (tfgld106)</ListItem>
         <ListItem>WIP and Inventory Transactions (SFC) (ticst300)</ListItem>
         <ListItem>PCS WIP and Inventory Transactions (tipcs300)</ListItem>
         <ListItem>Sales Order History (tdsls450, tdsls451, and
		  tdsls456)</ListItem>
      </List>
      <Paragraph>In Infor LN FP5 and later a feature is available to update tables directly
		through the RDBMS. This feature is implemented in porting set 8.7a.03 and
		later.</Paragraph>
      <Paragraph>Updates directly through the RDBMS are more efficient than
		updates via the bshell. The difference is that the entire transaction is handed
		over to the RDBMS. This type of update is limited to tables or data for which
		no recalculation of home amounts and/or exchange rates is required. This can be
		the case if, for example, the home amounts of a reporting currency become the
		amounts in local currency. Another example can be removal of home amounts. This
		can be the case if reporting currencies are deleted, or in logistical tables if
		the currency system changes to a standard currency system.</Paragraph>
      <Paragraph>The <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> session will check whether
		updates directly through RDBMS can be applied. The session will use the
		conventional (slower) updates if the update directly through RDBMS is not
		allowed.</Paragraph>
      <List>
         <ListIntro>Whether you can use RDBMS updates, is determined by the
		  following:</ListIntro>
         <ListItem>
            <Paragraph>In the <GUIRef href="/baanerp/tc/cri/tccri7100m000" role="session">CI Rates (tccri7100m000)</GUIRef> session, the value of the <GUIRef href="/baanerp/tc/cri/tccri7100m000#tccri700.excb" role="manual">Express in Base Currency</GUIRef> field must match that of the
			 corresponding field in the <GUIRef href="/baanerp/tc/mcs/tcmcs0108m000" role="session">Currency Rates (tcmcs0108m000)</GUIRef> session. For example, in EURO companies the exchange
			 rates from EUR (local) to transactional currencies can remain if the express in
			 base does not change during conversion.</Paragraph>
            <Paragraph>
               <GUIRef href="" role="manual">Note</GUIRef>:
			 This applies to all rate types of every base currency in the Currency Rates
			 session.</Paragraph>
         </ListItem>
         <ListItem>Technical limitations <List>
               <ListIntro>These restrictions apply:</ListIntro>
               <ListItem>The DB-driver must be a level-2 driver.</ListItem>
               <ListItem>
                  <Paragraph>The following tables are audited nor
				  mirrored:</Paragraph>
                  <Paragraph>tfgld495, tfgld482, tdsls451, and tdsls456</Paragraph>
               </ListItem>
            </List>
         </ListItem>
         <ListItem>Version 8.7a.03 or later of the porting set must be used.
		  TIV-level of the porting set must be 1744 or later. You can check this number
		  by running $BSE/bin/bshell6.2 –V on the command line (on Windows, use
		  %BSE\bin\ntbshell –V)</ListItem>
      </List>
      <Paragraph>If the currency initialization process starts in the <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> session, this session will access the conversion
		cluster and relevant companies, and then determine which type of conversion is
		required. If updates directly through the RDBMS can be applied, some data will
		be generated in the CI Conversion Tables by Cluster Companies (tccri725) and CI
		Cluster Conversion Tables Update Groups (tccri726) tables.</Paragraph>
      <Note>
         <SectionTitle>Note</SectionTitle>
         <Paragraph>CI Cluster Conversion Tables Update Groups (tccri726) are
		  generated only for Integration Transaction (tfgld482) entries in the <GUIRef href="/baanerp/tc/cri/tccri7125m000" role="session">CI Conversion Tables by Cluster Companies (tccri7125m000)</GUIRef> session.</Paragraph>
      </Note>
      <Paragraph>In the <GUIRef href="/baanerp/tc/cri/tccri7125m000" role="session">CI Conversion Tables by Cluster Companies (tccri7125m000)</GUIRef> session the Mass Updates
		field will be selected if <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> will update a table directly through RDBMS
		updates.</Paragraph>
      <Paragraph>The Integration Transactions (tfgld482) table may contain
		transactions that belong to multiple financial companies. The integration
		transactions that can be handled with updates directly through the RDBMS will
		be grouped in update groups. Transactions in one update group can be converted
		in one RDBMS update. If Integration Transactions (tfgld482) must be converted
		without updates directly through RDBMS (as well), the table conversion can
		still be split. In this way, the conventional update of the table will be
		processed using parallel processes.</Paragraph>
      <Paragraph>Reconciliation Data (tfgld495) must be split only if updates
		directly through the RDBMS cannot be applied. This will be the case if, for
		example, recalculation of home amounts or exchange rates is
		required.</Paragraph>
      <Paragraph>Reconciliation Data (tfgld495) must be split only if updates
		directly through the RDBMS cannot be applied. This will be the case if, for
		example, recalculation of home amounts or exchange rates is
		required.</Paragraph>
      <Note>
         <SectionTitle>Note</SectionTitle>
         <List>
            <ListItem>If the conversion of Reconciliation Data (tfgld495) is split,
			 the table will <Emphasis>not</Emphasis> be updated with updates directly
			 through the RDBMS.</ListItem>
            <ListItem>The Finalized Transactions (tfgld106) table can be converted
			 using parallel processes. Updates directly through the RDBMS are not
			 supported.</ListItem>
         </List>
      </Note>
   </GeneralSection>
   <ExampleSection>
      <SectionTitle>Tuning example</SectionTitle>
      <Paragraph>This example applies to conversion tasks that are handled
		without updates directly through RDBMS, and that can be split in <GUIRef href="/baanerp/tc/cri/tccri7125m000" role="session">CI Conversion Tables by Cluster Companies (tccri7125m000)</GUIRef>.</Paragraph>
      <Figure space-and-orientation="indented-estimated">
         <HTML:IMG xmlns:HTML="http://www.w3.org/TR/REC-html40" height="721" width="791"
                   SRC="../images/tr_conversion_example_1.png"
                   alt="[...]"/>
      </Figure>
      <Paragraph>An internal conversion with parallel processing may involve
		conversions with and without updates directly through the RDBMS, depending on
		the currency setup per company.</Paragraph>
      <Paragraph>Suppose data of three companies must be converted using nine
		parallel bshells. The picture shows this situation with different colors for
		the three companies.</Paragraph>
      <Paragraph>The table converted in task 1.1 is very large. At the same time,
		three other large tables are converted also (2.1, and 2.2, and 3.1). If the
		large conversion task 1.1 can be split, you can decide to have six bshells
		processing tasks 1.1, while three bshells will process task 2.1, 2,2, and 3.1.
		After splitting task 1.1, the smaller (purple-colored) tasks will be pushed
		aside by the six larger tasks that process task 1.1.</Paragraph>
      <Paragraph>The same approach can be used if, for example, conversion of
		table 2.3 and 2.4 can be split. If table 2.3 is processed by two bshells in
		parallel, and 2.4 is processed by three bshells in parallel, there is still
		enough capacity left for the remaining parallel bshells to process the smaller
		(green-colored) tasks at the same time.</Paragraph>
      <Figure space-and-orientation="indented-estimated">
         <HTML:IMG xmlns:HTML="http://www.w3.org/TR/REC-html40" height="721" width="791"
                   SRC="../images/tr_conversion_example_2.png"
                   alt="[...]"/>
      </Figure>
      <Paragraph>After splitting the tasks, the load for the parallel processes
		will look more balanced.</Paragraph>
      <Paragraph>The total elapsed time has been reduced from 28 to 17 time
		units.</Paragraph>
   </ExampleSection>
   <GeneralSection>
      <SectionTitle>CI Process (tccri7203m000): trial conversion vs. real
		conversion</SectionTitle>
      <Paragraph>In simulation mode, the database transactions of the updates
		directly through the RDBMS will be tested. This type of updates can be used
		within the conversion of Reconciliation Data (tfgld495), Integration
		Transactions (tfgld482), Sales Order History Lines (tdsls451), and Sales Order
		History Delivery Lines (tdsls456). Transactions will be rolled-back in trial
		mode. This can take considerably more time than the actual transaction in a
		real conversion.</Paragraph>
      <Paragraph>In the conventional conversion logic, the update of table data
		is not performed during trial conversion. Note that whereas these tables will
		be processed in a shorter time during trial conversion, processing them in the
		real conversion will take more time.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>Oracle settings</SectionTitle>
      <Paragraph>The updates directly through the RDBMS will be large
		transactions. As a result, a large amount of undo table space will be needed. LN is tested
		with an undo table space of 32 GB. We recommend that you configure the undo
		table space to extend the data files automatically with, for example, 8 GB per
		time. This will help prevent ORA-1555 <Emphasis>(Snapshot too old)</Emphasis> errors from occurring. Keep in mind the maximum data file size.</Paragraph>
      <Paragraph>It is not easy to predict whether the size of undo table space
		will be sufficient. We recommend that you look for ORA-1555 errors in the
		event-viewer logs of LN when <GUIRef href="/baanerp/tc/cri/tccri7203m000" role="session">CI Process (tccri7203m000)</GUIRef> is running.</Paragraph>
      <Paragraph>In general, to have queries perform well, the Oracle database
		requires proper tuning.</Paragraph>
      <List>
         <ListIntro>LN has been tested with the following settings applied to the
		  ERP LN environment via the $BSE/lib/default/db_resource file:</ListIntro>
         <ListItem>
            <Code>ora_init:0101000</Code>
         </ListItem>
         <ListItem>
            <Code>ora_max_array_fetch:100</Code>
         </ListItem>
         <ListItem>
            <Code>ora_max_array_insert:100</Code>
         </ListItem>
         <ListItem>
            <Code>ora_alter_session</Code>: set " <Code>_optim_peek_user_binds</Code> "= <Code>false</Code>
         </ListItem>
      </List>
      <Paragraph>You should consider merging the above lines with the batch-based
		db resource for conversion.</Paragraph>
      <Paragraph>In some implementations non-default values are applied to hidden
		Oracle parameters (the so-called underscore parameters). These settings might
		influence the execution plans of the queries. Consider to reset them to their
		defaults. This can be done by adding them to the <Code>ora_alter_session</Code> property in the $BSE//lib/defaults/db_resource file.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>SQL Server settings</SectionTitle>
      <Paragraph>You should consider changing the logging on the LN database
		during currency initialization to <GUIRef href="" role="manual">Simple</GUIRef> and create a full
		backup after completing the currency initialization.</Paragraph>
      <Paragraph>Set up the $BSE/lib/default/db_resource file to enable array
		fetching, and then set the fetch size to 100.</Paragraph>
   </GeneralSection>
   <GeneralSection>
      <SectionTitle>DB2 settings</SectionTitle>
      <Paragraph>Set up the $BSE/lib/default/db_resource file to enable array
		fetching, and then set the fetch size to 100.</Paragraph>
   </GeneralSection>
</ManualTopic>