BULK COLLECT Vs CURSOR

Bulk Collect will be having better performance at the cost of Server RAM.

Cursor resides in our temp tablespace but as we bulk collect into some collection and this collection resides in the computer memory(RAM). So while using cursor we should consider about our temp tablespace and while using Bulk collect we should consider about server RAM.

COLLECTIONS in Oracle

Index-By Tables (Associative Arrays) -  Same as arrays except that have no upper bounds, allowing them to constantly extend. As the name implies, the collection is indexed using BINARY_INTEGER values, which do not need to be consecutive. The collection is extended by assigning values to an element using an index value that does not currently exist.

TYPE table_type IS TABLE OF NUMBER(10)
    INDEX BY BINARY_INTEGER;

Nested Table Collections - Nested table collections are an extension of the index-by tables. The main difference between the two is that nested tables can be stored in a database column but index-by tables cannot. In addition some DML operations are possible on nested tables when they are stored in the database. During creation the collection must be dense, having consecutive subscripts for the elements. Once created elements can be deleted using the DELETE method to make the collection sparse. The NEXT method overcomes the problems of traversing sparse collections.

TYPE table_type IS TABLE OF NUMBER(10);

Varray Collections - A VARRAY is similar to a nested table except you must specifiy an upper bound in the declaration. Like nested tables they can be stored in the database, but unlike nested tables individual elements cannot be deleted so they remain dense.

TYPE table_type IS VARRAY(5) OF NUMBER(10);

Assignments and Equality Tests

Same type of collections - 
  TYPE table_type IS TABLE OF NUMBER(10);
  v_tab_1  table_type;
  v_tab_2  table_type;

  v_tab_2 := v_tab_1; -- This works

  IF v_tab_1 = v_tab_2 THEN -- This works
    ....
  END IF;


Different type of collections - 
  
  TYPE table_type_1 IS TABLE OF NUMBER(10);
  TYPE table_type_2 IS TABLE OF NUMBER(10);
  v_tab_1  table_type_1;
  v_tab_2  table_type_2;

  v_tab_2 := v_tab_1;  -- This will throw error

  IF v_tab_1 = v_tab_2 THEN  -- This will throw error
    ....
  END IF;


Collection Methods:

A variety of methods exist for collections, but not all are relevant for every collection type.

EXISTS(n) - Returns TRUE if the specified element exists.
COUNT - Returns the number of elements in the collection.
LIMIT - Returns the maximum number of elements for a VARRAY, or NULL for nested tables.
FIRST - Returns the index of the first element in the collection.
LAST - Returns the index of the last element in the collection.
PRIOR(n) - Returns the index of the element prior to the specified element.
NEXT(n) - Returns the index of the next element after the specified element.
EXTEND - Appends a single null element to the collection.
EXTEND(n) - Appends n null elements to the collection.
EXTEND(n1,n2) - Appends n1 copies of the n2th element to the collection.
TRIM - Removes a single element from the end of the collection.
TRIM(n) - Removes n elements from the end of the collection.
DELETE - Removes all elements from the collection.
DELETE(n) - Removes element n from the collection.
DELETE(n1,n2) - Removes all elements from n1 to n2 from the collection.

MULTISET Operations

  TYPE t_tab IS TABLE OF NUMBER;
  l_tab1 t_tab := t_tab(1,2,3,4,5,6);
  l_tab2 t_tab := t_tab(5,6,7,8,9,10);
  ...

MULTISET UNION {ALL | DISTINCT} Operator - 

  l_tab1 := l_tab1 MULTISET UNION l_tab2;

  l_tab1 := l_tab1 MULTISET UNION DISTINCT l_tab2;

MULTISET EXCEPT {DISTINCT} Operator

  l_tab1 := l_tab1 MULTISET EXCEPT l_tab2;

MULTISET INTERSECT {DISTINCT} Operator

  l_tab1 := l_tab1 MULTISET INTERSECT l_tab2;

https://oracle-base.com/articles/8i/collections-8i
https://docs.oracle.com/cloud/latest/db112/LNPLS/composites.htm#LNPLS005

Query optimization using CBO and RBO

Query optimization is the overall process of choosing the most efficient means of executing a SQL statement. SQL is a nonprocedural language, so the optimizer is free to merge, reorganize, and process in any order.

The database optimizes each SQL statement based on statistics collected about the accessed data. The optimizer determines the optimal plan for a SQL statement by examining multiple access methods, such as full table scan or index scans, different join methods such as nested loops and hash joins, different join orders, and possible transformations.

For a given query and environment, the optimizer assigns a relative numerical cost to each step of a possible plan, and then factors these values together to generate an overall cost estimate for the plan. After calculating the costs of alternative plans, the optimizer chooses the plan with the lowest cost estimate. For this reason, the optimizer is sometimes called the cost-based optimizer (CBO) to contrast it with the legacy rule-based optimizer (RBO).

Note:

The optimizer may not make the same decisions from one version of Oracle Database to the next. In recent versions, the optimizer might make different decision because better information is available and more optimizer transformations are possible.

Execution Plans

An execution plan describes a recommended method of execution for a SQL statement.

The plan shows the combination of the steps Oracle Database uses to execute a SQL statement. Each step either retrieves rows of data physically from the database or prepares them for the user issuing the statement.

An execution plan displays the cost of the entire plan, indicated on line 0, and each separate operation. The cost is an internal unit that the execution plan only displays to allow for plan comparisons. Thus, you cannot tune or change the cost value.

O2C

Explain Order Management Flow in detail?

Create Sale order > in the Header Level - enter customer name whos should be having both Bill to and Sit to Address> enter Payment Terms> enter the pricing > enter the transaction Type of that sale, then go to Line item and pick the inventoriable (or ono inventoribale item) items from item master from the Sub Inventroy Orginsation, then attach this line to a particular sales man or collection agent.
Save the data, (Line statius is 'Entered') then book the order (shows the line status as “line is awating shippment" (order status will be 'booked' > release the sales order > (Line status will be " Picked") and ship the Materail which eventually show the line status as 'closed'.  This shows the inventroy is credited with inventory Cost and COGS is Debited
The next face is interfacing to AR ( Autoinvoicing Rule) - Customer is Debited and Sales is Credited.

enter the order:
oe-order-headers-all
oe-order-lines-all(flow_status_code = entered)
book the order:
oe_order_headers_all
oe_order_lines_all(flow_status_code = booked)
wsh_new_deliveries(status_code =open)
wsh_delivery_details(releases_status = R 'ready to release)
pick release:
which items on sales order we need to take out from inventory. Normally pick release SRS program run from backend once this over.
oe_order_lines_all (flow_status_code=picked)
wsh_delivery_detalis(release_status = S 'submitted for release)
pick confirm:
items are transfered from salable to staging sub inventory.
mtl_material_transaction
mtl_transaction_accounts
wsh_delivery_details (released_status = Y 'released')
wsh_delivery_assignments
ship confirm:
here ship confirm program run from backend and data removed from wsh_new_deliveries.
oe_order_lines_all (flow_status_code =shipped)
wsh_delivery_details (released_status = shipped)
mtl_transaction_interface
mtl_material_transactions (linked through source_header_id)
data deleted from mtl_demand & mtl_reservations
item deducted from mtl_onhand_quantities.
Enter invoice:
this is also called recivables interface,that mean information moved to accounting area for invoicing details. Invoicing workflow activity transfers shipped item info to recevables.
ra_interface_lines_all
then auto-invoice program imports data from this.
then effected tables : ra_customer_trx_all (trx_number is the invoice number)
ra_customer_trx_lines_all (line_attribute 1 & 6 ) linked to header_id
and lined_id for orders....
complete line:
order line level table get updated with flow status & open flag.
oe_ordr_lines_all ( flow_status_code = shipped & open flag = N)
close order:
once we close the order oe_order_lines_all table get updated with flow_status_code as closed.

MOAC

What is MOAC?

Multi-Org or multiple organization access (MOAC) is basically an ability to access multiple operating units from a single application responsibility.

What are its advantages?

Multi-Org Access Control (MOAC) enables companies that have implemented a Shared Services operating model to efficiently process business transactions by allowing them to access, process and report on data for an unlimited number of operating units within a single applications responsibility.
This increases the productivity of Shared Service Centers, as users no longer have to switch application responsibilities when processing transactions for multiple operating units at a time.
Ability to view data from multiple operating units from a single responsibility, gives users more information. This enables them to make better decisions.
The following SQL will dump out the Security Profiles and Operating Unit Names assigned to them.

SELECT   psp.SECURITY_PROFILE_NAME,
         psp.SECURITY_PROFILE_ID,
         hou.NAME,
         hou.ORGANIZATION_ID
FROM     PER_SECURITY_PROFILES psp,
         PER_SECURITY_ORGANIZATIONS pso,
         HR_OPERATING_UNITS hou
WHERE    pso.SECURITY_PROFILE_ID = psp.SECURITY_PROFILE_ID
         AND pso.ORGANIZATION_ID = hou.ORGANIZATION_ID;

There are three Profile Options you need to be aware of related to Multi-Org that should be set at the Responsibility Level.

MO: Security Profile– Always evaluated first.
MO: Operating Unit– Secondary priority being evaluated after ‘MO: Security Profile’
MO: Default Operating Unit– Sets the default Operating Unit for transactions when running under a Security Profile.

How it is done in R12?

In Release 12, one creates a Security Profile and assigns as many operating units as you required. One can tie that security profile to a single responsibility using a profile option called MO: Security Profile. For example, you could assign the security profile to the EMEA Payables responsibility to allow that responsibility to process invoices across all operating units.

In Release 12, define a security profile in HR using the Security profile form or the Global Security profile form, and assign all of the operating units that one would want a responsibility to access. The one needs to run a concurrent request called “Run Security List Maintenance” from HR which will make those security profile available and allow one to assign them to a responsibility via a profile option called MO: Security Profile.

One can define another profile option called MO: Default Operating Unit which is optional and allows one to specify a default operating unit that will be the default when you open different subledger application forms.

Multi-Org in EBS - Technical Implementation

For ERP applications, data partitioning is performed by database views. These views reside in the APPS Oracle schema and derive the appropriate operating unit context from an RDBMS variable.

All applications code is run against the APPS schema. The Applications database architecture is now the same for a Multiple Organizations and non-Multiple Organizations implementation.

Multi Organization Tables

Multiple Organizations in Oracle Applications is enabled by partitioning some database tables by operating unit. Other tables are shared across operating units (and thus across sets of books).
In general, the following criteria determine if a table would be partitioned:
The table contains a GL Account Code (code combination ID).
There is a business reason for the table to be partitioned (for example, the entity should not be shared).
The table contains transaction data.
The table is an interface table where data being loaded is partitioned.

Applications with Partitioned tables

• Oracle Cash Management
• Oracle Order Management and Shipping Execution
• Oracle Payables
• Oracle Property Manager
• Oracle Projects
• Oracle Purchasing
• Oracle Release Management
• Oracle Receivables
• Oracle Sales Compensation
• Oracle Sales and Marketing
• Oracle Service
• European Localizations
• Latin America Localizations
• Regional Localizations

RDBMS Variable

A global variable exists in the Oracle database called CLIENT_INFO, which is 64 bytes long. The first 10 bytes are used to store the operating unit ID (or ORG_ID) for the Multiple Organization Support feature. The CLIENT_INFO context is derived from a profile option that the user sets for each responsibility as part of the Multi-Org setup steps.

Org_id column in the warehouse contains the Operating Unit ID
Organization_id column contains the warehouse / Inventory Org.

select * from <table name>_ALL
where ORG_ID = SUBSTRB(USERENV('CLIENT_INFO'),1,10);