Oracle Fusion Dehydration Store planning
Dehydration
Store Planning (Installation time)
This
article is for database growth management strategy, it is intended for the
actual developers, Architects who are requested to help in managing the
Dehydration Store.
Identifying
the size of database
The
criteria are to consider the instance space filled per day, retention period ,
purging policy.
Each
instance stores data in dehydration store, this information is stored in
several tables.
This
article is for calculating the dehydration space before installation.
Let
us define the size versus category (Small, Medium, and High); also we assume
that we will not need more than 10 days of retention.
Serial.
|
Size
of Database
|
Composite
Space persisted per day
|
Minimum
Retention of Space.
|
1
|
Small
|
<10
GB
|
<100
GB
|
2
|
Medium
|
10-30
GB
|
100-300
GB
|
3
|
High
|
>30
GB
|
>300
GB
|
Identify the
inflow of Data
Number of Instances produced
daily
Daily Inflow = Number of
Instances / Period of time.
E.g. Daily Inflow = 10000/5 =
2000
So, for example we have 2000
instances daily.
Disk Space used by each instance
Disk Space = SOA Schema /Number
of Instances
E.g. we have 20 GB used, and
number of instances = 2000.
Disk Space = 20 GB/2000 = 10 MB
Space filled by Composite daily
Daily
Space = Daily Number of Instances * Disk space per composite.
Daily
Space = 2000 * 10 MB = 20 GB
Retention policy of
Composites
Most
of instances are not needed after a period of time.
We
need to decide on legal requirement of Data, do we need to store finance data
for several years as required by few Governments.
This
can also vary industry wise, if the data needs to be stored for trend analysis.
This
needs to decide for each instance type after agreement with business.
Determine the minimum
retention Disk Space
Minimum
space retain = Daily composite space * Retention period.
e.g.
Minimum
space retain = 20 GB * 10 = 200 GB
200
GB of space is required to retain the data of composites for 10 days.
Determine the minimum
retained instances
Minimum
Retained instances = Daily Inflow of composites * Retention period
Minimum
Retained Instances = 2000 * 10 = 20000
20000 instances retain 200 GB as per
our example.
So,
In our example we are medium size Data base, assuming retention period of 10
days and maintenance cycle of < 1 day.
Serial.
|
Size
of Database
|
Composite
Space persisted per day
|
Minimum
Retention of Space.
|
1
|
Small
|
<10
GB
|
<100
GB
|
2
|
Medium
|
10-30 GB
|
100-300 GB
|
3
|
High
|
>30
GB
|
>300
GB
|
Clearing of Composite
Space
Purge
Cycle – The data can be purged in cycles, the period of time till data is
deleted is measured in purge cycle.
It
might take few hours for multiple executions or it might be scheduled in maintenance
cycles.
Maintenance
Cycle - This is maintenance cycle for different components, it goes over days
covering all space operations.
Maximum
Retention period of instances
Do
we have long running instances, what is the maximum duration of long running instances?
Future
Planning for Space
Monitoring
Space Utilization
How
do we determine the growth? Do we check database?
Table Level
Database
Growth can be measured by measuring the number of records over a period of
time.
The
tables have created date fields.
·
SCA_FLOW_INSTANCE: CREATED_TIME
·
CUBE_INSTANCE: CREATION_DATE
Creating
Tables to store the history of the growth trend, we can create a copy of
following tables so that we can store the history of instances.
Ø SCA_FLOW _INSTANCES
Ø CUBE_INSTANCE
DBA
Help
The
package can be used for growth trend of Tables using following.
OBJECT_GROWTH_TREND function
of the DBMS_SPACE
Schema level (DBA Help might be required)
Segment
growth - DBA_SEGMENTS, filtered on Owner = SOA Owner.
We
can create a copy of the data from dba_segment.
Determine
the largest segments
After Installation, Guide Lines for
Developer – How can we throttle the BPELs after the installations of BPEL?
Word
Throttle is used like a mechanism for controlling the dehydration points of
instances.
Why
would we consider dehydration? Dehydration is used as mechanism to control
transaction information availability in case of failures in BPEL. It could be
failure of Server or the BPEL instances (temporary lack of resources, time outs
.etc...)
Following
are options to force dehydration in BPEL.
Serial.
|
Level
|
Description
|
|
1
|
each
partner link property
|
idempotent
BPEL Property
|
False
– dehydrated after invocation.
True
– Does not hydrate after invocation.
|
2
|
BPEL
Properties Set Inside a Composite
|
bpel.config.inMemoryOptimization
|
True
– dehydration is not required.
False
– Dehydration is required.
|
3
|
BPEL
Properties Set Inside a Composite
|
completionPersistPolicy(works
only if inMemoryOptimization is true)
|
(I)On
(default):-The completed instance is saved normally
(ii)Deferred:-The
completed instance is saved, but with a different thread and in another
transaction.
(iii)Faulted:-Only
the faulted instances are saved.
|
Detailed:-
Properties
that can affect the Dehydration Store:-
(I)
idempotent BPEL Property:-Idempotent Activities:-An idempotent activity is an
activity that can be retried (for example, an assign activity or an invoke
activity).
Oracle
BPEL Server saves the instance after a no idempotent activity. A BPEL invoke
activity is by default an idempotent activity, meaning that the BPEL process
does not dehydrate instances immediately after invoke activities. Therefore, if
idempotent is set to true and Oracle BPEL Server fails right after an invoke
activity executes, Oracle BPEL Server performs invoke of instance again after
restarting.
If
idempotent is set to false, the invoke activity is dehydrated immediately after
execution and recorded in the dehydration store. If Oracle BPEL Server then
fails and is restarted, the invoke activity is not repeated, because Oracle BPEL
Process Manager Sees that invoke of instance is already executed.
When
idempotent is set to false, it provides better failover protection, but at the
cost of some performance, since the BPEL process accesses the dehydration store
much more frequently. This setting can be configured for each partner link property.
Setting this parameter to true can significantly improve throughput. Some
examples of where this property can be set to true are read-only services (for
example, CreditRatingService) or local EJB/WSIF invocations that share the
instance's transaction.
(ii)BPEL
Properties Set Inside a Composite:-
e.g.
<property
name="bpel.config.inMemoryOptimization">true</property>
<property
name="bpel.config.completionPersistPolicy">faulted</property>
(a)inMemoryOptimization:-This
property indicates to Oracle BPEL Server that this process is a transient
process and dehydration of the instance is not required. When set to True, the
completionPersistPolicy is used to determine persistence behavior. This
property can only be set to True for transient processes or processes that do
not contain any dehydration points such as receive, wait, onMessage and onAlarm
activities. The inMemoryOptimization property is set at the BPEL component
level.
Values:
This
property has the following values:
False
(default): instances are persisted completely and recorded in the dehydration
store database.
True:
The completionPersist policy is used to determine persistence behavior.
(b)completionPersistPolicy:-
This
property configures how the instance data is saved. It can only be set at the
BPEL component level. The completionPersistPolicy property can only be used
when inMemoryOptimization is set to be True (transient processes). Note that
this parameter may affect database growth and throughput (due to reduced I/O).
Value
(I)On
(default):-The completed instance is saved normally
(ii)Deferred:-The
completed instance is saved, but with a different thread and in another
transaction.
(iii)Faulted:-Only
the faulted instances are saved.
(iv)Off:-No
instances of this process are saved.
Reference:-
http://pushplsingh.blogspot.fr/2011/11/dehydration-in-soa-11g.html
posted by Architect View @ 4:28 AM
0 Comments
