FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FU.
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Internal Distribution:
External Distribution:
Approval Authorities:
Branch Database High Level Design
High Level Design
HNG-X
This document describes the design of the Branch Database
(BRDB), which is the data-store for the Branch Access Layer and
also provides all of the transactional data to Legacy.
It also covers the BRDB-standby database, which provides a
failover solution
APPROVED
Andy Beardmore
Gareth Jenkins, David Johns, Duncan Macdonald, David Harrison,
Roger Barnes
(Specify those individuals outside of the Post Office Account who
require approved version only. For Document Management to
distribute following approval)
FUJ00235023
IJ00235023
Name Role Signature Date
David Harrison HNG-X Solution Design
Graham Allen HNG-X Development
Note: See Post Office Account HNG-X Reviewers/Approvers Role Matrix (PGM/DCM/ION/0001) for guidance.
‘©Copyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE, Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 1 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Document Control
0.1 Table of Contents
DOCUMENT CONTROL............06
0.1 Table of Contents
0.2 Document History
0.3 Review Details.
0.4 Associated Documents (Internal & External)
0.5 Abbreviations
0.6 Glossary.
0.7 Changes Expected . 11
0.8 Accuracy...
0.9 Copyright...
4 INTRODUCTION... 13
14 Summary
12 Scope...
13 Context within the Architecture
14 Assumptions
2 DESIGN PRINCIPLES
3 REQUIREMENTS ............0006 17
4 SUB-SYSTEM DESCRIPTION 18
5 APPLICATION COMPONENTS 22
5.1 Data Partitioning and Di 22
5.2 Data Subject Areas. 28
5.3 System Interfaces. 37
5.4 Aggregation and De-normalisation .. 60
5.5 Migration 64
5.6 Training 65
5.7 Branch Database Supportability 66
58 Branch Support System Feed: 68
3.9 Branch Standby Database 68
5.10 Post Hydra changes ..
6 BUILDING BRANCH DATABASE... 73
6.1 Oracle Installation & Configuration.
6.2 Storage Management
6.3 Database Components
6.4 BRDB Database Bui
6.5 Network Configuratio:
6.6 Replication to the SSC Support (History) Databas:
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 2 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
6.7 Setting up Branch Standby Database
.8 Interfacing with non-Oracle Database Systems.
Application Development
Host Processes
BRANCH STANDBY DATABASE SOLUTION.
Standby Database Configuration ......
Setting up Branch Standby Databas
Branch Standby Database Backups..
Switching to BRDB-Standby ..
PLATFORMS ........ccscsssssssssssessesescsessseneesenesssssssssessanssescassnscscesesenenseraceeaseeeseneasone®
Branch Database
BRDB-Standby Database
4 NETWORKS .....ccscsessessssessssessssussssncseenssnessancossucassussssusssussussesuesesosarsesaceseeneasensass 125
42.4 Security.
42.2 Availability.
42.3 Usability.
12 Performance
12.5 Backups..
12.6 Failure & Restart/Recovery
12.7 Switch to BRDB-Standby
12.8
Potential for Change.
13.4 Summary ....
13.2 Delivery Units
18 APPENDIX A— TABLE AND INDEX DEFINITIONS .........cceseceseseseseeeeeeseneeee 151
18.4 Live Schema objects shared with Training.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 3 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
419 APPENDIX B — VIEW DEFINITIONS 152
wee 153,
21 APPENDIX D— METADATA AND STATIC REFERENCE DATA DEFINITION 164
. 164
. 169
. 183
. 183
. 185
24.4 Partition Management metadata
21.2 Housekeeping & Maintenance Metadata
21.3 Fad-Hash Mappings...
Host Processing Metadat:
Branch Specific Metadata
22 APPENDIX E -SUGGESTED ORACLE INITIALISATION PARAMETERS .....194
22.1 Branch Database Parameters
22.2 Branch Standby Database Parameters ..
22.3 Role Reversal Parameter Change:
. 194
. 196
. 198
Figure — 1 Context within the Architecture
Figure — 2 Logical Data Model and Data Flows...........
Figure — 3 Concept of a Rolling Window
Figure — 4 Rolling Window implementation for a composite partitioned table
Figure — 5 Rolling Window implementation for a composite partitioned table
Figure — 6 Bulk Copy Schedule demonstrating Node Unavailability
Figure — 7 BRDB Transactions to TPS ....
Figure — 8 Hydra-specific feeds from TPS
Figure — 9 BRDB Transactions to APS
Figure ~ 10 BRDB Transactions to DRS.
Figure — 11 BRDB interfaces with RDMC/RDDS
Figure — 12 Oracle components on each BRDB-Host node
Figure — 13 ASMB Instance Disk Group Layout............. soteeee
Figure — 14 Oracle components used on the BRDB - ACDB/BCDB interface..............
Figure — 15 Branch Database Execution Environment...
Figure — 16 BRDB-Standby Platform Execution Environment.
Figure — 17 BRDB Backup Approach
Figure — 18 Metadata logical data model.....
Table 1 — List of BRDB to/from Legacy Interfaces..............
Table 2 — Guidelines for Installing & Configuring Oracle ....
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 4 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE &
Table 3 - ASM Disk Group Usage Notes .... wee
Table 4 ~ Guidelines for Installing & Configuring Oracle ....
Table 5 — Branch Database Availability Targets
Table 6 — Branch Database Throughput Target
Table 7 — Branch Database Overall Volumes.....
Table 8 — Settlement Transaction Throughput & Volumes .
Table 9 —Reporting Throughput & Volumes...
Table 10 — Session Management Throughput & Volumes ....
Table 11 — Recovery Management Throughput & Volumes
Table 12 — Help Service Throughput & Volumes
Table 13 — Bulk Copy Throughputs
Table 14 — Audit File Throughputs....
Table 17 - BRDB_ TABLE GROUPS Metadata
Table 18 - BRDB_PARTITIONED TABLES Metadata
Table 19 - BRDB_ TABLE PARTITIONS Meta Data
Table 20 - BRDB_SUBPARTITION RANGES Meta Data ...
Table 21 -—BRDB_ ARCHIVED TABLES Metadata ....
Table 22 - BRDB_ANALYZED OBJECTS Meta Data...
Table 23 -BRDB FILES TO HOUSEKEEP Meta Data
Table 24 - BRDB_PROCESSES Meta Data
Table 25 - BRDB_OPERATIONAL INSTANCES Meta Data.......
Table 26 - BRDB_HOST_ INTERFACE FEEDS Meta Data
Table 27 - BRDB_HOST_AGGREGATIONS Meta Data...
Table 28 - BRDB_BRANCH ROLES Meta Data
Table 29 - BRDB_BRANCH SERVICES Meta Data...
Table 30 - BRDB_BRANCH SERVICES Meta Data...
Table 31 —Core BRDB Initialisation Parameters......
Table 32 —Net Services specific Initialisation Parameters
Table 33 — Instance Tuning specific BRDB Initialisation Parameters
Table 34 — Database Tuning specific BRDB Initialisation Parameters...
Table 35 — Standby Database specific BRDB Initialisation Parameters.
Table 36 — Streams Replication specific BRDB Initialisation Parameter:
Table 37 -BRDB-Standby Initialisation Parameters ....
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 5 of 197
FUJ00235023
FUJ00235023
co Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
0.2 Document History
Version No. Date Summary of Changes and Reason for Issue Associated Change -
CP/PEAK/PPRR
Reference
0.4 22-Dec-2006 First Draft (APP1)
0.2 06-APR-2007 Incorporated Review Comments & issued second draft (APP1
& APP2)
03 09-Jun-2007 Incorporated review comments, elaborated on host interface
definitions and issued third draft (APP1 & APP2)
04 26-Sep-2007 Incorporated review comments. Added Backup and Recovery
(some sections incomplete) approach.
05 30-Oct-2007 I Updated as a result of review of development / testing for
INTS.
06 03-Mar-2008 Updated section for Data Aggregation
07 40-Mar-2008 _I Updated Standby Database Section(s)
0.8809 28-Dec-2008 __I Various Changes for CP299 cP299
0.10 10-Nov-2009 Outstanding PEAKs and for review
1.0 17-Nov-2009 Updated BRDB_FAD_HASH_OUTLET_MAPPINGS.csv and
sent for Approval
0.3 Review Details
Review Comments by : 17% November 2009
Review Comments to
Mandatory Review
Role Name
HNG-X Solution Design David Harrison
HNG-X Development Steve Goddard
Architecture Jim Sweeting
ssc Mik Peach
Business Continuity Adam Parker
System Test John Rogers
Role Name
HNG-X Architecture Roger Barnes
HNG-X Architecture Duncan Macdonald
Programme Manager Alan D'Alvarez
Security and Risk Team CSPOA.Security,
Applications Architecture Dave Johns
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version:
Date: 17-Nov-2009
Page No: 6 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Test Design
George Zolkiewka
Head of Service Management
Gaetan van Achte
Head of Service Change & Transition
Graham Welsh
Service Support
Kirsty Gallacher
Service Network Jan Mills
Data Centre Migration Geoff Butts
Integration Peter Okely
SV&i Manager
Sheila Bamber
Tester
Hamish Munro.
RV Manager
James Brett (POL)
V1& TE Manager
Mark Ascott
POL Design Authority
lan Trundell (POL, via Document Control)
Core Services
Ed Ashford
System Qualities Architecture
Dave Chapman
Core Services
Andrew Gibson
Integrity Testing
Alan Child
Integrity Testing
Michael Welch
Business Architect
Gareth Jenkins
Development Graham Allen
Architect Jason Clark
Issued for Informa
distribution list to a minimum
Position/Role Name
(*) = Reviewers that returned comments
0.4 Associated Documents (Internal & External)
Reference In Dat Tit Source
IR1] PGM/DCM/TEM/0001 Fujitsu Services Post Office Account I Dimensions
(D0 NOT REMOVE) HNG-X Document Template
[R2] PGM/DCM/TEM/0002 Dimensions
(DO NOT REMOVE)
IR3] ARC/APP/ARC/0008 HNG-X Business Data Solution Dimensions
Architecture — Branch Database
IR4] ARC/PER/ARC/0001 HNG-X System Qualities Manual Dimensions
IR5] DES/APP/HLD/0005 HNG-X RDDS Host Data High Level I Dimensions
Design
[R6] ARC/APP/ARC/0007 HNG-X Batch Services Architecture I Dimensions
IR7] DES/GEN/STD/0001 Host Applications Design and Dimensions
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 7 of 197
Fe)
FU
ITSU COMMERCIAL-IN-CONFIDENCE
Branch Database High Level Design
FUJ00235023
FUJ00235023
Date Title
Development Standards (HADDIS)
[R8] DES/APP/HLD/0050 Branch Access Layer High Level Dimensions
Design
[R9] DEV/INF/LLD/0019 Building Oracle 10gR2 on RHEL4 U4 I Dimensions
AS 64-bit Low Level Design
[R10] DES/PPS/HLD/0002 Red Hat Linux 4 AS High Level Dimensions
Design for HNG-X
[R11] DES/APP/HLD/0022 Branch Database Sizing and Volume I Dimensions
Spreadsheet
[R12] DES/APP/HLD/0021 Branch Database Scheduling High Dimensions
Level Design
[R13] ARC/GEN/REP/0001 HNG-X Glossary Dimensions
[R14] DES/APP/HLD/0023 Branch Support Database High Level I Dimensions
Design
[R15] PGM/PAS/PRO/0003. HNG-X Design and Build Dimensions
Methodology — Build and Unit Test
process
[R16] DES/APP/HLD/0027 HNG-X TPS High Level Design Dimensions
[R17] I DES/APP/IFS/0007 Branch Database (BRDB)- Legacy _I Dimensions
Host Interface Specification
[R18] DES/APP/AIS/0007 HNG-X APS Host to Branch DB Dimensions
BRDB Interface Specification
[R19] DES/APP/IFS/0001 HNG-X RDDS Host to Branch DB Dimensions
BRDB Reference Data Interface
Specification
[R20] DES/APP/IFS/0002 HNG-X: RDDS to Branch Database — I Dimensions
Counters Reference Data and Memo
Submission Interface Specification
[R21] DES/APP/IFS/0010 Branch Database — Branch Access Dimensions
Layer Interface Specification
[R22] I ARC/MIG/STG/0001 HNG-X Migration Strategy Dimensions
[R23] ARC/SEC/ARC/0003. HNG-X Technical Security Dimensions
Architecture
[R24] ARC/SYM/ARC/0003. HNG-X System and Estate Dimensions
Management Monitoring
[R25] DES/SYM/HLD/0031 Estate Management Database Dimensions
(EMDB) High Level Design
[R26] ARC/NET/ARC/0001 HNG-X Network Architecture Dimensions
[R27] ARC/SEC/ARC/0003. HNG-X Security Architecture Dimensions
[R28] EP/IFS/005 Horizon Counter — TPS Ongoing PVCS
Migration Feed Interface Specification
[R29] DES/APP/HLD/0049 HNG-X Generic Report Data Extract Dimensions
High Level Design
[R30] EP/IFS/006 Horizon — HNG-X In Day Migration PVCS
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 8 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Reference Date Title Source
Interface Specification
[R31] I DES/APP/HLD/0070 Host Application Monitoring High Dimensions
Level Design
[R32] DES/APP/HLD/0005 HNG-X RDDS Host High Level Dimensions
Design
[R33] DES/APP/HLD/0004 HNG-X RDMC Host High Level Dimensions
Design
[R34] DES/SYM/IFS/0002 ACDB/BCDB to Branch Database Dimensions
Interface Specification
[R35] DES/SYM/HLD/0015 HNG-X Backup and Recovery High Dimensions
Level Design
[R36] DES/APP/LLD/0199 Branch Database Schemas Dimensions
[R37] ARC/APP/ARC/0004 HNG-X Architecture - Branch Access _ I Dimensions
Layer
[R38] DES/APP/HLD/0053 HNG-X BAL Reporting High Level Dimensions
Design
[R39] DES/APP/HLD/0121 HNG-X HLD - BRDB Aggregations Dimensions
[R40] DES/APP/HLD/0120 HNG-X HLD - BRDB Processing of Dimensions
the End of Day Migration Data
[R41] DES/APP/HLD/0122 HNG-X HLD - BRDB Data Retention Dimensions
[R42] DES/APP/HLD/0113 HNG-X HLD - BRDB Processing of Dimensions
the In Day Migration Data
[R43] DES/APP/SPG/0001 Branch Database Support Guide Dimensions
Unless a specific version is referred to above, reference should be made to the current approved
versions of the documents.
0.5 Abbreviations
Abbreviation Definition
APEX Oracle’s Application Express (formerly known as XML DB)
APOP Automated Payment Out-Pay
APS Automated Payment System
ASM Automatic Storage Management
BLOB Binary Large Object
BRDB Branch Database
CLOB Character Large Object
cs Customer Services
DMZ De-militarised Zone
DR Disaster Recovery
DRS Data Reconciliation System
DWh Data Warehouse
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref DESTAPP/HLD/0020
bate Y7-Nov.2000
Page No: 9 of 197
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
ed
Definition
Estate Management Version 2. Generic term used for HNG-X estate management
changes.
ERwin ERwin Data Modeller (CASE Tool)
ETU Electronic Top-Up (of payment cards)
FAD Financial Accounting Division [POL Outlet]
GB Giga Bytes
GCs Oracle Global Cache Service
GREV Guaranteed Reversals
IAS (Oracle) Internet Applications Server
loT Index Organised Tables
IT™ IBM Tivoli Monitoring Agent
HLD High Level Design
JDBC Java Database Connectivity
KB Kilo Bytes
LcR Logical Change Request (Oracle Streams data ‘packet’)
LFS Logistics Feeder Service
LPAN Logical Processor Area Network
LGWR Log Writer process
LOB (Oracle) Large Object (Datatype)
MB Mega Bytes
NPS Network Persistent Store
OAS Oracle (Internet) Applications Server
OCFS Oracle Cluster File System
OcR Oracle Cluster Registry
ODBC Microsoft's Open Database Connectivity
OEM Oracle Enterprise Manager
OLTP Online Transaction Processing
OMDB Operation Management Database
Oracle 10gR2
Oracle version 10gR2
PAN
Processor Area Network
PGA Program Global Area
POL-MIS Post Office Limited - Management Information System
RAC Real Application Cluster
RAD IBM's Realtime Network Dashboard
RDMC Reference Data Management Centre
RDDS Reference Data Distribution Service
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 10 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
Fe)
FUJITSU COMMERCIAL-IN-CONFIDENCE
Abbreviation Definition
RHEL Red Hat Enterprise Linux
RMAN (Oracle) Recovery Manager
SAN Storage Area Network
SGA ‘System Global Area
SLA Service Level Aggrement
SOAP Simple Object Access Protocol
sat Structured Query Language
SRDF ‘Symmetrix Remote Data Facility
SRS ‘System Requirement Specification
SYSMAN2 ‘Systems Management Environment (on the legacy Horizon environment)
T&T Track and Trace
TES Transaction Enquiry System
TESQA Transaction Enquiry System Query Application
TPS Transaction Processing System
TWS Tivoli Workload Scheduler
XML eXtensible Mark up Language
0.6 Glossary
Also refer to the HNG-X Glossary [R13].
Term Definition
Branch Database The centralised data store which will act as the data repository and transaction store
in HNG-X
Real Application Clusters I An Oracle Real Application Cluster is a group of loosely coupled computers that work
together closely so that in many respects they can be viewed as though they are a
single computer. Clusters are usually deployed to improve performance and/or
availability over that provided by a single computer.
Branch Access Layer The middle-tier that carries out the data storage, retrieval and transfer on behalf of
the Counter.
Flashback Flashback in the Oracle context refers to a feature by which users can access data
from the table for a point in time in the recent past. Using similar technology it is also
possible to rescue objects that may have been erroneously deleted without having to
go to the backups.
Hydra Phase covering the dual-running of Horizon and HNG-X
Outlets Also known as Branches or Post Offices
0.7 Changes Expected
Changes to be expected for the next version of this document:
« HNG-X Release 2 CP's
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 11 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Changes to be expected for a future version (may not be the next) of this document:
* Once the SRS is published, the requirements and requirement traceability sections will be updated.
0.8 Accuracy
Fujitsu Services endeavours to ensure that the information contained in this document is correct but, whilst every
effort is made to ensure the accuracy of such information, it accepts no liability for any loss (however caused)
sustained as a result of any error or omission in the same.
0.9 Copyright
© Copyright Fujitsu Services Limited 2009, All rights reserved. No part of this document may be reproduced, stored
or transmitted in any form without the prior written permission of Fujitsu Services.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 12 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
1. Introduction
1.1. Summary
This document describes the design of the Branch Database (BRDB), which will be built on a set of new
database servers using Oracle's 10gR2 Real Application Cluster technology.
The Branch Database will provide a centralised data-store for all counter transactions and events for
branches and the data will be retained for a period that sufficiently covers the reporting and support
requirements. The Branch data store will also support Counter Training Office (CTO) needs and provides
a separate data access environment for support teams.
Counter access to the Branch database will be through a middle tier logically referred to as the Branch
Access Layer (BAL) - Web Services in technical terms.
BAL will log all the transactional and event messages received from the Counter to the Branch Database.
When necessary BAL will record transactions requiring third party authorisation prior to forwarding the
authorisation request to third parties (external interfaces) so that they can be recovered after failure.
Branch Database will provide the existing host systems like TPS, APS etc with data feeds to replace the
feeds that these systems currently get from Riposte Message Store via the agents. Near real-time and
batch feeds will also be in place to transfer data from existing host systems to the Branch database for
use by the counters.
All business centric transactional, event and access control information sent up by the counters will be
audited in its original compressed XML format. The counter must obfuscate security sensitive information
where necessary. The auditable data will be accessed by the audit server over NAS.
This document is an internal Fujitsu Services document. The level of detail in this document is intended
to act as a baseline to Fujitsu Services developers and testers.
1.2 Scope
This document is the high level design of the database that will support BAL to store transactional and
events data and facilitate report generation and recovery of failed on-line transactions. It also covers
details required to support the HNG-X CTO and delivery of Reference data delivery to Counters.
This document covers the design of Branch database batch processes such as those required for
interfacing with other host systems, audit file generation and general database housekeeping activities.
This document also covers the design of the BRDB-Standby database and the mechanism for keeping it
in step with the live Branch database.
The Branch database host processes scheduling requirements are not covered in this document but are
covered in [R12]. The physical database sizing is covered in [R11].
The document does not cover the design details of the Branch Support System (also referred to as SSC
History database). This is covered in Branch Support System Design [R14].
The document does not cover details of either the BAL platform or BAL processes. These are described
in the Branch Access Layer High Level Design [R8].
Also, this document does not cover the processes defined within the existing host systems domain that
push or pull data to or from the Branch database respectively. These details will be present in the
respective host systems High Level Design documents and in the Branch Database to host systems
Interface Specification documents.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 13 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJITSU
The details of platform build for the operating system RHEL4 are present in the Red Hat Linux 4 AS High
Level Design [R10]. Details of building a platform environment for hosting the Branch Database are
covered in [R9].
1.3 Context within the Architecture
Document Relationship
Fujitsu POA
Parent
Documents
Architecture &
Strategy “ARCIPERIARCIOOOT "ARCTAPPIARCI0008 I I ~ARCISECTARCIO003 I { ~ARCTAPPYARCIO07
5 levine iter HNG-X System Qualttes Branch Database HING-X Secunty Batch Applications
ene I (Rho Marton sien ‘Manual “Architecture Architecture Architectute
~e _-4
High Level Ac,
Design ‘DESIAPPINLDIO022 DESIAPPIMLDIO020 DESIAPPIALDIO02T DESIAPPIALDIonnn
prea Branch Database Sizing bali] Branch Database High Level fa}=oeI Branch Database Schecuiing Legacy Application High
Spreadsheet Design High Level Design Level Designs
Low Level {
Designs and : -
Application Series of BROB Application SSeres of Legacy Application
Interface Build Low Level Designs Build Low Level Designs
‘Spectfications
Figure - 1 Context within the Architecture
1.4 Assumptions
This design is based on the following assumptions and assertions.
1. Under all circumstances, BAL will always access the correct Oracle instance, as per the Fad-
Hash to Oracle Instance mappings (defined later), regardless of the number of Branch Database
nodes running.
BAL as far as possible will avoid the need to re-prepare and hence re-parse SQL statements.
Where possible it must also use statement batching.
The Branch Access Layer will be responsible for deriving the value of the pseudo column
“Trading-Date”. This date will not have any time part and will be derived by applying a metadata-
driven delta to the Application Server clock date.
The delta value will be Shours i.e. the Trading Day will switch to the next calendar day at 7pm.
The clock of the Branch Access Layer rigs will not vary from the clocks of the Branch Database
nodes by more than by 1 second. Further detail can be found in [R37].
All consumers of the Branch Database data will minimise the need to read non-outlet specific
data from the Branch Database to reduce the cluster interconnect traffic. At the same time, outlet
specific data reads will be qualified by the partitioning keys (Journal Date) and Fad-Hash to take
advantage of the partitioning logic and reduce the load on the Branch Database.
The existing host systems interfaces will be simplified wherever possible in order to use the
common host interface (discussed in 5.3.2) and thus lower the cost of development.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 14 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7. The flashback query feature in Oracle 10gR2 has a number of benefits around recovering the
primary database on a standby platform and avoiding the re-configuration of streams. However
using the ‘flashback’ feature has performance implications, which are as yet un-quantified. The
working assumption is that this feature will be disabled.
8. Itis assumed that the source and target systems for transactional data into the Branch Database
are compliant with the PCI standards.
9. During the hydra phase, there will be means of identifying the up to date list of all Outlets that
have migrated to HNG-X. The mechanism will be simple and involves running a SQL query
against one or more tables within the Branch Database.
10. RDT requirement for Branch Database is a single node cluster (Test size). The database name
and its operational requirements remain the same as those for any other test system.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 15 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
2 Design Principles
» In line with other Fujitsu POA Host Systems the Branch Database design follows the standards
defined by [R7].
» Fujitsu POA processes covering the full lifecycle are defined by [R15].
» The design is based on relational databases that use Oracle's RAC technology.
>» The design is not object based.
» The design functional decomposition allows for a small sized development team in the order of
no more than 8 developers.
> The design aims for reduced risk and cost through secure minimal change.
» The approaches highlighted in certain sections require prototyping effort to prove them. The
scope of any prototyping effort needed is clearly marked in those sections.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 16 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
3 Requirements
The SRS for this topic architecture captures incoming requirements. The requirements system has a
skeleton copy of the document (section numbers only). The skeleton document identifies the section
where the requirement is being addressed.
Section will be updated to reference the document once it is published.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 17 of 197
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
4 Sub-System Description
The Branch Database (BRDB) system will provide a scalable, highly resilient (24 x7 availability)
store for the Branch Access Layer and the Counter.
data-
The BRDB system will run on four p-blades within the Fujitsu-Siemens’ BladeFrame environment. The
operating system will be a suitable patch-set of Red Hat Linux Enterprise Edition version 4 and will
a SAN-based storage solution.
utilise
The Branch Database will be implemented in the form of a 4-node Oracle Real Applications Cluster and
database version will be a stable patch set of 10gR2. Clustering allows the database to provide the
following features:
> High Resilience: If a database node fails, the other available nodes can take over with mi
inimal
effort on part of the consumer applications. The BRDB design allows for the system to continue
running even if storage fails by providing a standby BRDB database (discussed later).
> High Avai
downtime.
The database is a truly 24 x 7 system and has no scheduled regular
> Workload Balancing: A bespoke application-level load-balancing algorithm, which is discussed
in the next section, ensures that the workload is distributed evenly across the available nodes of
the cluster. In case of a node-failure, correct use of the load-balancing algorithm allows workload
balancing across the remaining nodes.
» High Scalability: Oracle RAC technology allows nodes to be added or removed easily. For
HNG-X although the Branch Database will not exploit this feature, there is a possibility of
adding/removing nodes in future.
BRDB will provide storage to the Branch Access Layer to allow it to support the following business
functionality from the Counter:
» User and Session Management
Maintain Counter users, roles (Clerk, Manager etc) and stock units.
Assist in user connection request authentication and log-on/log-off.
Reference data version checking facility
Record user access information for audit
> Settlement Basket Capture
Record basket settlement request for audit
Log settlement transactions for counter reporting and host systems interfaces
> Reporting
Assist in generating transaction level and aggregated reports based on requests from the
counter.
Record report generation requests for audit and reporting purposes
> External Authorisation Transaction Recovery
Provide persistence for potential recovery in case of failures
Assist in transaction recovery
> Track & Trace
Record Track & Trace transactions for onward routing to NPS
> Counter Reference Data
Provide on-demand Reference data to the counter.
»__Cash and Stock Pouch Despatches, Advice Notices
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 18 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Inform counter on availability of such information.
Provide details to the counter on demand.
Record access requests for audit.
> Delivery Notifications and Cash Declarations
Record notifications and declarations for audit and onward routing to existing host systems.
> Desktop Memos
Notify Counter user on availability of memos and track their read status.
Provide message details on demand and audit access requests.
The following figure shows the Branch Database data flows and a logical layout of the data structures:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 19 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
{ ea nee ae eases {\ [ NPS Host Database II I RDDS Host Database I \«
. a a oe ; za * .
5 ras 7 Host based
etch Migration Interactive Batch / Ondémand Auditing process
Balch Interface yh Interface I Batch Ref-data data transfer \
a Interface « ; Sep
¥ , , L a ¥
Host Systems
I Metadata and I 5 L User
Control Data. I & 3 Management
2
s 2 {ls II $ 3 5 2 g Dew
6 I8 I/8 g g ® = é B/I 8 a
3 2 (2 4 8 = 2 Branch soll 8 =
= = a g a a Ea = 3 S 8 3 &
Se ae 8 Access 2 = 2
Bellfzilse Seis § ll€sil8ellbe . &e 2 ia
Be ag Beisel sel sr liSSiiesiiss 3 Metadataand I s§ = \lae
BS ssls8ii$2)\8s)/I Se lisaiiosII=8ii ai] 8 ControlData IG ae ze
go II£oI/25//29/I/88 I) $8 II8o)IBsileel sii < } g 8s 8s y__
&2II8e2//8e \bo ga] Ba I#e ISel/8e =) 2 s Ba liza
Ee lEsitel/seiI 22] 28 II Sel (sel (Ze 5 rot] I88)I B II 2° I 22
SSeS ls 18S 3 S Se Eo a i Reference (25 ‘'g 5 o Session
5 8 I a & a 2 3 Data $5 3 2 FA Establishment
2 co} w oO
= 19 I [4 [:4 3 ye 2 3 3 and
B wu jie & II Genericand I I & 2) ral Management
Outlet specific I § Fa Data
Counter 8 ie (62 days)
Reference
Data L
4 Ly a Ls ‘Overnight ¥ a a a rN ES
Aggregation ; ;
; Ponaee . 1 Branch Database
vo» ¥ > Pw & ¥ e
Branch Access Layer
Figure - 2 Logical Data Model and Data Flows
Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref. DESIAPPIHLDI0020
Version: V1.0
Date: 47-Nov-2009
Page No: 20 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
The data in Transactional tables will be kept for up to three business days (three daily partitions). This is
required to support the delivery of "must deliver" messages to existing host systems. Recovery data will
be stored until the Counter marks it off as ‘not needed’ for transaction recovery.
Reporting transactional and aggregated data will be retained for two calendar months (62 daily partitions)
to cover the longest possible trading period that an Outlet may have. All control and metadata tables will
work off the same retention period of 62 days.
The BRDB system consists of a number of Linux-based host processes that are run by TWS scheduling
software. These processes typically perform operations such as table and index partition management,
interfacing with other Oracle-based host systems to provide data feeds to and from them, feeds to audit,
file and table housekeeping and SLT report generation’.
BRDB will provide existing batch applications such as APS, TPS, and DRS etc with transactional data,
events, Cash declarations, Pouch deliveries, tracking and recovery specific data.
Batch applications will provide BRDB with Counter and Host reference data, desktop memos, transaction
corrections and cash replenishment information.
Additionally during the dual-running (Hydra) phase, the TPS agent, via TPS batch applications, will
provide the Branch Database with a daily feed. . This daily feed will have End-of-Day and In-Day
migration
BRDB will run in archived redo-log mode to provide the facility of point in time recovery. RMAN will be
used as the tool for performing backups and restore/recovery.
There will be a unidirectional real-time asynchronous feed of counter generated data from BRDB to the
Branch Support (Database) System (BRSS).
There will also be another real-rime asynchronous feed of all Branch Database data to Standby Branch
Database (BRDB-standby). This database will be used in the event of LIVE database failure as a result of
data corruption or failures in the storage subsystem.
1 The Branch Database is used for reference data SLA reporting and as there is limited bandwidth in the
overnight batch schedule for running time-consuming jobs the Branch Support Database (BRSS) is used
for other SLT reporting such as counter SLT reporting via counter audit data.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 21 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5 Application Components
5.1 Data Partitioning and Distribution
Database design for an Oracle Real Applications Clustered database used for high OLTP volumes, such
as the Branch Database, needs to overcome the issue of Block Pinging, which could lead to serious
performance degradation of the cluster.
Block Pinging refers to data or index blocks being transferred to and fro across the cluster interconnect
(network that connects the RAC nodes). Block pinging causes serious performance issues due to the
amount of waits generated (as processes have to wait for blocks to be transferred) and the additional
network traffic that needs to flow across the cluster interconnects in order to negotiate the transfer of
read-only copies or ownership of data blocks across.
Oracle suggests a number of design best practices for reducing block pinging. Almost all of the
suggested best practices involve soft limiting the physical and logical data objects modified to a single
instance. While this may not be practical for all objects and taken to the extreme will defeat the purpose
of having a RAC database, is certainly highly recommended for objects holding high throughput OLTP
transactions.
The concept of using a single RAC instance as the sole means of reading / writing transactional data has
been implemented in the Branch Database at two levels, data partitioning using timestamps and/or
mapping metadata and distributing partitioned data (on Fad-Hash) across tablespaces.
5.1.1. Data Partitioning using Mapping metadata
As outlined in [R3], the Branch Database will pre-allocate a “Hash” value ranging from 0 to 127 to each
Outlet. The Hash allocation will be based on the volumes of data flowing from Outlets®. Once allocated,
the Fad-Hash remains with the Outlet in the mapping metadata for the life of the Outlet in the Post Office
branch network.
The Fad-Hash value will be used internally as the partition key within the Branch Database and also used
to aid routing of particular FAD Hash values to specific Oracle Instances running within the Branch
Database RAC.
The FAD Hash needs to be an integer with a range that best suits the partitioning of the RAC and the
database. A range of 0-127 is considered suitable as it offers a balance between the complexities of
deriving the mapping algorithm and fast data access based on full table scans across 1/128" of a day's
transactional / event data.
With a range of FAD Hash values coming from the data centre, the Branch Access Layer can very simply
route the messages to one of the Oracle RAC Instances (nodes*) depending on the value of the FAD
Hash. A simple lookup table will cross-reference the FAD Hash value to the identifier of the Oracle RAC
Instance. However, there are instances where the simple look-up table is insufficient:
© Complications occur when one of the Oracle RAC Instances fails or one (or more) of the
Application Servers fails to connect to an Oracle RAC Instance.
2 A study of data volumes over a period of three months (Jul-2006 to Sep-2006) has been conducted and
the Outlets have been distributed across the 128 “hash” buckets. This has since been revisited Oct-2009.
3 Node refers to the Server where the Branch Database instance is running. Node-Id is a number ranging
from 1 to 4 that has been statically assigned to each node.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 22 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
© Design needs to allow for adding nodes to the Oracle RAC or removing nodes from the Oracle
RAC in order to vary the processing power according to the timings of the peak loadings. This is
considered unlikely in practical terms and is included for completeness.
The challenges presented by both of the above situations are similar and the solution to the problems
must be the same.
The solution is that each FAD Hash must be able to be routed to any Oracle RAC Instance but will have a
preference as to which one it should be routed to as long as that node is available. As soon as the
preferred Oracle RAC Instance is unavailable, then the FAD Hash number must have associated with it a
secondary preferred Oracle RAC Instance to which it is routed. Taking this to the logical extreme, each
FAD Hash number must have priority-based routing to all Oracle RAC Instances. When the preferred
node is not available, then the next-in-line preferred option is used.
In a configuration that allows a maximum of 8 Oracle RAC Instances, each FAD Hash value will have a
mapping to each node, each of them with a different priority.
When the Node that a FAD Hash is mapped-to is unavailable for any reason, then the FAD Hash will map
to the Node that is available at the next highest priority. The trick is to ensure that, regardless of which
Nodes are available or unavailable, the balancing of the FAD Hash values across remaining Nodes is
relatively balanced. Reducing or increasing the number of Nodes thereby retains a balanced and
performance system.
The embedded spreadsheet* contains a matrix of FAD Hash values, Priorities (1-8) and the FAD
Hash/Priority Node mapping. This provides a fairly good balance of FAD Hash/Node distribution
regardless of how many RAC Instances are available.
"Fad-Hash
‘Spreadsheet.xls"
Worksheet “PriorityMatrix” gives an easily visible FAD Hash to Oracle Instance mapping in priority order:
Worksheet “PriorityList” shows the same data in a table format.
Extracting the data from worksheet “PriorityList” into an Oracle table provides the information with which
the Application Servers can determine the Instance (Node) to which a message from any FAD Hash
should be routed.
If this data were loaded into a database table named BRDB_FAD_HASH_INSTANCE_MAPPING with
following columns:
Column Type Comment
FAD_Hash I Number (3) The FAD Hash value that will accompany each communication between
the Counter and the Data Centre
Instance_Id_I Number (2) The Instance to which the FAD Hash value maps at this priority level
Priority Number (2) The priority value of this Hash->Instance mapping. Priority 1 is highest
and 8 is lowest.
4 Note that this spreadsheet contains 8 levels of priority. Since the priority number maps on to a node /
database instance number, This spreadsheet can only be implemented on an 8-node RAC. This version
of the spreadsheet should only be used to understand the concepts. Currently 4-node RAC.
Refer to Section 21.3.3 for the correct mapping spreadsheet to be used for HNG-X.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 23 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
As long as all Instances are available, then the following SQL returns the FAD Hash to Instance mapping:
SELECT fh.Instance_Id, f!
FROM brdb_fad_hash_ins
FAD_Hash
ance_mapping fh,
(SELECT FAD_Hash, MIN (Priority) Priority
FROM brdb_fad_hash_node_mapping
GROUP BY FAD_Hash) fhs
WHERE fh.FAD Hash = fhs.FAD_Hash
AND fh.priority = fhs.priority;
5.1.1.1. Handling Node Unavailability
However, we need a means of indicating the Nodes that are unavailable. This list of unavailable Nodes
will need to be populated whenever Instances are removed from the cluster. This list of available nodes
will also need to be updated whenever an Instance has been operationally removed from the cluster.
The solution is to maintain a single table that store the list of instances and whether they are operationally
available or not. Let us assume that the table is called brdb_operational_instances. Also assume that
the tables have a single column each called “Node”. Then by restricting the selection to the contents of
brdb_operational_instances, the following SQL gets us the FAD Hash to Instance mapping:
SELECT fh.Insatnce_Id, £h.FAD_Hash
FR FAD_Hash fh,
(SELECT FAD_Hash, MIN (Priority) Priority
FROM brdo_fad_hash_instance_mapping
Node
FROM brdb_operational_instances)
GROUP BY FAD Hash) fhs
WHERE fh.PAD Hash = fhs.FAD_Hash
AND fh.priority = fhs.priority;
There are two scenarios:
© The schedule or an operator dictates that an Oracle RAC Instance (Node) has now been added
or removed from the RAC
© An Oracle RAC Instance (or Node) fails or is restored following failure
© An single (or multiple) Application Service fails to connect to an Oracle RAC Instance
The first scenario will involve operations updating brdb_operational_instances.
The second scenario will be handled by a Host-based utility that uses the Oracle Fast Application
Notification (FAN) feature. FAN is a feature that filters and publishes high priority events to specific
targets. For Branch Database, the FAN will run the Host utility, which will in turn update an entry in the
brdb_operational_instance table.
In the third scenario, when a single Application Server fails to connect to a particular node, then the
actions to be taken include:
> Retry for up to three times with a configurable pause of nn seconds to allow any momentary glitch
type errors.
» Use an alternate JDBC connection that has failover nodes defined so that the connection is
established to an available node, to re-fetch the mapping details and using the new mappings, retry
connecting to the node once.
When the Application Server needs to re-evaluate its FAD Hash mapping by re-reading from the
brdb_fad_hash_node_mapping table in the following manner:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 24 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
SELECT £h.FAD_Hash, fh.Node
FROM FAD.
(SELEC Hash, MIN (Priority) Priority
FROM k d_hash_node_mapping
WHERE Node IN (SELECT Node
FROM brdb_operational_nodes
WHERE is_available = ‘y’
)
GROUP BY FAD_Hash) fhs
-FAD_Hash = fhs.FAD_Hash
«priority = fhs.priority;
WHERE
AND
» Otherwise bail out with error.
Note that once a node that was down comes back up, its entry in brdb_operational_instances needs to
be updated. This will be done by an automated process as part of the overnight batch.
As long as the FAD Hash algorithm provides a relatively balanced distribution of transaction volumes
across Hash values, then the described approach provides a flexible and resilient mechanism by which
the load balancing by Outlet can be achieved within the Application Service layer.
5.1.2 Distributing Fad-Hash across tablespaces
One of the main performance bottleneck issues with any RAC database is un-necessary ‘chatter’ of data
across the cluster interconnects. The data partitioning based on Fad-Hash approach mentioned earlier
will help alleviate the problem for incoming data to the Branch Database. However the problem will still
persist when fetching data out of the database unless preventive action is taken.
If a service in the Branch Access Layer connects to the Branch Database using one node and attempts to
fetch a number of blocks of data for an Outlet, Oracle will implement its own load balancing across the
cluster by distributing the ownership of data blocks amongst the four instances. This happens regardless
of whether the Fad-hash algorithm has been used to fetch the data from the ‘correct’ instance.
If the blocks are manipulated using the same single instance, Oracle in the background will negotiate the
ownership of the blocks across instances before updating them. This causes un-necessary overhead in
manipulating the data and may result in performance degradation.
This problem can be minimised in the following manner:
> If the data for each Fad-Hash resides in its own data-file, Oracle's load balancing avoids
distributing data across instances. This however is not fail-safe and relies on Oracle detecting
that data belonging to certain data files is not used by more than one instance.
>
The Fad-Hash based partitions or sub-partitions will be created in their own tablespaces. There will be
128 data tablespaces, where each tablespace will hold Fad-Hash based partitions or sub-partitions
belonging to different tables. The extent sizes may differ from table to table.
For the second approach, please refer to Section on Instance Tuning for further details.
5.1.3. ‘Rolling Window’ Data Storage
There is a requirement for a number of BRDB transactional and aggregation tables to retain data over a
period of days. This may be because there is a business need for the data to remain in BRDB for that
period of time or we may simply want to remain the data for a larger period that required in order to
minimise the possibility of losing critical data before it has been, say, forwarded to existing host systems
or copied across to the audit server.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 25 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
In order to satisfy such requirements with minimal impact on performance, a number of transactional,
audit and reporting tables will be implemented in the form of a ‘Rolling Window' by making use of
Oracle's range partitioning.
The following diagram explains the rolling window concept by taking an example of a table with a three-
day rolling window on successive dates of 224 and 23° December:
BRDB Transactional Table
For 22™ December For 23" December
tition Partition I Partition Partition I Partition I Partition
forday for day forday I forday I forday
21" Dec 22" Dec 21" Dec 22" Dec I 23" Dec
New partition
added
Old partition
dropped
Figure - 3 Concept of a Rolling Window
The addition of a new partition to the table on 23 December along with the simultaneous drop of the now
aged-out partition of 20'" Dec, results in the ‘Rolling Window’ to roll forward by a day.
There are a number of advantages of using this approach:
>» Minimal performance impact of storing data for larger periods of time as approach takes
advantage of Oracle's partition pruning.
>» Ease of maintenance as aged-out partitions can be dropped or archived off without any
potentially messy data movements.
> Metadata driven implementation of the rolling window maintenance software (see Section 7.2.1)
ensures ease of changing window retention period.
For the very high volume OLTP tables, a combination of the ‘Rolling Window’ concept will be used along
side Fad-Hashes distributed across tablespaces. This will result in a composite partitioned table with
range-partitions on Business/Transactional Date and list-sub partitions on the Fad-Hash value.
The following figure explains the same pictorially:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 26 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB Transactional Table
For 22 December
Partition Partition Partition
for day for day for day
20"Dec 21"Dec —.22" Dec.
BRDB_FH_PART_000_DATA 0 FH-0 FH-0
BRDB_FH_PART_001_DATA FH-14 FH-1
BRDB_FH_PART_002_DATA FH-2 FH-2
BRDB_FH_PART_127_DATA __ FH-4. FH - 127 FH - 127
Figure - 4 Rolling Window implementation for a composite partitioned table
Note that in all of the examples in this section, partitions are shown to be created on the day that they will
be needed. In reality, the BRDB Start of Day process will create partitions one day in advance. This is to
ensure if partitions could not be created for any reason, Branch trading can continue while support
investigates the problem.
5.1.4 Fad-Hash Maintenance
5.1.4.1. Pre HNG-X Go-Live
One of the disadvantages of having a mapping metadata driven approach for data partitioning is the need
for keeping the metadata up to date. The analysis for deriving the mappings has been done quite early on
in the development lifecycle and it is reasonable to expect some additions to the list of Outlets by the time
HNG-X goes Live. Hence an exercise of deriving the Fad-Hash mappings for the new Outlets needs to be
carried out just before going Live. This exercise should be based on analysis of the Outlet volumes in
order to maintain an even balance across the Fad-Hashes and ensure that the Fad-Hash values are
correctly balanced when HNG-X goes Live. The new Fad-Hash to Outlet mappings will need to be added
as a delta to the Fad-Hash-Node-Mapping table. Existing Fad-Hash to Outlet mappings should not be
changed.
5.1.4.2 Post HNG-X Go-Live
Once the Branch Database goes Live, any new Outlets joining up to the Network will need their mappings
derived and present in the Fad-Hash-Node-Mapping table before the Outlet can be allowed to trade or in
fact even before any outlet-specific reference data arrives in BRDB. This is because the Transactional,
Event and Audit tables as well as some Ref-Data tables, amongst others, will be partitioned on Fad-Hash
and without the Fad-Hash value no data can be logged in these tables.
Since the Outlet will be new to the estate, no transactional volume analysis will be possible; hence the
Outlet will be assigned with a Fad-Hash value as per the following algorithm.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 27 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
New outlets are made available by POL many weeks in advance. Fad-Hash value will assigned when the
Branch information feed from EMDB is processed.
It is possible that over time the Fad-Hash to Outlet mappings will not be as evenly balanced in terms of
Outlet transaction volumes as at the time of going Live. This is acceptable and an allowance of 20% has
been made in the performance analysis done for the Branch Database. This allowance is on the higher
side and it is not expected for the transactional volumes to be out of balance by more than a few percent.
Over a period of time, some Outlets may cease trading and eventually disappear from the Post Office
Network and Reference Data. For simplicity, the Fad-Hash to Node mappings for such Outlets will never
be deleted. This approach will reduce the cost of maintenance of the mapping mechanism and keep the
solution simple. There will be a no impact on performance due to this.
5.2 Data Subject Areas
This section describes in brief each of the data subject areas depicted in Figure — 2 Logical Data Model
and Data Flows.
5.2.1. Transactional Store
The transaction information from the basket Settlement XML message needs to be parsed and written to
tables. This information is passed on to existing host systems, as a once or more-times-a-day batch
feed. .
The existing host systems that read transactional data from the Branch Database are APS, DRS and
TPS.
TPS and APS systems will read AP transactional data from the same source as part of the HNG-X
development. The Branch Database APS tables will therefore carry the attributes that are the union of
both the TPS requirements and the APS requirements. The data collected in the branch database needs
to be no richer in attributes than the data required for servicing the TPS/APS applications (and their
interfaces).
5.2.1.1. Transactional Store Layout and Usage
The transaction store is sub-divided into various tables structured along the lines of the table structures of
the interface tables in existing host systems.
Each basket settlement XML message will be broken down based on the type of message and messages
will be inserted into their corresponding tables. Refer to the Branch DB — Branch Access Layer IFS [R21]
for further details.
The significant tables that constitute the transaction store are:
BRDB_RX_EPOSS_TRANSACTIONS Stores details of all EPOSS and Settlement transaction parts.
Each EPOS transaction in a customer session will result in
one record being inserted into the EPOSS transactions table.
The settlement transaction will also result in a record being
inserted into the EPOSS-transactions table.
BRDB_RX_APS_TRANSACTIONS Stores details of all APS transaction parts.
Each AP transaction in a customer session will result in one
record being inserted into the APS transactions table.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 28 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB_RX_NWB_TRANSACTIONS Stores Network Banking & E-Top Up transaction parts.
Each Network Banking / E-Top Up transaction in a customer
session will result in one record being inserted into the NWB
transactions table.
BRDB_RX_DCS_TRANSACTIONS Stores Debit and Credit Card transaction parts.
Each Debit Card transaction in a customer session will result
in one record being inserted into the DCS transactions table.
BRDB_RX_BUREAU_TRANSACTIONS Stores Bureau de Change transaction parts.
Each Bureau de Change transaction in a customer session
will result in one record being inserted into the BUREAU
transactions table.
BRDB_RX_REPORT_SESSION_DATA Stores a subset of all transaction parts in a settlement
message.
Every EPOS, AP, Banking + E-Top Up, Debit Card, Bureau
and Settlement transaction in a customer session will result in
one record each being inserted into the Report-Session-Data
table.
5.2.1.2 Transactional Store Storage & Partitioning
All Transaction store tables are distributed across 128 table partitions based on the Fad-Hash value
present in each transaction. The tables are partitioned on a Date value that relates to the time of the
transaction.
Tables have been implemented in the form of a ‘Rolling Window’ as described in Section 5.1.3.
5.2.2 Message Journal
Every auditable request made by the counter will be logged in the message journal before the request is
actioned by the BAL, The message journal performs two functions, firstly it provides auditing facility and
secondly it provides a duplicate checking facility to prevent counter messages that may have been resent
from being reprocessed.
The message journal will also contain messages to reflect any balancing/correcting business transactions
that may have been inserted by support to assist the Post Office branch business. Refer to Section 5.7.2
for more details on balancing transactions.
In order to ensure the integrity and completeness of the audit store, business transactions involving
auditable transactions will not result in a ‘Success’ response if they could not be logged in the message
journal for any reason other than being a duplicate.
All auditable messages logged during a calendar day will be made available to the audit system in
uncompressed form as a part of Branch Database batch overnight processing. However, the audit file will
be compressed to reduce disk space and network utilisation when copying files to the audit system.
5.2.2.1. Message Journal Layout and Usage
The message journal is implemented in the form of a_ single Oracle table named
BRDB_RX_MESSAGE_JOURNAL. Uniqueness is controlled at the level of a Branch counter using a
dense sequence known as the Journal-Sequence-Number.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 29 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.2.2.2 I Message Journal Storage & Partitioning
All Message Journal table records are distributed across 128 table partitions based on the Fad-Hash
value present in each auditable request. The tables are partitioned on a Date value that relates to the
time of the journal message at the counter.
Message Journal will be implemented in the form of a ‘Rolling Window’ as described in Section 5.1.3.
5.2.3 Events
Events that are raised by the counter typically fall into two categories: first is where the counter raises an
event for an action to be performed and the second is where the counter raises the event to report on an
action that it has performed.
Events of the first type will typically be in the form of ‘requests’ from the counter that results in an
interaction with the BAL while events of the second type will typically arrive along with unrelated requests
such as Settlement..
All events will be logged in the message journal table while the Report Events will be logged in the
BRDB_RX_REP_EVENT_DATA and will be identifiable by the Event-Id.
A subset of the other events referred to as EPOSS events will be stored in the table
BRDB_RX_EPOSS_EVENTS and passed on to the TPS batch application for onward routing to the Post
Office MIS. Another subset containing SLA measurement events will be passed on to the Data
Warehouse batch application.
5.2.3.1 Event Store Layout and Usage
The significant tables that constitute the event store are:
BRDB_RX_EPOSS_EVENTS Stores details of all events that need to be passed onto the
TPS Host.
Data is passed onto TPS Host on the same business day and
is retained in the Branch Database for up to 3 days (3 daily
partitions worth of data are retained).
BRDB_RX_REP_EVENT_DATA Stores details of all report events. The reason report events
are stored separately from other events is so that they can be
retained for a longer time period (62 days) to cover requests
for any reports for the current and previous trading period
5.2.3.2 Event Store Storage & Partitioning
All Event tables are distributed across 128 table partitions based on the Fad-Hash value present in each
event message. The tables are partitioned on a Date value that relates to the date and time of the Event.
Tables have been implemented in the form of a ‘Rolling Window’ as described in Section 5.1.3.
5.2.4 Transaction Recovery
Core details of recoverable transactions will be stored in the Branch Database to allow for their recovery
in the event of a failure. Examples of recoverable transactions include some externally authorised
transactions such as Network Banking.
Recoverable transactions are recorded in the Branch Database during a customer settlement session as
a request for the transaction is sent up from the Counter. In the event of the transaction failing due to any
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 30 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
reason e,g, comms issues, counter PC crash etc, the transaction recovery entry is used to initiate the
recovery.
lf the recoverable transaction succeeds, then as a part of the basket settlement processing, any
recoverable transactions for the customer session are marked as processed.
5.2.4.1. Transaction Recovery Store Layout and Usage
The transaction recovery store is in the form of a_ single table named
BRDB_RX_RECOVERY_TRANSACTIONS.
5.2.4.2 Transaction Recovery Store Storage & Partitioning
All Transaction Recovery tables are distributed across 128 table partitions based on the Fad-Hash value
present in each recoverable transaction message. The tables are partitioned on Receipt Date value that
relates to the time of the transaction.
Tables have been implemented in the form of a ‘Rolling Window’ as described in Section 5.1.3.
5.2.5 Reporting & Cut-offs
Data required for reporting is stored at two levels; firstly at a transaction level where core information
such as Product-ld, Amount and Quantity is stored for each settlement transaction and secondly at an
aggregated level that summarises the Outlet's transactions for each day at product level
Transaction level details are stored synchronously when processing settlements. Along with the core
transaction details, certain types of transactions such as AP or Banking will result in additional
information being stored such as AP transaction references, Banking customer Sort Code etc.
Aggregated information will be summarised by a batch overnight host process.
Cut-off markers and details record all report cut-offs registered at the Counter. Cut-offs is recorded
synchronously with cut-off events coming up from the counter.
5.2.5.1. Reporting & Cut-off Store Layout and Usage
Significant tables that constitute reporting and cut-off data store are listed below. Further details can be
found in [R38].
BRDB_RX_REP_SESSION_DATA Stores a subset of all transaction parts in a settlement
message.
Every EPOS, AP, Banking + E-topup, Debit Card, Bureau
and Settlement transaction in a customer session will result
in one record each being inserted into the Report-Session-
Data table.
BRDB_CUTOFF_MARKERS Stores a marker for each Stock Unit Cut-off report. The
marker is in the form of the highest journal-sequence-number
for a cut-off report at a Branch Counter.
Table is updated by a batch-overnight aggregation process.
BRDB_CUTOFF_DETAILS Stores cut-off details for reports at the level of a Stock Unit
within a Branch.
Table is updated by a batch-overnight aggregation process.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 31 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB_CUTOFF_TOTALS Stores cut-off totals for reports at the Branch level.
BRDB_SU_OPENING_BALANCE Stores the brought forward Cash and Stock position for each
Product in every Stock Unit for a Branch.
Table is updated daily to populate it with the new stock
position.
5.2.5.2 Reporting and Cut-off Storage & Partitioning
The report session data table is distributed across 128 table partitions based on the Fad-Hash value
present in each settlement transaction. The tables are partitioned on the Receipt-Date value that relates
to the time of the transaction. This table is implemented in the form of a ‘Rolling Window’ as described in
Section 5.1.3.
All aggregation and stock tables will be list partitioned with 128 partitions based on the Fad-Hash value in
each record. The table partitions will be static.
5.2.6 Logistical Store
The logistical support data stored in the Branch Database can be classified into upstream and
downstream data. The upstream data includes cash declarations, pouch delivery and pouch collection
details while the downstream data includes planned orders and replenishment delivery details.
The upstream data is passed by the Counter as requests that are logged in the Branch Database from
where they are transferred to heritage system LFS as a part of the batch overnight schedule.
Downstream data is transferred from the LFS into Branch Database via a batch interface. As soon as the
data reaches Branch Database, it will be made available to the Counter however the counter will need to
initiate a request for accessing the data.
5.2.6.1 Logistical Store Layout and Usage
BRDB_BRANCH_DECL Stores the headers and details for all Cash and Stock
BRDB_BRANCH_DECL_ITEM declarations.
BRDB_BRANCH_DECL_MARKER Table is populated by the BAL. Data is also read by a Branch
Database summarisation process for aggregating and onward
routing of data to legacy host system LFS.
BRDB_RX_POUCH_COLL_HEADER Stores the headers and details for all Pouch Collections.
BRDB_RX_POUCH_COLL_DETAILS Table is populated by the BAL and records are then updated
as they get transferred to the LFS system via a batch feed.
BRDB_RX_POUCH_DEL_HEADER Stores the headers and details for all Pouch Deliveries.
BRDB_RX_POUCH_DEL_DETAILS Table is populated by the BAL and records are then updated
as they get transferred to the LFS system via a batch feed.
LFS_PLO_HEADER Stores the headers and details for all Planned Orders.
LFS_PLO_DETAILS Table is populated by a batch copy process using records
read from LFS. The BAL on behalf of the Counter reads
records as requested for by the Counter.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 32 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
LFS_RDC_HEADER Stores the headers and details for all Replenishment
Deliveries.
LFS_RDC_DETAILS
Table is populated by a batch copy process using records
read from LFS. The BAL on behalf of the Counter reads
records as requested for by the Counter.
5.2.6.2 Logistical Store Storage & Partitioning
All upstream and downstream logistical data tables will be list partitioned with 128 partitions based on the
Fad-Hash value in each record. The table partitions will be static.
5.2.7. Branch Information
The Branch information is available in the Branch Database table BRDB_BRANCH_INFO and
BRDB_BRANCH_NODE_INFO. Primary source for this data is Estate management through the EMDB
feed. Below are the details for implementing this feed. .
The functionality will be implemented as a PL/SQL package PKG_BRDB_EMDB_INTERFACE in the
style of all the other non-source-updating interfaces.
The interface will be invoked by TWS once a day as part of the normal schedule.
TWS will call the BRDBX003.sh programs in the same way as other feeds.
The package will interact with the process control framework as other feeds.
The feed meta data will allow the interface to be re-runable more than once a day.
The schema needs updating to put a primary key onto the following tables
EMDB_POST_OFFICE (branch_code)
EMDB_MANAGED_NODE (branch_code, node_id)
We will process the EMDB_POST_OFFICE records first.
All rows in the EMDB_POST_OFFICE will be processed each day.
If a matching row already exists in the BRDB_BRANCH_INFO then
update the columns ip_subnet, number_of_counters, suspend_distribution, mobility_type, service_type,
cto_flag and extended_information with a simple overwrite.
If suspended_distribution_flag then set branch_status as ‘Closed’
else
if it doesn't exist then
obtain BRDB_CURR_BRANCH_ACCOUNTING_CODE from BRDB_SYSTEM_PARAMETERS.
fad-hash = MOD(BRANCH_ACCOUNTING_CODE, 128)
create new record into the BRDB_BRANCH_INFO table.
insert a new row into the BRDB_FAD_HASH_OUTLET_MAPPING table
Update BRDB_CURR_BRANCH_ACCOUNTING_CODE
endif;
On error, log error message in normal way,stop processing and exit with error code set.
We will process the EMDB_MANAGED_NODE records second.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 33 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
All rows in the EMDB_MANAGED_NODE will be processed each day.
Look up the fad_hash for each branch_code from the BRDB_BRANCH_INFO table.
If a matching row already exists in the BRDB_BRANCH_NODE_INFO then
update the columns ip_address_1, extended_information, suspend_distribution_flag with a simple
overwrite.
else
if it doesn't exist then
if the parent branch CTO_flag is TRUE then
get (and later increment) the next unused branch accounting code FOR EACH COUNTER in the range
910000 to 919999
else
branch_accounting_code = branch_code
endif;
create new record in the BRDB_BRANCH_NODE_INFO table.
endif;
On error, log error message in normal way,stop processing and exit with error code set.
commit at the end.
5.2.8 Stock Unit and Accounting
A number of Stock Unit and Accounting related objects will reside in the Branch Database. The
transaction summary objects will be populated by the Branch Database overnight aggregation process.
All balances stored in the database will be derived by the Counter.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 34 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.2.8.1 Logistical Store Layout and Usage
BRDB_DAILY_SUMMARY Table stores a non-cumulative summarised view of
settlement transactions for each Trading Day. The
aggregation level is at Trading-Date, Journal Date, Fad-
Hash, Branch Accounting Code, TP, BP, Stock Unit,
Product Id and Transaction Mode.
Data is populated by Host aggregation process and is used
as an intermediate step towards constructing the Daily-
Cumulative summary.
BRDB_DAILY_CUMULATIVE_SUMMARY Table stores a cumulative summarised view of settlement
transactions for each Trading Day. The aggregation level is
at Trading-Date, Journal Date, Fad-Hash, Branch
Accounting Code, TP, BP, Stock Unit, Product Id and
Transaction Mode.
Data is populated by Host aggregation process and is used
for all accounting related counter reports and as a part of
the SU and Branch rollover processing.
BRDB_SU_OPENING_BALANCE Tables store the opening and closing balances at Fad-
Hash, Branch Accounting Code, Stock Unit, Trading
Period, Balance Period and Product Id.
Table is populated by the BAL using figures sent up by the
Counter as a part of the SU rollover process.
BRDB_BRANCH_OPENING_BALANCE Tables store the opening and closing balances at Fad-
Hash, Branch Accounting Code, Trading Period and
Product Id.
Table is populated by the BAL using figures sent up by the
Counter as a part of the Branch rollover process.
BRDB_BRANCH_STOCK_UNITS Table stores the Stock Unit details.
Data is populated by the BAL based on information passed
up by the Counter.
5.2.8.2 Logistical Store Storage & Partitioning
The Daily-Summary and Daily-Cumulative-Summary are composite partitioned; range-partitioned on
Trading-Date & list-partitioned on Fad-Hash. The Opening and Closing Balance tables are list-partitioned
on Fad-Hash. The data retention is two Trading-Periods for all of these tables.
Stock Units are retained until they have been deleted. All actions performed on Stock Units are
additionally journalised into the Stock Unit History table.
5.2.9 Reference Data
The Branch database requires both dynamic and static reference data to support its operations. Dynamic
reference data is sourced from RDDS database.
Static data is populated as part of the schema build process.
Dynamic reference data is required by the Counter, Branch Access Layer and the Branch database host
processes.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 35 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
As directed by the Branch DB Architecture [R3], the source system RDDS will initiate the transfer of
reference data by making a call to the to the Branch database when a new version of the data is available
by invoking the BRDB harvester.
The harvester or data copy mechanism will run on the Branch database node 1 and will run a number of
pre-defined SQL statements that will copy the reference data updates from RDDS into the Branch
Database.
Dynamic reference data can be further sub-divided into Counter reference data and the reference data
used by the Branch Access Layer / Branch Database Host processes.
5.2.9.1 Counter Reference Data
Dynamic counter reference data covers emergency reference data changes (both Counter specific and
general) and changes to exchange rates.
Data will be loaded in the Branch Database incrementally from RDDS and the data-load will be triggered
by the RDDS schedule.
5.2.9.1.1 Counter Reference Data Layout and Usage
All of the following tables are populated by the RDDS — BRDB batch interface.
RDDS_PACKAGE_TYPE Table maintains a list of all package types. Examples of
package types are “MAIN”, “SPOTRATES”, “MARGINS” and
“OTHER”.
RDDS_DELIVERY_TYPE Table maintains a list of delivery types. Examples include
“COMMON, “PINPAD” etc.
RDDS_PACKAGE Table defines each reference data package that is delivered
down to the counters.
RDDS_DELIVERY Table defines each of the reference data deliverables down to
the counter.
RDDS_PACKAGE_CONTENT Table contains the actual reference data file that will be
delivered down to the counters.
5.2.9.2 Counter Reference Data Storage & Partitioning
All Counter reference data tables are non-partitioned.
5.2.9.3 Host Reference Data
The common host systems interface (discussed later in Section 5.3) will access RDDS for reference data
via a set of views and will refresh the data in equivalent tables owned by the Branch-DB schema owner.
The Reporting service within the Branch Access Layer needs to be able to access reference data going
back 60 days. RDDS generally manages the retention of it's data in BRDB and so the interface can be
kept simple by deleting records from the branch database tables prior to populating them with new
reference data on each day.
Note that a single commit should be used following deletion and population with new data. In this way,
should the RDDS be unavailable or the copy process fail in any way, the previous days data will still be
available to allow operation of the BRDB host processes and BAL.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 36 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
There can be multiple versions of reference data items in each of the RDDS views. The most recent
version of reference data for a key value e.g. Product-Id can be obtained by using the record with highest
Version-Number and whose Valid-From and Valid-To Dates cover the date required.
5.2.9.3.1 Host Reference Data Layout and Usage
All of the following tables are populated by the RDDS — BRDB batch interface.
RDDS_BRANCHES. Provides details of all Post Office Branches including
training branches. It also provides a history of Branch
reference data with each instance having an effective start
date and end date (optional).
RDDS_PRODUCTS Table provides details of all Post Office products. Table
also contains a history of product reference data with each
instance having an effective start date and end date
(optional).
RDDS_ACCOUNTING_NODES The table provides details of all the accounting nodes that
make up the reporting hierarchies. There is one main
reporting hierarchy (top node 3017) defined.
The table contains a history of accounting node reference
data with each instance having an effective start date and
end date (optional).
RDDS_BRANCH_OPENING_PERIODS. The table provides current details (including opening
timings) only of all Post Office Branches including training
branches.
The interface between RDDS and BRDB is described in the Branch Database — RDDS Interface
Specification [R19].
5.2.9.4 Host Reference Data Storage & Partitioning
All Host reference data tables are non-partitioned.
5.3 System Interfaces
5.3.1 Overview
At HNG-X, transactional data is captured in the Branch database in real-time when providing services
such as sale of goods at Post Office branches. The existing Horizon solution consists of a number of host
systems that require the captured data in the same or modified form at various times during the day.
The existing host systems also interface with the PO back office systems and the Reference Data service
and these systems need to transfer data to the Branch database for onward routing via the Branch
Access Layer to the Post Office branches as and when necessary.
The following table summarises the Branch Database interface with various host systems.
No Description Source Target Frequency Volumes
System System
4. I Transfer AP, EPOS, Banking, E- I BRDB TPS ‘Once per day Very
topup, Debit/Credit Card and Bureau High
transactions to TPS. Also transfer
EPOSS Events to TPS.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE, Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 37 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
ed
No Description Source Target Frequency Volumes
System System
2. I Transfer aggregated transaction I BRDB TPS Once per day Medium
totals to TPS
3. I Transfer C12 for Banking, E-topup I BRDB DRS Once per day High
and Debit/Credit card transactions to
DRS
4. Transfer AP transaction details to I BRDB APS. Once per day Medium
APS
5. Transfer Track & Trace transactions I BRDB NPS Interactive feed once every I Medium
from BRDB to NPS-Host 1 min
6. Transfer Guaranteed Reversals from I BRDB NPS Interactive feed once every I Low
BRDB to NPS-Host 1 min
7. I Transfer Planned Order details from I LFS BRDB On Demand. Normally I Low
LFS to BRDB once per day but could be
more in case of late
deliveries.
8. I Transfer Replenishment Delivery I LFS BRDB On Demand. Up to 16 per Low
details from LFS to BRDB day.
9. I Transfer Cash Declaration details I BRDB LFS On Demand. 2 per day Low
from BRDB to LFS
10. I Transfer Pouch Delivery details from I BRDB LFS On Demand. 2 or more per I LOW
BRDB to LFS day
11. I Transfer Pouch Collection details I BRDB LFS On Demand. 2 or more per I Low
from BRDB to LFS day
42. I Transfer emergency common or I RDDS BRDB On Demand. Typically I Low
Outlet Specific Reference Data, Spot Once per day but may be
Rates and Desktop Memos from more
RDDS to BRDB
13. I Transfer Branch, Product, Accounting I RODS BRDB Once per day Low
Node and helpdesk-specific from
RDDS to BRDB
44. I Transfer up to date HNG-X Outlet I BRDB RDMC ‘Once a day Low
information from BRDB to RDMC
15. I Transfer up to date HNG-X Outlet I BRDB RDDS Once a day Low
information from BRDB to RDDS.
16. I TPS Transaction Corrections to I TPS BRDB Once per day Very Low
BRDB
47. I Transfer ongoing Outlet information I TPS BRDB Once per day Very
from TPS to BRDB (hydra only) High
48. I Transfer ongoing _reconciliation I TPS BRDB Once per day Low
information from TPS to BRDB (hydra
only)
19. I Transfer ‘in-day’ Outlet information I TPS BRDB Once per day Medium
from TPS to BRDB (hydra only)
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 38 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
No Description Source Target Frequency Volumes
System System
20. I Branch & Counter status feed from I SYSMAN2 I BRDB Once a day Very Low
SYSMAN2 to BRDB (OMDB)
21. I HNG-X Counter Network Information I ACDB BRDB Once a day Very Low
22. I Branch and Counter Migration Status I BRDB ACDB ‘Once a day Very Low
to ACDB (Hydra only)
23. I Branch detail feed to Helpdesk I BRDB Dispatcht I Once a day Low
System
Table 1 — List of BRDB to/from Legacy Interfaces
Considering the large number of interfaces to be developed, there is a strong need for identifying a
common approach for defining these interfaces and a common mechanism for implementing them.
The main driver for this is cost as aggressive costing of the HNG-X programme presents the challenge of
cost reduction by minimising design and development effort. A common approach also provides the
means of incorporating the odd interface that may need to be introduced as a late design change but in
the HNG-X timescales, at relatively low cost.
A true generic host interface is not proposed because although such an interface is architecturally clean
and presents a truly flexible means for interfacing batch systems, the high design and development effort
involved in constructing such a mechanism would reduce the cost benefit of developing the common
interface.
5.3.2 Identifying Common Functionality
5.3.2.1. Data Copy Approach
The common interface relies on the fact that all of the interfaces listed earlier fall into two types:
» Data primed for copying to existing host systems is simply copied across the interface using the
SQL statement InseRT INTO... SELECT FROM...
>» Data is fetched from source table/s with either row-locking or ROWIDs to ‘remember’ them
(SELECT FROM... WHERE...), copied across the interface (INSERT INTO... SELECT FROM...
WHERE...) and the remembered records are updated in the source table to mark as ‘copied’
(UPDATE... WHERE...)
Interfaces involving large amounts of data and are executed once per business day fall into the former
category while those that copy across smaller amounts of data or are executed more than once per day
fall into the later category. One exception to this is that some of the interfaces transferring reference data
use the first type of approach with an additional preceding step of clearing down the target table/s.
Interfaces that fall into the second category need to run multiple SQL statements to implement them.
There is also the need to ‘remember’ the rows affected by a SQL statement so that they can be marked
off as transferred in a final SQL statement. Although the most efficient way of doing this is to ‘remember’
the Oracle ROWIDs of source records that are transferred across the interface, at Oracle 10gR2, there is
a vulnerability of this approach because of the potential use of ‘flashback’. There are no plans to use
‘flashback’ in the Branch Database.
Oracle guarantees that once assigned, the ROWID of any record remains constant (provided ‘flashback’
feature was not used) unless the row length increases by more than the allowance made for increases in
the block, which then causes Oracle to migrate the entire row to a different block and assign a new
ROWID. The other reason of ROWIDs changing is table restructuring through export/import or other such
means. Since both of these activities are not expected to happen while the batch copy process is
executing, ROWIDs can safely be used to mark records as transferred.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 39 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Another potential approach is to programmatically remember the records fetched, and use them when
updating the table to set the flag. Although this approach does not have the vulnerabilities present for
using ROWIDs, it is also not as performant as using ROWIDs.
To facilitate implementation of interfaces that require the source tables to be updated based on the
ROWIDs of records transferred, a temporary® working table with the following structure will be delivered
for each Host interface:
Table Name: WKG_Name of the Host interface as defined in BRDB_HOST_INTERFACE_FEEDS
Column Name Datatype & Size_I Mandatory Comments
FAD_HASH Number (3) Yes Stores the Hash-value of the Branch that the record
belongs to. Used as a key for table partitioning.
SRC_ROWID ROWID Yes Stores the ROWID of the source record that is being
transferred to the corresponding table in the target
database.
SOFT_DELETED_YN I Varchar2 (1) Yes Values are “Y" (Yes) and "N” (No).
It is used to exclude rows from the update of
the source table - because the data has not
been loaded into the target table (due to a data
error).
The table is list-partitioned on Fad-Hash with 128 list partitions all spread across 128 tablespaces. Table
access is by Fad-Hash as described in Section 5.1.
5.3.2.2 Fad-Hash aware Table Access
All partitioned tables in the Branch Database must be accessed is a fad-hash aware manner i.e. Fad-
Hash (sub) partitions of the table must be accessed using the correct instance. The view
BRDB_FAD_HASH_CURRENT_INSTANCE provides the ‘current’ Fad-Hash to instance mappings for all
available instances.
5.3.2.3. Handling Exceptions
Exceptions encountered by interfaces that are driven through the Branch Database would be handled
with a common approach. If an Oracle exception occurs while transferring data across the interface, the
exception will be checked to see if it were a data-related exception. A simple way of doing so is to log a
list of exception codes for data-related exceptions in a static reference data table named
BRDB_ORACLE_ERROR_CODES and to compare the exception that is raised by the interface against
this list.
Data related exceptions should not cause the interface to fail. The reason for the error is likely to be that
a few records would have violated a constraint of the target table. These records should be copied to an
exceptions table and rest of the interface should be processed. For interfaces involving marking the
source records as ‘processed’ by setting a flag/date timestamp, the erroneous records should not be
marked as ‘processed’. This gives support the chance to correct the data in the input tables before the
next scheduled run of the interface so that the data gets transferred.
Data exceptions should be logged in a common table named BRDB_HOST_INTERFACE_EXCEPTIONS
unless otherwise stated e.g. unless there is a pre-defined exceptions table in batch host applications.
Each erroneous record should be logged as a separate row in the table. Against each row, the Oracle
error code and details should also be logged.
5 Table may not be defined as “temporary” in Oracle terms but its usage will be similar to that for typical
temporary tables.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 40 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
There is a limit on the number of records each interface can log into this table. This will be driven to a
BRDB system parameter and the initial value should be set to 1000.
If the interface has encountered one or more data exceptions, then on completion of processing an
Operational exception should be logged in order to highlight to support the presence of data exception
details in the process logs and error tables.
All non data-related errors such as system errors or connection issues should result in the job exiting with
a failure.
5.3.2.4 Metadata driven solution
One of the approaches suggested by the high level design is using a metadata-driven approach for
defining the interfaces. Such an approach provides the necessary flexibility for adding, changing or
removing interface definitions. Refer to for details.
5.3.3. Failures and Restartability
The logical processing unit for all interfaces involving Fad-Hash partitioned / sub-partitioned tables as
either the source or target is a Fad-Hash value. The use of HADDIS-compliant process-control measures
will ensure that when the data for a Fad-Hash value has been transferred successfully, process-control
will record the fact and prevent the same partition from being re-processed in the event of a restart. Use
of process-control also ensures that in the event of a restart after failure, the failed Fad-Hash is
reprocessed.
For interfaces that do not involve Fad-Hash partitioned / sub-partitioned tables, the logical process unit is
the entire interface. In the event of a restart after failure, the interface is re-processed.
Note that for the restartability to work correctly, the interface must be able to rollback any changes made
or data transferred before the failure occurred.
5.3.3.1. Handling Node Unavailability
One of the advantages of using an Oracle RAC database is that the database is available for use even
when one or more nodes (servers hosting the Oracle instances) are down. Nodes could be unavailable
for a variety of reasons from OS crashes to planned maintenance work.
Every batch interface that copies transactional data along with the copy job schedule needs to handle
unavailability of one or more nodes. A node could become unavailable before the interface starts
executing or while it is running. Both types of situations must be handled and the copy job schedule must
complete using the available nodes to copy the data for the pending Fad-Hash values across.
Node unavailability needs to be handled differently for jobs that are controlled at Fad-Hash level from the
jobs that run as interactive batch feeds e.g. NPS T&T and GREV interfaces.
Fad-Hash Level Controlled Jobs
Jobs that are controlled at Fad-Hash level are the ones that typically run at defined times during the day
and for whom it is absolutely essential for all of the transactions to be transferred across the interface in
that run of job.
The solution proposed below is simple to implement and works within the constraints of the job
scheduling software TWS.
The batch interface will handle failures such as Oracle instance going down by bailing out with a specific
error code, say 99. Although the scheduling software will not be able to distinguish such errors from other
application failures, which typically result in error code of 1, the error code of 99 will aid supportability.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 41 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The scheduler waits for all instances of the copy job to either finish execution (successfully or otherwise)
or for a small time period e.g. 15 minutes to elapse from the start of the schedule, before running a
‘check’ job which checks if all of the possible Fad-Hash values (128 of them) have been processed
successfully by the interface job and if so it returns a Success. If one or more Fad-Hash partitions have
not been processed at all or the copy has not completed successfully, the check job returns a Failure.
If the ‘check’ job returns a Failure, the scheduler invokes ‘recovery’ batch interface jobs on all of the
nodes with exactly the same parameters as before to allow the copy mechanism to process the pending
Fad-Hash values.
This approach relies on the Oracle Fast Application Notification utility to quickly detect and record the fact
that the node/instance is down in the table brdb_operational_instances. The Fad-Hash filtering SQLs
that are run by the batch interface will return a different set of Fad-Hashes for each instance. The new set
of fad-hashes will include those that normally belong to the failed instance but have been redirected to
the alternate nodes.
It is prudent to run the ‘check’ job again to ensure that all Fad-Hashes have been covered. If the check
job fails again, a high-priority alert will be raised to allow the support lines to intervene.
Example
The recovery schedule structures can be best explained through an example. For the purpose of this
example only, it is assumed that the common batch interface described in is implemented. If an alternate
method was used, the approach outlined by this example is still valid.
The full command used to invoke the routine Bulk-copy (batch interface) process is expected to be:
BulkCopy.sh Interface-Name Business-Date Node-Id
Let us assume that the overnight transaction copy interface from Branch Database to TPS is called
“BRDB_TXNS_TO_TPS”. BulkCcopy.sh is actually script BRDBX003.sh.
With business date as 20" Nov 2009, the scheduler will run four instances of the Bulk-copy process for
this interface:
On Node‘ execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 1”
On Node2 execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 2”
On Node3 execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 3”
On Nodeé4 execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 4”
If the job on Node3 fails during execution and an error code of 99 is returned back to the scheduler, once
the conditions described earlier are satisfied, the check job is run and if it returns a failure, four further
recovery jobs are fired by the scheduler. Each job will be passed exactly the same parameters as before.
On Node1 execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 1”
On Node2 execution command is “BRDBX003.sh BRDB_TXNS_TO TPS 20061120 2”
On Node? execution command is “BRDBX003.sh BRDB_TXNS TO TPS 20061120 3”
On Node4 execution command is “BRDBX003.sh BRDB_TXNS_TO_ TPS 20061120 4”
The recovery jobs will attempt to re-copy the data for all fad-hashes that have the respective nodes as
priority —- 1 node and will also cover all those fad-hashes whose priority — 1 node is the failed node but the
priority — 2 node is the node the recovery job instance runs on.
The information is depicted diagrammatically below for failure of Node-3:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 42 of 197
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJITSU
FUJ00235023
FUJ00235023
ed
Start of
Node BRDB_TXNS_TO_TPS
ode interface
¥
Failed with any failure
Have all other job
instances started?
No
fas it been N minute:
ce schedule started
Yes
x
Check-Script
Checks if Fad-Hashes have 4
been processed
If returned failure
v —_-
BRDBX003.sh BRDBX003.sh
BRDB_TXNS_TO_TPS BRDB_TXNS TO TPS
20061120 1 20061120 2
¥
Check-Script
Checks if Fad-Hashes have
been processed
If returned failure
a
Raise high priority
operator alert
Figure - 6 Bulk Copy Schedule demonstrating Node Unavailability
Yes
No.
Have all other job
instances finished?
Yes
¥
BRDBX003.sh
BRDB_TXNS_TO_TPS
20061120 4
The above-mentioned approach is applicable for nodes that become unavailable before or during
execution of the Bulk copy process.
The changes required for implementing the proposed changes for handling node availability to the
common bulk-copy mechanism described earlier are minimal.
Interactive Batch Jobs
Jobs that run as an interactive batch feed are the ones that are either run at frequent intervals by the
scheduler or run in the foreground and wake up after pausing for a short period of time.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 43 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
For such jobs, if some of the data is not copied across in a particular run due to a non-persistent error,
there is always the next run to catch up with the data copy.
The solution proposed for such jobs in the event of a failure is to rerun the job instance after pausing for a
short period of time to allow the transient error such as a network glitch to disappear. If the job instance
fails again, raise a high priority alert to allow the support teams to quickly respond to, resolve the problem
and reinstate the interactive batch feed.
5.3.4 Host Interfaces
5.3.4.1 TPS
The BRDB — TPS batch interface will perform the following functions:
> BRDB Transactions to TPS: Once a day transfer of transactional data and EPOSS Events from
BRDB to TPS to allow TPS to perform HR-SAP and POL-FS summarisations and onward route
the transactional and event data to POL-MIS.
>» BRDB Transaction Totals to TPS: Once a day transfer of aggregated transaction totals from
BRDB to TPS to allow TPS to perform reconciliation with similar totals derived from the
transactional feed delivered from the Branch Database to TPS.
> BRDB Cut-off Summaries to TPS: Once a day transfer of counter report cut-off summary
information from BRDB to TPS to allow TPS to pass these on to the POL-FS.
>» TPS Transaction Corrections to BRDB: Once a day transfer of Transaction corrections from
TPS to BRDB. These messages will be relayed by the Branch Access Layer to the Counter,
which uses them to perform accounting corrections.
In addition for the duration of the pilot, TPS will receive a new Migration-specific feed of all bits of
information that it does not receive from the TPS harvester e.g. current stock position, non-EPOSS
events, T&T sack details, cut-off data for cut-off reports etc. This information will be collated in TPS for all
outlets that have not migrated to HNG-X and relayed to the Branch Database in the form of once a day
type feeds.
5.3.4.1.1 BRDB Transactions to TPS
This batch feed will run after the logical event “Start of BRDB-Batch® has occurred.
This feed is characterised by very high data volumes however the implementation is simple as is depicted
by the following diagram:
6 This will be implemented in the form of a scheduler job which either creates a flag-file or sets a
scheduler variable to TRUE. The time is expected to be 19:00 or thereabouts. Refer to the Scheduling
High Level Design [R12] for details.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 44 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
I Bulk coy or
pe fC BRDB Single Copy (if A
BAL 7 BRDB I 7 TPS
Settlement I =z! I [I Transaction ae \ == Batch Interface erron I Transactional I
Service V1 II Sub-partition I I ~~ I Instance #1.4 I I & - (I Tables I I
“I I Maps 128 Fad-Hashes I . °
Settlement to 64 tables
Requests from
Counter
BRDB-Host Domain TPS-Host Domain
Figure — 7 BRDB Transactions to TPS.
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances running for each of the following transaction types:
« Automated Payment Transactions
¢ Electronic Point of Sale Transactions
e Network Banking & E-Topup Transactions
e Debit Card Transactions
e Bureau De Change Transactions
« EPOS Events
e Summary of Cut Off Events
* Transaction Totals
For each transaction type from above, the interface steps involve:
e Fetching records for the current day's Trading Date from the appropriate Fad-Hash sub-partition
in the BRDB source table where the TRANSFERRED_FROM_LEGACY_YN flag value is set as
e Inserting records into the appropriately numbered target table in TPS.
Copied records need not be marked in the source BRDB tables as ‘processed’.
The 128 Fad-Hash sub-partitions in BRDB will be mapped to 64 TPS partitions as per the following:
Fad-Hash #0 => TPS Table #1
Fad-Hash #1 => TPS Table #1
Fad-Hash #2 => TPS Table #2
Fad-Hash #3 => TPS Table #2
Fad-Hash #4 => TPS Table #3
Fad-Hash #127 => TPS Table #64
Any records that could not be copied across to TPS due to a data-related exception (as opposed to other
exceptions such as system level or connection related) will be logged in the TPS Harvester Exceptions
table (TMS_ HARVESTER_EXCEPTIONS).
The source and target data attribute mappings / derivations are defined in the Branch Database — TPS
Interface Specification [R17].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 45 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.3.4.1.2 BRDB Transaction Totals to TPS
The batch feed will run after the logical event “Start of BRDB-Batch” has occurred.
This feed is characterised by medium data volumes and simple implementation.
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the interface with each instance running on a Branch Database node.
The interface steps involve:
e Fetching records for the current day's Trading Date from the appropriate Fad-Hash sub-partition
in the BRDB~ source table BRDB_TX_TRANSACTION_TOTALS) where _ the
TRANSFERRED_FROM_LEGACY_YN flag value is set as ‘N’.
e Inserting records into the un-partitioned target table in TPS
(TMS_RX_TRANSACTION_TOTALS).
Copied records need not be marked in the source BRDB tables as ‘processed’.
The 128 Fad-Hash sub-partitions in BRDB will be mapped to a single TPS transaction table.
The source and target data attribute mappings / derivations are defined in the Branch Database — Legacy
Host Interface Specification[R17].
5.3.4.1.3 Cut Off Summaries to TPS
The batch feed will run after the logical event “Start of BRDB-Batch” has occurred.
This feed is characterised by medium data volumes and simple implementation.
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the interface with each instance running on a Branch Database node.
The interface steps involve:
e Fetching records for the current day's Trading Date from the appropriate Fad-Hash partition in
the BRDB source table BRDB_RX_CUT_OFF_SUMMARIES.
e Inserting records into the appropriately numbered target table in TPS.
Copied records need not be marked in the source BRDB tables as ‘processed’.
The 128 Fad-Hash sub-partitions in BRDB will be mapped to 64 TPS partitions as per the following:
Fad-Hash #0 => TPS Table #1
Fad-Hash #1 => TPS Table #1
Fad-Hash #2 => TPS Table #2
Fad-Hash #3 => TPS Table #2
Fad-Hash #4 => TPS Table #3
Fad-Hash #127 => TPS Table #64
Any records that could not be copied across to TPS due to a data-related exception (as opposed to other
exceptions such as system level or connection related) will be logged in the TPS Harvester Exceptions
table (TMS_HARVESTER_EXCEPTIONS).
The source and target data attribute mappings / derivations are defined in the Branch Database — TPS
Interface Specification [R17].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 46 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.3.4.1.4 TPS Transaction Corrections to BRDB
This batch feed is initiated by the TPS-Host batch schedule and typically runs at the tail end of the TPS.
schedule TPS_TC, which run in the early hours of the day.
This feed is characterised by very low data volumes and a simple implementation. The interface is
implemented in the form of a single job instance. The instance runs on a pre-defined BRDB-Host node
and node failure recovery actions involve running on other nodes.
The interface steps for copying transaction corrections across from TPS to BRDB involve:
« Fetching all transaction correction records from TPS table TMS_TX_TPS_TC_DETAIL, which
have not been copied across to BRDB (indicated by HNGX_ACTIONED_IND values of Null / ‘N’),
from TPS.
« Inserting records into the target table (TPS_TXN_CORRECTION_DETAILS) in BRDB.
e Updating the copied records in TPS to mark them as ‘copied’ by setting the
HNGX_ACTIONED_IND flag value to ‘Y’.
The source and target data attribute mapping / derivation are defined in the Branch Database — Legacy
Host Interface Specification [R17].
5.3.4.1.5 Hydra-specific Migration Feeds from TPS
These batch feeds will run after the logical event “Start of BRDB-Batch” has occurred and after the
completion of the execution of the migration-specific TPS harvester. Refer to [R12] for details of schedule
dependencies.
These feeds are characterised by a varied range of volumes (low to very high) and the number of tables
affected within the Branch Database. The following diagram presents a pictorial view of the interface:
PS I BROB
I ({ rranseciona ['\ ln, [Iimtege mance). (! ansacon be [I
ay II Tables v 1 Sub-parition I
sos v I 64 \ 2 \\ #000..127\
¢ \ deere Maps single view to 128 Fad-Hashes al
1 Bahaneed’
TPS HarvesterI __‘nyds’_. (pg Lod ( BROB
instances I “SpeciieHeSt” I Migration End-of- I I cxtm}> [I Mleriege Intence > [Ongoing Migration I I
ulna \_ Day Data ; \ Counter Totais \)
TPS al BRDB/\
S I tn-Day' Mirtion sus, [I Interface instance In-Day Migration
ad $A > I moe
i
TMS Harvester BRDB-Host Domain
c TPS-Host Domain
Domain
Figure - 8 Hydra-specific feeds from TPS
Transactional Data
The ongoing hydra-specific interface for transactional data is initiated by the TPS operational schedule
and implemented in the form of four instances running for each of the following transaction types:
e Automated Payment Transactions
¢ Electronic Point of Sale Transactions
e Network Banking & E-Topup Transactions.
¢ Debit Card Transactions
e Bureau De Change Transactions
For each transaction type from above, the interface steps involve:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 47 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
e Fetching records for the current day's Trading Date from the appropriate partition in the TPS
source table.
e Inserting records into the target table in BRDB while populating the Fad-Hash value for the
Branch.
«Inserting a subset of the record into the BRDB table BRDB_RX_REP_SESSION_DATA to
facilitate counter reports, while populating the Fad-Hash value for the Branch.
e Inserts into the BRDB_ transactional table should match inserts __ into
BRDB_RX_REP_SESSION_DATA. Any data exception should cause the failed record to be not
written to both the tables.
e Set the TRANSFERRED_FROM_LEGACY_YN flag in the BRDB tables to “Y” for all transferred
transactions.
Copied records need not be marked in the source TPS tables as ‘processed’.
There is no defined rule for mapping the 64 TPS partitions to the 128 Fad-Hash sub-partitions in BRDB
and it is recommended that each of the four interface instances use the TPS overall view to fetch records
for specific Fad-Hash values.
Reconciliation Data
The ongoing hydra-specific interface for reconciliation totals from the counter is initiated by the TPS
operational schedule and implemented in the form of a single instance of the interface.
The steps to be executed by the interface step are:
e Fetch records for the current day's Trading Date from the migration preparation TPS source table
TMS_RX_HNGX_MIGRATION_PREP.
e Insert those records into the target table in BRDB TPS_HYDRA_RECON_TOTALS while
enriching it with the Fad-Hash value for the Branch.
Copied records should be marked in the source TPS table as ‘processed’.
The source and target tables are both non-partitioned.
In-Day Migration Data
The in-day hydra-specific interface for the migration object from the counter is initiated by the TPS
operational schedule and implemented in the form of a single instance of the interface.
This batch feed will bring across all of the information necessary for a just-migrated Horizon Branch to be
able to operate under HNG-X. This includes the Branch's cash & stock positions, Users, Roles and Stock
Units, sack details for the various Remittance outs and cut-off events for cut-off reports.
The steps to be executed by the interface step are:
e Fetch records for the current day's Trading Date from the in-day migration TPS source table
(TMS_RX_HNGX_MIGRATION_DAY).
* Insert those records into the target table TPS_HYDRA_INDAY_DATA in BRDB while enriching it
with the Fad-Hash value for the Branch.
Copied records should be marked in the source TPS table as ‘processed’.
The source and target tables are both non-partitioned.
The source and target data attribute mappings / derivations are defined in the Branch Database — Legacy
Host Interface Specification [R17]
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 48 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.3.4.2 APS
The BRDB - APS batch interface will perform one function (BRDB Transactions to APS) of once a day
transfer of AP transactional data from Branch Database to APS to allow APS to onward route the
transactional data to the AP Clients.
5.3.4.2.1 BRDB Transactions to APS
The batch feed will run after the logical event “Start of BRDB-Batch” has occurred.
This feed is characterised by high data volumes however the implementation is simple as is depicted by
the following diagram:
I Bulk cory or
BAL (f BRDB-/\ Single Copy (if A
nt ff { Generic interface error] I aps \
Settlement I > I II AP Transactions I b ; /\
SEnies 71 I) sub-partiion I I “7 I Instance #1..4 I I pm a {I Transactional
\\ 7 \i KA able }
Maps 128 Fad-Hashes
toa single table
Settlement (Metadata () < I
Requests from I
Counter
BRDB-Host Domain APS-Host Domain
Figure — 9 BRDB Transactions to APS
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the generic bulk copy interface running for each of the following transaction type:
e Automated Payment Transactions
The interface steps involve:
e Fetching records for the current day's Trading Date from the appropriate Fad-Hash sub-partition
in the BRDB source table (BRDB_RX_APS_TRANSACTIONS) where the
TRANSFERRED_FROM_LEGACY_YN flag value is set as ‘N’.
* Inserting records into the un-partitioned target table in APS (TMS_RX_APS_MCBC_TXNS).
Copied records need not be marked in the source BRDB tables as ‘processed’.
The 128 Fad-Hash sub-partitions in BRDB will be mapped to a single APS transaction table.
The source and target data attribute mappings / derivations are defined in the Branch Database — Legacy
Host Interface Specification[R17].
5.3.4.3 DRS
The BRDB — DRS batch interface will perform one function (BRDB Transactions to DRS) of once a day
transfer of C12 confirmation messages from the Branch Database to DRS to allow DRS to reconcile the
transaction parts and in case of Debit-Card C12 messages, to onward route to streamline.
5.3.4.3.1_ BRDB Transactions to DRS
The batch feed will run after the logical event “Start of BRDB-Batch” has occurred.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 49 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
This feed is characterised by high data volumes however the implementation is simple as is depicted by
the following diagram:
I Bulk con or
aE ~~ BRDB a } Single Copy (if mn
I ff \ Generic Interface erro! prs / \
Settlement [= >I II C©12Messages I ff i \
Sanies V III Subpartton I = Instance #1...4 {I Ct2Input I I
\\ wo00..127 \/ TV \ Table /
l I Maps 128 Fad-Hashes /
Settlement Gee toa single’ table
Requests from I I
Counter
BRDB-Host Domain DRS-Host Domain
Figure - 10 BRDB Transactions to DRS
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the generic bulk copy interface running for each of the following transaction types:
e C12 confirmation messages for Network Banking and E-topups
e C12 confirmation messages for Debit Card
The interface steps involve:
e Fetching records for the current day's Trading Date from the appropriate Fad-Hash sub-partition
in the BRDB source table.
e Inserting records into the target table in DRS. Even though the target table is hash-partitioned, it
needs to be accessed at table level as opposed to partition level. Even distribution of
transactions across all eight partitions in the DRS input table can be achieved by using the DRS.
sequence TMS_REC_SEQ.
Any records that could not be copied across to DRS due to a data-related exception (as opposed to other
exceptions such as system level or connection related) will be logged in the DRS Input Exceptions table
(DRS_C12_INP_EXCEPTIONS).
The source and target data attribute mappings / derivations are defined in the Branch Database — Legacy
Host Interface Specification[R17].
5.3.4.4 LFS
The BRDB - LFS batch interface will perform the following two functions:
> BRDB messages to LFS: Twice a day transfer of Cash Declarations and hourly transfer of
Pouch Collection and Pouch Delivery details from BRDB to LFS for onward routing to SAPADS.
>» LFS messages to BRDB: Transfer of Planned Orders (typically once per day) & Replenishment
Delivery details (up to 16 times a day) from LFS to BRDB. These messages will be relayed by the
Branch Access Layer to the Counter in response to requests from the Counter.
5.3.4.4.1_ BRDB messages to LFS
The batch feed will run at regular intervals throughout the day depending on the type of feed...
This feed is characterised by low data volumes and simple implementation.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 50 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the generic bulk copy interface running for each of the following types of messages:
e Cash Declarations
e Pouch Deliveries
« Pouch Collections
The interface steps involve:
« Fetching all messages that have not been copied across i.e. LFS-Delivered-Timestamp is not
set, for the above-mentioned types from BRDB.
e Inserting those records into the target tables in LFS. Inserts of detail records need to match
header records. Any data exception in header/detail record should result in corresponding
detail/header records to not be copied across. For such records, the LFS-Delivered-Timestamp
should remain un-set.
« Updating the LFS-Delivered-Timestamp for all copied records in BRDB to mark them as ‘copied’.
For each message type, the above steps need to form a single commit transaction to ensure data
integrity and a consistent restart point. Messages belonging to all Outlets need to be copied across
regardless of whether the Outlet is trading under Horizon or HNG-X.
The source and target tables and data attribute mapping / derivation are defined in the Branch Database
— Legacy Host Interface Specification [R17].
5.3.4.4.2 LFS messages to BRDB
The batch feed will run at the tail end of the PLO, RDC file processing schedules in LFS. Since these LFS
schedules run on-demand, the copy jobs may run within core hours.
This feed is characterised by low data volumes and simple implementation.
It is implemented in the form of four instances (one on each node) of the generic bulk copy interface for
each of the following types of messages:
« Planned Orders
e Replenishment Delivery Messages
The interface steps involve:
« Fetching all messages that have not been copied across i.e. HNGX-Actioned-Tsmp flag is not
set, for the above-mentioned types from LFS.
e Inserting records into the target tables in BRDB. Inserts of detail records need to match header
records. Any data exception in header/detail record should result in corresponding detail/header
records to not be copied across. For such records, the LFS-Delivered-Timestamp should remain
un-set.
« Updating the HNGX-Actioned-Tsmp flag to SYSTIMESTAMP for all copied records in LFS to
mark them as ‘copied’.
The above steps need to form a single commit transaction to ensure data integrity. Messages belonging
to all Outlets need to be copied across regardless of the Outlet is trading under Horizon or HNG-X.
The source and target tables and data attribute mapping / derivation are defined in the Branch Database
— Legacy Host Interface Specification [R17].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 51 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.3.4.5 RDDS
The BRDB — RDDS batch interface will perform the following functions:
> BRDB Reference Data from RDMC/RDDS: Once a day transfer of Reference Data to BRDB.
The interface will transfer data from RDDS to be used by BRDB-Host & the BAL for internal
processing and will also transfer Outlet opening times from RDMC to be supplied in future to the
helpdesk system.
> BRDB Host Reference Data to RDDS: Once a day transfer of Estate Management Data from
BRDB to RDDS. This data will be used by RDDS for its internal processing.
> BRDB Host Reference Data to RDMC: Once a day transfer of Estate Management Data from
BRDB to RDMC. This data will be used by RDMC for its internal processing.
> Counter Reference data from RDDS: Once a day (fixed) plus on-demand transfer of counter
specific reference data from RDDS to BRDB. This includes data such as Bureau De Change spot
rates, emergency counter ref-data changes and desktop memos.
The following diagram depicts the data flows between RDMC/RDDS and BRDB.
I BRDB-RDMC
Interface Instance
RDMC
HNG-X Outlets &
l BRDB
HNG-X Outlets &
BRDB-RDDS le Counters
RDMC-Host Domain . alsdess nce.
RDDS ( aA BRDB
HNG-X Outlets & Products &
Counters 4 Accounting Nodes
Fase _ >» RDDS-BRDB #1
oe Interface Instance
BRDB
Accounting Nodes Outlets & Opening
ROW Times
(Outlets & Opening I
Times
BRDB
RDDS RDDS-BRDB #2 Counter
Counter Interface Instance Reference Data &
Desktop Memos
Reference Data &
Desktop Memos I
RDDS-Host Domain
BRDB-Host Domain
Figure — 11 BRDB interfaces with RDMC/RDDS
5.3.4.5.1 BRDB Host Reference Data from RDMC/RDDS
The RDDS-to-BRDB host feed will populate the Branch Database with Products, Accounting Periods
and Branch information. The interface will also populate the Branch Database with Counter Report
definitions.
Additionally the interface will also populate the Branch Opening timings information for use by the
helpdesk system from the RDMC database.
The batch feed will run once a day and is triggered by the RDDS system operational schedule.
This feed is characterised by very low data volumes and a simple implementation. The interface is
implemented in the form of a single instance copy job. The process unit is at the interface level i.e. all
interface steps will be executed as a part of a single commit.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 52 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
This interface covers the following Branch Database reference data tables:
RDDS_BRANCHES
RDDS_ACCOUNTING_NODES
RDDS_PRODUCTS
RDDS_BRANCH_OPENING_PERIODS.
The instance will run on a pre-defined BRDB-Host node and connect to the instance using bequeath
protocol. BRDB node/instance failure recovery actions involve a single retry by re-running on one of the
other available nodes by using the BRDB service. The scheduler will provide an extra command-line
parameter to facilitate a rerun. RDDS node/instance failure will not result in a rerun.
The interface steps for copying host reference data to BRDB involve:
e Deleting all host reference data that is about to be refreshed from the source system.
e Fetching new reference data from RDMC/RDDS and inserting into the target tables in BRDB.
e Deriving the current day's de-normalised view of the Accounting node to Product mappings. This
de-normalisation is described in detail below.
Accounting Node — Product De-normalisation
The table BRDB_ACC_NODE_PRODUCT_MAPPING provides a de-normalised materialized
view that identifies each product with all of the accounting nodes to which it is related at each
level in the hierarchy.
For each accounting node, all the products that either directly or indirectly maps to it are
extracted from the BRDB_CURRENT_ACCOUNTING NODES view and inserted into the
BRDB_ACC_NODE_PRODUCT_MAPPING table.
The materialized view should be refreshed once its source tables in BRDB have been refreshed.
The source and target tables and data attribute mapping / derivation are defined in the Branch Database
-—RDMC/RDDS Interface Specification [R19].
5.3.4.5.2 BRDB Host Reference Data to RDDS
The BRDB-to—-RDDS host feed will populate RDDS with up to date status information on Branches using
data provided by Estate Management. The interface will be owned by RDDS-Host and is discussed in the
RDDS High Level Design [R32].
5.3.4.5.3_ BRDB Host Reference Data to RDMC
The BRDB-to—RDMC host feed will populate RDMC with up to date status information on Branches. The
contents and mechanics of the interface are owned by the RDMC-Host and are discussed in RDMC High
Level Design [R33].
5.3.4.5.4 Counter Reference Data from RDDS
This on-demand batch feed will run at various times during the day and will be driven by the RDDS
system operational schedule.
This feed is characterised by low data volumes but a more complicated implementation. The interface is
implemented in the form of a single instance, which will run on a pre-defined BRDB-Host node and node
failure recovery actions involve running the same job on one of the other nodes.
This interface covers the following Branch Database counter reference data tables:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 53 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJITSU
RDDS_PACKAGE_TYPE
RDDS_PACKAGE
RDDS_PACKAGE_CONTENT
RDDS_DELIVERY_TYPE
RDDS_DELIVERY
Interface Steps
This interface is different from the common interface functionality identified in Section 5.3.2 hence this
section describes the interface steps involved in detail.
The BRDB interface process will be invoked by an RDDS-host process via TWS. The BRDB Interface will
be passed in the command-line arguments that are mandatory for the interface i.e. Interface-Name,
Business Date and Node-Id.
The BRDB interface will access the RDDS table RD_TRANSFER_CONTROL to read the list of
unprocessed Package-Types i.e. records where status is 0 (not-started) or 1 (Started but not completed).
Records will be fetched in chronological order using the creation_date column.
For each Package-Type fetched, the BRDB interface will update the RD_TRANSFER_CONTROL table
to set the status to 1 and lock the record and will use the Package-Type (e.g. SPOTRATES, MAIN etc) as
an argument’.
The BRDB interface will identify the mismatches between the above-mentioned Branch Database tables
and their corresponding tables in RDDS by issuing SQL queries. Queries will be based on Primary-Key
values and may involve joining parent tables where necessary to filter on the input package-type
argument.
SQL Template #1 to identify records to be inserted into the Branch Database table:
SELECT Primary-Key-values
FROM RDDS-table-name(s)
WHERE package-type = ‘Input-package-type’
(optional AND...)
MINUS
SELECT Primary-Key-values
FROM BRDB-table-name(s)
WHERE package-type = ‘Input-package-type’
(optional AND...)
SQL Template #2 to identify records to be deleted from the Branch Database table:
SELECT Primary-Key-values
FROM BRDB-table-name(s)
WHERE package-type = ‘Input-package-type’
(optional AND...)
MINUS
SELECT Primary-Key-values
FROM RDDS-table-name(s)
WHERE package-type = ‘Input-package-type’
(optional AND...)
The above-mentioned templates apply to all of the BRDB counter reference data tables with the
exception of RDDS_PACKAGE and RDDS_PACKAGE_TYPE
For RDDS_PACKAGE the Select-list needs to include the column EXPIRY_DATE in addition to the
primary keys for the table. This is to cover scenarios where emergency changes to the RDDS-equivalent
7 With one exception as discussed later in this section.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 54 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
tables involve expiring the current version of counter reference data and replacing it with a new version.
Note that Expiry-Date column can have Null values.
The RDDS_PACKAGE_TYPE table will not be refreshed on a nightly basis. It will be refreshed whenever
the value of system parameter called “Feed-Name-in-uppercase_REFRESH_YN’” is set to “Y”.
Once all the changes have been made to the counter Reference-Data, the transfer-control table will be
updated to set the status to 2 and record the completion-date. All records for the reference data change
will either be committed or rolled back (in case of an error) as one unit alongside the transfer control
update. In case of a failure, the Transfer-Control status for that package type must be left at its current
state and an operational exception must be raised to make support aware of the failure. However the
process should exit with success.
The BRDB interface process will also be capable of checking and using the value of system parameter
called “Feed-Name-in-uppercase_REFRESH_YN” of “Y” to indicate a complete refresh of all data in
BRDB Counter reference data tables. Complete refresh involved deleting all records from the target
tables in BRDB and refreshing with data from source tables in RDDS. The system parameter value will
usually be set to “N” is only meant to be used by Support in exceptional circumstances and this will be
covered in more detail in the Branch Database Support Guide.
The TWS implementation of this job for Spot-Rates is in the form of an on-demand schedule that is
triggered by the successful completion of the RDDS TWS job that processes the Counter Reference Data
into the RDDS interface tables. The TWS implementation of the job for all packages other than ‘Spot-
Rates’ is in the form of a job that typically runs once a day but whose execution is dependent on the
completion of the RDDS TWS job that processes Counter Reference Data and makes it available in the
interface tables in RDDS.
The source and target data attribute mapping / derivation is driven off metadata and is defined in the
Branch Database - RDDS Counter Reference Data and Memos Interface Specification [R20].
5.3.4.5.5 Desktop Memos from RDDS
This on-demand batch feed will run at various times during the day and will be driven by the RDDS
system operational schedule.
This feed is characterised by very low data volumes and a simple implementation. The interface is
implemented in the form of a single instance, which will run on a pre-defined BRDB-Host node and node
failure recovery actions involve running the same job on one of the other nodes.
This interface covers the following Branch Database desktop memo tables:
RDDS_DESKTOP_MEMO
RDDS_DESKTOP_MEMO_DISTR
Interface Steps
This interface is similar to the common interface functionality identified in Section 5.3.2 but with some
variations.
The BRDB Memo interface process will be invoked by an RDDS-host process. The BRDB Memo
interface will be passed in the command-line arguments that are mandatory for the interface i.e.
Interface-Name, Business Date and Node-Id.
The BRDB interface will access the RDDS table MEMO_TRANSFER_CONTROL to read the list of
unprocessed Memo-lds i.e. where status is 0 (not-started) or 1 (Started but not completed). Records will
be fetched in chronological order using the creation_date column.
For each Memo-ld fetched, the BRDB interface will update the MEMO_TRANSFER_CONTROL table to
set the status to 1, lock the record and will use the Memo-ld to fetch the memo and its distribution details
from RDDS and populate the corresponding BRDB tables. Once memo details are copied across, the
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 55 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
transfer-control table will be updated to set the status to 2 and record the completion-date. All records for
the ‘Memo-lId’ will either be committed or rolled back (in case of an error) as one unit along with the
transfer control update.
If the Memo was already present in the Branch Database, the interface will raise & return an exception
and will not attempt to process the memo.
The BRDB interface process will also be capable of checking and using the value of system parameter
called “Feed-Name-in-uppercase_BRDB_REFRESH_YN” of “Y” to indicate a complete refresh of all data
in BRDB Desktop Memo tables. Complete refresh involved deleting all records from the target tables in
BRDB and refreshing with data from source tables in RDDS. The system parameter value will be
defaulted to “N" and is only meant to be used by Support in exceptional circumstances and this will be
covered in more detail in the Branch Database Support Guide.
The TWS implementation of this job is in the form of an on-demand schedule that is triggered by the
successful completion of the RDDS TWS job that makes the memos available in the RDDS interfacing
tables. A successful completion of the Memo copy to Branch Database will trigger the memo de-
normalisation job (see Section 5.4.5.1).
The source and target data attribute mapping / derivation is driven off metadata and is defined in the
Branch Database - RDDS Counter Reference Data and Memos Interface Specification [R20].
5.3.4.6 NPS
The BRDB — NPS batch interface will perform one function (BRDB Transactions to NPS) of a interactive
batch transfer feed of Track & Trace (T&T) and Guaranteed Reversal (GREV) messages from the Branch
Database to NPS to allow NPS to forward the T&T messages as SOAP requests to POL EDG and to use
the GREV messages to ensure that the Fls and POA financial reconciliation are aware of the reversal.
5.3.4.6.1 BRDB messages to NPS
The interface will be implemented in the form of an interactive batch feed that will run both within and
outside of core business hours.
This feed is characterised by medium/high data volumes and a more complex implementation due to the
interactive nature of the feed.
It is driven by the Branch Database system operational schedule and is implemented in the form of four
instances of the generic bulk copy interface running for each of the following types of messages:
© Track & Trace
« Guaranteed Reversals
The interface steps involve:
e Checking for a signal to exit processing. The signal is sent by an updating the value of System
Parameter named <Feed-Name>_STOP_YN (see 7.2.11 for details). There will be separate
system parameter flags for GREV and T&T interfaces.
« Fetching all messages that have not been copied across i.e. NPS-Delivered-Timestamp is NULL,
for the above-mentioned record types from BRDB.
e Inserting records into the target tables in NPS.
« Updating the copied records in BRDB to mark them as ‘copied’ by set the value of NPS-
Delivered-Timestamp to SYSTIMESTAMP.
e Checking for a signal to exit processing as before.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 56 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
e ‘Sleep’ for a metadata-defined time period® before waking up and repeating the above-mentioned
steps.
The Track & Trace feed to NPS will connect to the NPSSERVICE1_2 service and the Guaranteed
Reversals feed will connect to NPSSERVICE2_1.
The source and target tables and data attribute mapping / derivation are defined in the Branch Database
— Legacy Host Interface Specification [R17].
5.3.5 Estate and Systems Management Interfaces
The Branch Database will interface with various Estate and Systems Management systems to read
networking information about Branches and Counters within Branches and to transfer the details of HNG-
X Migration Confirmation to Systems Management via EMDB.
Networking information involves reading details such as the Connection type available at the Branch and
the full IP address of each counter in an HNG-X branch. For the period up to a point before the start of
Windows-XP Rollout, the information will be sourced from ACDB via EMDB. After that the information will
be sourced from a new system called BCDB via EMDB. BRDB also provides EMDB with the definitive
view of branch information via a view on the reference data tables and BRDB_BRANCH_INFO.
Additionally for the duration of Hydra, the Branch Database needs to provide ACDB / BCDB via OMDB
with information on Branches that have reached the point of no return in HNG-X migration.
The following diagram depicts the Branch Database interfaces with Estate and Systems Management.
8 Sleep time in seconds will be stored in BRDB-System-Parameters table. This needs to be queried once
only, at the start of the processing.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 57 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
\ /
SYSMAN2 (hydra only)
ED \ /
ompB {I \ /
I Migration Status ] I / .
4 / \
(emzof I OMDB-BRDB ey
EMDB is fw ]_ I Gener intertace ===EH,_Branch Migration I
I Branch fe) 1 \ Status
Connectivity I
Estate Management
ae Domain -
I y EMDB-BRDB I pepe f\
EEN \ Generic Interface Information I
I ( AcDB/BcpB /)\ \ a
I \ Migration Status I I \ BRDB y
el \ \ { Branch
ACDB/BCDB I \ \ \_ Connectivity \/
\ Branch Connectivity I I \ \ OO
\ \
Systems Management I \ .
Domain i \ BRDB-Host Domain
5.3.5.1 EMDB Branch Connectivity to BRDB
The interface will be implemented as an instance of the generic interface for feeds going out of the EMDB
system. The feed to BRDB will be in the form of an infrequent repopulation of the corresponding tables in
EMDB and will be initiated and owned by EMDB.
The Branch Database tables populated by this interface are:
EMDB_POST_OFFICE
EMDB_MANAGED_NODE
The interface steps involve:
e Deleting all Branch Connectivity data in the Branch Database EMDB target tables, as they are
about to be refreshed from the EMDB source tables.
e Repopulate the EMDB tables within Branch Database.
Refer to the EMDB HLD [R25] for more details
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 58 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
A job to populate and update the BRDB_BRANCH_INFO and BRDB_BRANCH_NODE_INFO tables will
run as part of the TWS batch schedule BRDB_FROM_EMDB. The implementation of the
BRDB_EMDB_INTERFACE process is described in section 5.1.4.2.
5.3.5.2 BRDB Outlet Migration Status to ACDB (hydra only)
The interface will be implemented in will run once a day outside of core business hours.
This feed is characterised by very low data volumes and a more complex implementation due to the
interactive nature of the feed and the fact that an Oracle database is accessed by SQL*Server.
It copies HNG-X Branch trading status across to ACDB via OMDB (also see CP4928).
This interface is Hydra only.
The source and target tables and data attribute mapping / derivation are defined in the Branch Database
—ACDB/BCDB Interface Specification [R34].
5.3.6 HNG-X Migration Schedule from CS
The Branch Database will receive a once-a-day view of the day's view of the Migration schedule. The
schedule is owned by the Post Office and is maintained by the Post Office / CS and is stored in RDDS.
Branch Database has access via a database link of the RDDS migration schedule which is stored in
RD_MIGRATING_BRANCHES. This is then used by the BRDBX034 hydra_prep_recon package, after
start of day, to obtain the list of branches migrating within the next 14 days via procedure
Get_Migrating_Branches. See HNG-X RDDS Host High Level Design [R32].
For the processing of migration data please see BRDB Processing of the End of Day Migration Data
[R40] and BRDB Processing of the In Day Migration Data [R42]
5.3.7 Branch Access Layer Interface
Branch Database receives XML-based requests from Post Office branches through the Data Access
Service in the Branch Access Layer.
The application interface specification between the Branch Access Layer’s Data Access Service and the
Branch Database is defined in [R21].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 59 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.4 Aggregation and De-normalisation
5.4.1 Overview
The Branch Database receives transactional, control and reference data all through the day. Some of the
accounting, reporting and operational requirements necessitate the data to be aggregated / de-
normalised as a part of (usually but not always) overnight processing. The aggregations for the Legacy
Host systems are emulating reconciliation totals that were generated by the Horizon Counter. These
aggregations need to be carried out for all transactions for a trading day as soon as possible after the
trading day has ended. Given that a Trading Day can span multiple Journal Dates, these aggregations
will not be confined to a single partition. However a Trading Date cannot start earlier than the Journal
Date which is one day earlier than the Trading Date and this fact can be used to constrain the scanning
of the BRDB tables. Such aggregation must be carried out prior to the data being transferred to the
Legacy Host systems. Aggregation for TPS and APS Hosts are independent of each other.
Given that the Trading Day ends at 19:00 (local time - as defined by the BAL), then these processes can
run soon after that time. Their actual running will be controlled by TWS and the tasks should be
scheduled at around 19:15 each night. The process that copies the day's transactions to the Legacy
Hosts should be dependent upon the corresponding aggregation processes.
The aggregations for Reporting are based on the data in a single partition based on Journal Date which is
based on the clocks at the counter. Since Journal Date is held in UTC time, such aggregation cannot
take place until after 01:00 (which is when the date changes in BST). To allow for any counter drift, the
aggregation process should not start until at least 01:15. Again these processes will be scheduled by
TWS. Once all the aggregation for reporting is complete, the System Parameter LastDailySummaryDate
is updated to the current Business Date to indicate to the reporting processes that the aggregation is
complete.
Given the way that data is partitioned using fad_hash, it is possible to run a number of parallel
aggregation processes. A minimum of 4 such processes should be run (one for each Oracle Instance).
Further details on aggregations can be found in [R39]
5.4.2 Metadata Driven Mechanism
The aggregations / de-normalisations outlined earlier can be best performed by following a metadata
driven approach. This allows for ease of implementation through the use of common code constructs and
provides sufficient flexibility in tweaking the SQL with reduced development impact and delivery
overheads.
The approach relies on the following characteristics of the operations being performed
>» The source and target tables reside in the Branch Database
> In the event of a failure, the operation needs to be backed out. No partial runs are allowed.
Where Fad-Hash partitioned tables are involved, the atomicity is at Fad-Hash level.
> If more than one SQL statements are required to perform the logical operation, the multiple SQL
statements will be defined in metadata and will be run as a single commit unit.
The metadata table that will drive the aggregations / de-normalisations is called
BRDB_HOST_AGGREGATIONS. The following table lists some of the important attributes of the table:
Column Name Data type & I Mandatory Key Description
Size
Aggregation-Name I Varchar2 (50) I Yes Yes Identifies the aggregation / denormalisation
SQL_ statement. This will be passed on
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 60 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Column Name
Data type &
Size
Mandatory
Key
Description
‘command-line as the first input parameter to the
generic aggregation module as described in
7.2.7.
SQL-Id
Number (3)
Yes
Uniquely identifies each aggregation SQL for an
Aggregation / Denormalisation. It is assumed
that scripts with the same aggregation name,
but different SQL ids will have the same value
for use_fad_hash.
Aggregation-SQL /
Aggregation-SQL-
continued
Varchar2
(4000) each
Yes / No
No
Stores the Aggregation / Denormalisation SQL.
If the SQL is larger than 4000 characters, the
Aggregation-SQL-continued column is used to
store the remainder.
All SQLs will make use of the Input
Trading/Business Date and Node/Instance Id
input parameters as described in the generic
aggregation module as described in Section
7.2.7. It is left to the relevant low level designs
to define how the parameters will be substituted
into the Aggregation SQLs.
Use Fad-Hash
Varchar2 (1)
Yes
No
Indicates whether the aggregation to be
performed needs to be Fad-Hash aware. If the
flag value is set, the aggregation module will
use the input Node-Id parameter (see Section
7.2.7) to identify the Fad-Hash values for the
Node and run the Aggregation SQL for each
Fad-Hash value.
Note that if there are more than one SQLs
associated with an aggregation, the value of
this flag for the first SQL applies to all others.
The Aggregation / Denormalisation SQL definition may contain one or more of the following placeholders,
which needs to be substituted by the Aggregation Routine, typically with parameter values passed on the
command-line. Note that these are case sensitive and must be delimited by the # sign:
This is a date in the format YYYYMMDD.
#BUSINESS-DATE#
#INSTANCE-ID#
#FAD-HASH#
#OPTIONAL-PARAM1#
#OPTIONAL-PARAM2#
#OPTIONAL-PARAM3#
It indicates the business day of aggregation and may either be a calendar day
or the trading day.
Numeric value of up to 2 digits indicates the Branch Database Node/Instance
Id to use to run the Aggregation / Denormalisation.
Numeric value of up to 3 digits indicating the Fad-Hash to filter on. Note that if
the Use-Fad-Hash flag in the brdb_host_aggregations table is not set, this
placeholder should not be present in the SQL. If found to be present, an
exception should be raised.
Alphanumeric value of up to 100 characters long.
Alphanumeric value of up to 100 characters long.
Alphanumeric value of up to 100 characters long.
‘©Copyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE, Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 61 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.4.2.1. Process Distribution Across Nodes
The actual implementation of all SQLs that involve Fad-Hash based processing needs to take into
account Fad-Hash — Instance mappings to perform the aggregation on each Branch Database node.
Aggregations can either be done once for each Fad-Hash i.e. in 128 steps or just once to cover all the
Fad-Hashes that ‘belong’ to the node.
It is recommended that where possible, aggregations should be done at Fad-Hash level. However for
some aggregations, it may be sufficient to run four instances of the SQL, one on each node. The Fad-
Hash filter can be applied in the form of an additional where clause, as shown below:
WHERE
AND fad_hash IN ( SELECT fad_hash
FROM brdb_fad_hash_current_instance
WHERE instance _id = :current_instance_id)
Use of parallel query should be made where appropriate.
5.4.2.2. Table Access by Fad-Hash based on Node availability
As with most operations on the Branch Database involving transactions, all partitioned tables in the
Branch Database must be accessed is a fad-hash aware manner i.e. Fad-Hash (sub) partitions of the
table must be accessed using the correct instance. The view
BRDB_FAD_HASH_CURRENT_INSTANCE provides the ‘current’ Fad-Hash to instance mappings for all
available instances.
5.4.2.3. Handling Exceptions
As the operations do not handle data errors differently from system errors, any exception that occurs.
while attempting to run the SQL that performs the action will result in the process performing an Oracle
Rollback and exiting with failure.
5.4.3 Failures and Restartability
The logical processing unit for all tables involving Fad-Hash based data is at a Fad-Hash level. The use
of HADDIS-compliant process-contro! measures will ensure that when the data for a Fad-Hash value has
been transferred successfully, process-control will record the fact and prevent the same partition from
being re-processed in the event of a restart. Use of process-control also ensures that in the event of a
restart after failure, the failed Fad-Hash is reprocessed.
For operations that do not involve Fad-Hash partitioned / sub-partitioned tables, the logical process unit is
the entire operation. In the event of a restart after failure, the action is performed again from the
beginning.
Note that for the restartability to work correctly, the operation must be able to rollback any data changes
that were made before the failure occurred.
5.4.3.1 Handling Node Unavailability
Node/Instance unavailability is handled in the same manner as for Batch Interfaces — See Section
5.3.3.1.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 62 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.4.4 Host Aggregations
5.4.5 Host De-normalisations
5.4.5.1. Desktop Memo De-normalisation
Desktop memos are supplied by the RDDS application and the data is provided in two tables:
RDDS_DESKTOP_MEMO - Provides the definition of the Desktop Memo and the User-Role to whom it
is targeted.
RDDS_DESKTOP_MEMO_DISTR - Provides the distribution list for the memo in the form of Branch
Accounting Codes.
The memos need to be made visible to every user belonging to the User-Role in each Branch from the
memo distribution list. There is a requirement to track whether the memo has been read by the user.
The de-normalisation simply populates a new table with the Memo-ld and the user list. This data is stored
in the table BRDB_DESKTOP_MEMO_USER_DISTR. This action needs to run on the completion of the
job that copies across desktop memo details from RDDS. There may be more than one runs of this job
during the business day.
The algorithm for de-normalising the memo distribution is:
SELECT branch_accounting_code,
fad_hash,
memo_id,
branch_user,
brdb_received_timestamp,
SYS_CONTEXT(USERENV’, 'INSTANCE_NAME')
FROM rdds_desktop_memo rdm,
Tdds_desktop_memo_distr rdmd,
brdb_branch_user_roles bbur
WHERE rdm.memo_id = rdmd.memo_id
AND rdmd.branch_accounting_code = bbur.branch_accounting_code
AND rdm.user_group = bbur.branch_user_role
The de-normaliisation will be available in three forms.
The first is at an individual Memo-ld level, which will de-normalise the memo for all Branches, as defined
by the distribution. To implement this, the SQL will contain an additional “AND memo_id = #OPTIONAL-
PARAM1#". The Optional-Parameter-1 will be passed on command-line to the Aggregation module. This
de-normalisation will be used on an ongoing basis to process a new memo coming from Reference data.
The second is at an individual Branch level and will cover all existing memos in the Branch Database. To
implement this, the SQL will contain an additional argument “AND branch_accounting_code =
#OPTIONAL-PARAM1#”. The Optional-Parameter-1 will be passed on command-line to the Aggregation
module. This de-normalisation will be used for hydra as a part of the ‘In-Day’ migration processing and
also on an ongoing basis as a step in setting up a new Branch in the Branch database.
The third form is at a gross level and will cover all existing memos in the Branch Database. The
difference between its SQL and the SQLs used by the first and second form will be the absence of the
argument that limits on any specific Memo-ld or Branch-Accounting-Code. The SQL will remain as shown
in the template earlier. This will be used once as a part of the preparation of the Branch Database for the
first business day only and thereafter only under exceptional circumstances.
The three forms of de-normalisation will be represented as separate sets of metadata in the host
aggregations table.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 63 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Since the volumes involved are very low (a few thousand), processing should be at process level and not
fad-hash level with the exception of the aggregation labelled DEN_DESKTOP_MEMO_REFRESH, which
will be at Fad-Hash level.
5.5 Migration
As per the Migration Strategy [R22], there will be a significantly large period of time after data centre
migration, during which Horizon Outlets will progressively move across to HNG-X. This time period is
known as ‘Hydra’ or dual running.
In order to facilitate the migration of Horizon Outlets to HNG-X, the Branch Database needs to be kept up
to date with the Horizon transactional and reconciliation data until the Outlet moves across to HNG-X.
This is known as the ‘ongoing’ migration feed.
There is also a need to ‘feed’ the Branch database with critical access (users, roles, privileges) and stock
unit information as a part of the Outlet switchover to HNG-X. This is known as the ‘in-day' migration feed
and is a one-off feed for each Outlet migrating to HNG-X.
This section discusses the migration feeds from a Branch Database perspective.
Before a Horizon Outlet can migrate to HNG-X, the following categories of Branch specific data needs to
be available in the Branch Database:
End of Day Migration Feed
e Transaction log covering all transactions (ideally) for the past 42 days or as a minimum, all
transactions since the beginning the Outlet trading period and the Outlet remuneration period,
whichever starts earlier.
e A reconciliation feed from Horizon counters covering the same duration as the transaction log
(from above).
[R40] describes the processing required within the Branch Database for above.
In-day Migration Feed
e Usernames and roles of all existing Outlet end users
* Stock Unit Definitions
e Current Cash and stock positions
e Suspense Accounts
e Transaction Correction statuses of all TCs targeted at the Branch over a period of 42 days
(lifecycle of the message store)
e Track & Trace “Sack” details
« REM Sack details.
e Cut off data for cut off reports
e Accounting information such as the current Trading Period & Balance Period
e The starting values of various Sequence Numbers such as Journal Sequence and AP
Transaction Sequence
[R41] describes the processing required within the Branch Database for above.
The End of Day and In-day migration feeds will be sourced from TPS-Host. The transfer mechanism is
discussed in Section 5.3.4.1.5 in further detail. For the processing of migration data please see BRDB
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 64 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Processing of the End of Day Migration Data [R40] and BRDB Processing of the In Day Migration Data
[R42].
5.6 Training
The Branch database will store a copy of part of the “live” schema under a different (“training”) schema
owner to support the training requirements. This second copy of the schema will be identical to the first
copy with a few exceptions:
> All tables that have been implemented as a ‘rolling window’ e.g. the message journal, will contain
just a single partition created for a date in the distant future e.g. 31st December 3000. This will
allow the training schema to be operational without any overheads of partition management.
> The training schema will not contain any host or counter reference data objects but will be given
a read-only view (through private synonyms) on the corresponding tables in the live schema. The
same applies for any static metadata objects.
>» All training schema objects will share the same tablespaces as the live schema objects but the
actual table sizes will be much smaller (no more than 1% of the Live size).
The training schema will be accessible to the Branch Access Layer via a separate set of users — See
Appendix C — User, Role Sequence Definitions and Database Links for details.
Table in thetraining schema will not be housekept, data will be deleted as part of training reset.
The following figure depicts the shared and exclusive schema objects for the Training users.
OPSSBRDB OPSSBRDBTR
Schema Owner "I transactional & Event Data ( Schema Owner Transactional & Event Data {
[- Counter Reference Data C Event Data
+ Host Reference Data I — Control Tables
Event Data User Management
a Slatic Metadata — Session Management
Control Tables (
}— Help fe
I User Management
L_ Session Management I
5.6.1. Training Metadata Setup
Training sessions will be setup under a (virtual) Branch-Accounting-Code. This is a numeric value that is
statically assigned to a CTO Branch-Code and Node-ld combination. POL will confirm a static range of
values to be used for these virtual Branch Accounting Codes. Any new Branch Node that is set up in the
table BRDB_BRANCH_NODE_INFO will be assigned a virtual Branch-Accounting-Code if the Branch
can be identified as a CTO branch. The de-normalised Is-CTO-Office flag will be set to “Y’ to indicate that
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 65 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
the Branch is a CTO office. Virtual Branch-Accounting-Code are assigned when processing the Estate
Management feed.:
5.6.2 Training Session Setup
The establishment of a new training session requires the BAL to do an extra lookup of the
BRDB_BRANCH_NODE_INFO table to fetch the Branch-Accounting-Code to be used for that training
session.
As a part of the creation of the training session, the training schema needs to be pre-populated with
transactions, events and accounting information. This will be done by the BAL either using SQL
statements or through a stored procedure.
5.6.3 Training Session Housekeeping
Tables in the training schema will not be housekept. Data will be deleted using a stored procedure when
training session is reset by the trainer. Given low data volume this approach does not have any adverse
affect on sizing.
5.7 Branch Database Supportability
5.7.1 Support Interface
The Branch Database provides the various support teams with a simple SQL based interface with the
access control managed using Oracle roles.
Any routine support queries should be addressed using the Branch Support System. The Branch
Database should be used only in the following cases:
e The Branch Support System (BRSS) is down / inaccessible or the replication between the Branch
Database and Branch Support System is down / or too far behind.
e The nature of query requires use of the Branch Database only e.g. querying the AUD§ table for
access logs.
Even when the Branch Database is used for support queries, any queries that access tables that are
partitioned or sub-partitioned on Fad-Hash will need to use the correct instance for fetching the data.
Failure to do so will increase the traffic across the cluster interconnects and could impact operational
performance of the Branch Database.
There is a need to reduce the impact of any potential inappropriate access/queries by support team
members. Support teams will be restricted to accessing the Branch Database only under an OCP. This
is a change in process and will be defined as a requirement in the Branch Database Support Guide.
5.7.2 Inserting Balancing Transactions
There is a requirement that the SSC will have ability to insert balancing transactions into the persistent
objects of the Branch Database. There are reasons for SSC having to do so e.g. to rectify erroneous
accounting data that may have been logged as a result of a bug in the Counter / BAL.
SSC will have privileges of only inserting balancing / correcting transactions to relevant tables in the
database. SSC will not have any privileges to update or delete records in the database.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 66 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE &
Any writes by the SSC to BRDB must be audited. The mechanism for inserting a correction record must
ensure that the auditing of that action performed must be atomic. There also needs a level of obfuscation
to ensure that the audit mechanism is robust.
The above-mentioned requirements suggest that there is a need for a correction tool to be delivered
which performs the correction, audits it and saves both changes.
A simple low-cost solution for the tool is to provide a Linux shell based utility, which calls a PL/SQL
package to perform the changes. The package will allow inserts to the following transactional tables in
the Branch Database Live schema with the exception of the Message Journal. All inserts will be audited
in the table BRDB_TXN_CORR_TOOL_JOURNAL.
Object Name Object I Ins I Sel I Upd I Del I Oth
Type
BRDB_RX_BUREAU_TRANSACTIONS Table =X
BRDB_RX_EPOSS_TRANSACTIONS Table =X
BRDB_RX_APS_TRANSACTIONS Table X
BRDB_RX_EPOSS_EVENTS Table x
BRDB_RX_NWB_TRANSACTIONS Table X
BRDB_RX_REP_SESSION_DATA Table x
BRDB_RX_DCS_TRANSACTIONS Table x
BRDB_RX_REP_EVENT_DATA Table =X
BRDB_RX_CUT_OFF_SUMMARIES Table =X
The values for some of the columns in the Message Journal will need to be derived in order to insert the
audit record. The following list shows the derived and non-derived values for the Transaction Correction
Tool Message-Journal entry:
No Column Name Value
1 FAD_HASH Fad-Hash value for the Branch as derived from
BRDB_FAD_HASH_OUTLET_MAPPING
2. BRANCH_ACCOUNTING CODE I The Branch-Accounting-Code of the Branch for which the correction transaction is
require
NODE_ID Hard-coded to “99”
JOURNAL_DATE Date & Time of record insertion into the Message Journal. Use Oracle built-in
SYSDATE.
5. JOURNAL_SEQ_ NUMBER This is the next sequence number for Node id ‘99'.
6. SUPPORT_TOOL_USERNAME I SUPPORTTOOLUSER
7. INSERT_TIMESTAMP Timestamp of record creation. Use Oracle built-in SYSTIMESTAMP
8. APP_SERVER_NODE_NAME ‘999°
9. BRDB_INSTANCE_NAME Instance name of the Branch Database Instance.
10. I JOURNAL_XML The format of the data written to this column is:
“<?xml version="1.0" encoding="UTF-8"?><Support_Insert>
<Unix User> Name of the Linux User executing the script </Unix_User>
<Oracle User> Oracle Username that executes the package </Oracle_User>
<Sql>_SQL Statement being executed </Sql></Support_Insert>”
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 67 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
11 I BRANCH_CODE ‘Same value as for BRANCH_ACCOUNTING_ CODE
Section 7.2.11 describes the correction tool in detail.
5.7.3. Support Monitoring
The Branch Database environment needs to be actively monitored by support on three fronts: the RHEL
Operating System, Oracle and application. The monitoring facilities offered for HNG-X application
systems require the use of different tools to monitor the Branch Database environment.
All monitoring requirements for the Branch Database are discussed in the Host Application Monitoring
High Level Design [R31].
5.8 Branch Support System Feed
The Branch Database will replicate transactional, event and other relevant data to the Branch Support
System (BRSS). The BRSS will act as the primary point of access to such data for the various technical
and support streams. The data needs to be replicated on a near real-time basis and in a manner that
results in no data loss under normal operational circumstances.
The mechanism chosen for this replication is Oracle Streams. Streams uses three stages for propagating
data: Capture, Propagate and Apply. Of these, Capture and Propagate will occur on the Branch
Database and Apply on the Branch Support System
5.8.1 Capture Changes in Branch Database
The Oracle Streams capture background process will reside within the Branch Database and capture all
DDL and DML events on objects (except temporary and working tables) owned by the Oracle user
OPS$BRDB. The capture involves running a Streams background process that progressively scans the
online and archived redo logs (as required) to capture changes to data into events known as Log Change
Records (LCR) and enqueue them into a queue. The capture process will make use of a dedicated queue
for streams replication of type SYS.AnyData.
The Capture process will use rules defined using Oracle supplied PL/SQL based utilities to ensure that all
DDL and DML operations on objects residing in the OPS$BRDB schema will be propagated from the
Branch Database to the Branch Support System. Some DDL operations such as ALTER TABLE DROP.
PARTITION and CREATE OR REPLACE PACKAGE must not applied on the Branch Support System.
5.8.2 Propagate Changes to Branch Support System
The Oracle Streams stage and propagate background process will reside within the Branch Database
and will propagate all LCRs events that are present in a named dedicated queue of type SYS.AnyData to
a destination queue of the same type in the BRSS database.
The propagation can propagate or discard events based on any rules that may be defined. Examples of
such rules include propagation of events belonging to selective schema objects, propagation of events
based on whether they relate to DDL or DML operations etc. No rules will be defined at the propagation
stage for the data replication from the Branch Database.
5.9 Branch Standby Database
Please refer to Section 8 for details on the Branch Standby Solution.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 68 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
5.10 Post Hydra changes
This section lists the changes required to the Branch Database as a part of the post hydra phase.
Alongside each change, the document lists whether the change is mandatory or optional and wherever
relevant, the implications of not making the change.
5.10.1 Schema Level Changes
The removal of any object specified in this section must be accompanied by the removal of its public /
private synonyms.
Tables to be removed (all Optional)
BRDB_HYDRA_CT_TOTALS
BRDB_HYDRA_CT_MODE_TOTALS
BRDB_HYDRA_MIGRATION_SCHED
BRDB_HYDRA_EXCEPTIONS
BRDB_HYDRA_TPS_FILTER
BRDB_HYDRA_TPS_FILTER_ERRORS
TPS_HYDRA_INDAY_DATA
TPS_HYDRA_RECON_TOTALS
TMP_HYDRA_INDAY_XML
TMP_HYDRA_INDAY_XML_BARCODES
TMP_HYDRA_INDAY_XML_BDC
TMP_HYDRA_INDAY_XML_CUTOFF
TMP_HYDRA_INDAY_XML_CUTOFF_TOT
TMP_HYDRA_INDAY_XML_EOSPROMPTS
TMP_HYDRA_INDAY_XML_EPOSS
TMP_HYDRA_INDAY_XML_EPOSSCAP
TMP_HYDRA_INDAY_XML_HWM
TMP_HYDRA_INDAY_XML_LFS_IN
TMP_HYDRA_INDAY_XML_LFS_OUT
TMP_HYDRA_INDAY_XML_PINPAD
TMP_HYDRA_INDAY_XML_REPORTS
TMP_HYDRA_INDAY_XML_ROLLOVER
TMP_HYDRA_INDAY_XML_SCAN
TMP_HYDRA_INDAY_XML_STOCK
TMP_HYDRA_INDAY_XML_TC
TMP_HYDRA_INDAY_XML_USER_ROLES
TMP_HYDRA_INDAY_XML_USERS
TMP_HYDRA_RECON_XML.
TMP_HYDRA_RECON_XML_PS_P
TMP_HYDRA_RECON_XML_PS_P_MD
BRDB_MIG_REPORT_DATA
BRDB_MIG_REPORT_DIFF
View to be removed (optional)
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 69 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
OMDBUSER.MV_TRADING_POSITION_DIFF
Sequences to be removed (optional)
BRDB_HYDRA_EXCP_SEQ
TPS_HYDRA_INDAY SEQ
TMP_HYDRA_RECON_SEQ
PL/SQL Objects to be removed (all Optional)
All PL/SQL objects that correspond to the following feeds should be removed:
BRDB_EPOSS_TXN_FROM_TPS Transfer EPOS transactions from TPS to BRDB (Hydra)
BRDB_APS_TXN_FROM_TPS: Transfer AP transactions from TPS to BRDB (Hydra)
BRDB_BDC_TXN_FROM_TPS: Transfer Bureau transactions from TPS to BRDB (Hydra)
BRDB_NWB_TXN_FROM_TPS: Transfer Banking & ETU transactions from TPS to BRDB (Hydra)
BRDB_DCS_TXN_FROM_TPS: Transfer Debit Card transactions from TPS to BRDB (Hydra)
BRDB_RECON_XML_FROM_TPS: Transfer ongoing Reconciliation blob from TPS to BRDB (Hydra)
BRDB_INDAY_XML_FROM_TPS: Transfer In-day Migration blob from TPS to BRDB (Hydra)
The following packages are implicated, along with associated synonyms
Pkg_brdb_hydra_inday
Pkg_brdb_hydra_prep_recon
Pkg_brdb_hydra_recon
Pkg_brdb_inday_xml_from_tps
Pkg_brdb_recon_xml_from_tps
Pkg_brdb_nwb_txn_from_tps
Pkg_brdb_eposs_txn_from_tps.
Pkg_brdb_dces_txn_from_tps
Pkg_brdb_bdce_txn_from_tps.
Pkg_brdb_aps_txn_from_tps.
5.10.2 Metadata Changes
Metadata to be removed (Mandatory)
Metadata referring to all the tables listed in Section 0.1.1 needs to be removed from all of the following
tables:
BRDB_ANALYZED_OBJECTS
BRDB_ARCHIVED_TABLES
BRDB_SUBPARTITION_RANGES
BRDB_PARTITIONED_TABLES
BRDB_PARTITIONED_INDEXES.
BRDB_PARTITION CREATES
BRDB_PARTITION_STATUS_HISTORY
BRDB_TABLE_PARTITIONS
BRDB_TABLE_GROUPS
BRDB_SQL_HINTS
Metadata to be removed (Optional)
Metadata referring to the following interfaces to be removed from BRDB_HOST_INTERFACE_FEEDS
along with corresponding child rows from BRDB_HOST_INTERFACE_FEED_EXCP.
BRDB_EPOSS_TXN_FROM_TPS
BRDB_APS_TXN_FROM_TPS
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 70 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB_BDC_TXN_FROM_TPS
BRDB_NWB_TXN_FROM_TPS
BRDB_DCS_TXN_FROM_TPS
BRDB_RECON_XML_FROM_TPS
BRDB_INDAY_XML_FROM_TPS
Metadata referring to process_name like BRDBX030%, BRDBX033% and BRDBX034 needs to be
removed from BRDB_PROCESSES table. Data from BRDB_PROCESS_CONTROL and
BRDB_PROCESS_AUDIT for the deleted BRDB_PROCESSES rows.
Rows from brdb_system_parameters for the following parameter_name
DEBUG_LEVEL_FOR_BRDBX030
DEBUG_LEVEL_FOR_BRDBX033
DEBUG _LEVEL_FOR_BRDBX034
BRDBX034_I LOOK _ AHEAD
BRDB_HYDRA_PREP_RECON DEBUG LEVEL
BRDB_HYDRA FILTER
BRDB_HYDRA_RECON_DEBUG_LEVEL
BRDB_HYDRA_INDAY_DEBUG_LEVEL
BRDB_HYDRA_INDAY_BATCH_SIZE
BRDB_HYDRA_INDAY_CONTROL_VERSION
BRDB_APS_TXN_FROM_TPS_DEBUG LEVEL
BRDB_APS_TXN_FROM_TPS_BATCH SIZE
BRDB_APS_TXN_FROM_TPS_MAX I DATA ERRORS.
BRDB_BDC_TXN_FROM_TPS_DEBUG LEVEL
BRDB_BDC_TXN_FROM_TPS BATCH SIZE
BRDB_BDC_TXN_FROM_TPS_MAX DATA ERRORS
BRDB_DCS_TXN_FROM_TPS_DEBUG I LEVEL
BRDB_DCS_TXN_FROM_TPS_BATCH SIZE
BRDB_DCS_TXN_FROM_TPS_MAX_DATA_ERRORS
BRDB_EPOSS_TXN_FROM_TPS DEBUG LEVEL
BRDB_EPOSS_TXN_FROM_TPS_BATCH SIZE
BRDB_EPOSS_TXN_FROM_TPS_MAX_DATA ERRORS.
BRDB_INDAY_XML_FROM_TPS DEBUG LEVEL
BRDB_INDAY_XML_FROM_TPS_BATCH_SIZE
BRDB_INDAY_XML_FROM_TPS_MAX_DATA_ERRORS
BRDB_NWB_TXN_I FROM. I TPS_DEBUG_ LEVEL
BRDB_NWB_TXN_FROM_TPS BATCH SIZE
BRDB_NWB_TXN_FROM_TPS_MAX_DATA ERRORS
BRDB_RECON_XML_FROM_TPS_DEBUG LEVEL
BRDB_RECON_XML_FROM_TPS BATCH SIZE
BRDB_RECON_XML_FROM_TPS_MAX_DATA_ERRORS
5.10.3 Process/Module Changes
Modules to be decommissioned (optional):
$BRDB_SH/BRDBX030.sh Hydra specific XML Data Processor
$BRDB_SH/BRDBX033.sh Hydra specific XML Data Processor
$BRDB_SH/BRDBX034.sh Hydra specific XML Data Processor
5.10.4 Scheduling Changes
All scheduling changes are discussed in the Scheduling Specification [R12].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 71 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref DES/APPIHLDIO020
Version: V1.0
Date: 17-Nov-2009
Page No: 72 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
6 Building Branch Database
6.1 Oracle Installation & Configuration
This section briefly describes the software components and installation guidelines for the Branch
database (BRDB) on Linux.
The BRDB-Host platform will contain the following components:
« Oracle Clusterware version 10.2 (suitably stable patchset)
e OCFS2 version 1.2 (suitably stable patchset)
e Oracle Enterprise Edition 10.2 (suitably stable patchset) with partitioning & RAC option
Installation guidelines for the above-mentioned software components are as follows:
Topic Description
RHEL >» The additional RPM packages required for an Oracle 10gR2 RAC cluster should
be installed in addition to the standard Linux build from [R10]. These packages
add development tools such as C/C++ compilers and libraries, glib and zlib
libraries, libaio and openmotif.
The hang-check timer should be enabled as per Oracle's recommendations.
Rsh, rlogin and rexec must be enabled across all four of the BRDB-Host nodes.
Kernel parameters such as minimum & maximum shared memory, semaphores
and maximum file handles should be adequately set to allow a single Oracle
database instance with a fixed size of 4GB and a variable (on-demand)
requirement of another 2 GB plus a fixed size of 1GB for a smaller ASM instance
to operate on each node.
> Ensure that the date/time are synchronized across all nodes.
VV Vv
Network > Ensure that the public IP addresses, VIP (virtual IP addresses) and the loop-back
for the cluster interconnects are uniquely defined for the bladeFrame.
Oracle > The Oracle clusterware VIPs should use the BladeFrame's internal back plane for
Clusterware interconnect communication.
OCFS2 » Ensure that the OCFS2 console and tools packages are loaded along with their
associated libraries.
>» OCFS2 needs to start-up at boot-up time.
> Three partitions need to be created and managed by OCFS2. The first two are
physical partitions meant for use by the OCR & voting disks. The third is an
OCFS2 file-system formatted partition, which will be used for sharing the SPFILE
across the nodes. Ensure that these partitions are mounted on all four nodes.
Details on names and sizes of OCFS2 partitions have been included in the BRDB
sizing & volume spreadsheet ([R11]).
ASM » ASM-lib version 2 or higher will be used as the storage management interface
between Oracle and the disk storage. ASMlib provides a set of libraries, which
allow for efficient access to shared raw devices used by ASM disk groups.
» The disks used to create ASM Disk Groups will be “oracleasm” partitioned. This
allows for greater manageability and is Oracle's recommended approach and will
be used for the Branch Database.
> Ensure that the ASM disks are configured to start on boot-up.
Oracle > The Oracle software needs to be installed in Real Applications Cluster mode to
Enterprise allow the RAC-specific components to be installed.
Edition » The starter database should not be created.
RDBMS
ODBC >_Install the DataDirect ODBC driver version 5.3 on each Branch Database node.
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 73 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Topic Description
Driver
Table 2 - Guidelines for Installing & Configuring Oracle
Detailed discussion of the installation e.g. order of software install and configuration of Oracle software
components is beyond the scope of this document. PI refer to the Linux Host design document [R10] for
the complete list of software components to be installed and the order of install. For installation details,
refer to [R9].
6.2 Storage Management
6.2.1 Use of ASM
Oracle ASM will be used for managing the storage for the following database components:
Control Files
v
» Online Redo-logs
>» Persistent data-file tablespaces
>» Temporary data-file tablespaces
» Archived Redo-Logs (in Flash Recovery area and NAS)
>» Backups (in Backup Recovery Area)
There will be an instance of ASM created for each node of the branch database. Each instance will be
named +ASMn where n is the instance id and ranges from 1 to 4.
6.2.2 Creating the ASM instance
Common Linux platforms (four in total) will be used to host the BRDB database. Oracle RAC ASM
instances (four in total) will be created on the BRDB-Host nodes to support the Branch database
instances. Because BRDB database runs as four Oracle instances with each running on a different node,
the ASM instance would also run on all four nodes.
The name of the instance will be “tASMn" where nis the instance id and ranges from 1 to 4.
BRDB Host — 1...4
Oracle EM Agent
Oracle Net Services
Database instance BRDB1...4
ASM Instance +ASMB1...4
OCFS2
Figure — 12 Oracle components on each BRDB-Host node
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 74 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The initialization parameters file for the ASM instances will be stored within a single SPFILE. This allows
for maximum flexibility in maintaining the cluster. Each node will have a local PFILE (per instance) at the
default location for initialization files (Oracle-Home/dbs) that simply points to the ‘shared’ SPFILE for the
database. The ‘shared’ SPFILE can be shared across nodes using OCFS2.
6.2.3 Disk Groups
A number of very high read/write activity areas have been identified in the Branch database storage. In
order to manage storage efficiently, heavily loaded database components/objects have been divided into
five groups as shown below.
ASM Instance
+ASMn I
¥ ¥ y ¥
BRDB_SYS ane BRDB_DATA _—_ BRDB_INDEX iF
1° copy of Control Ht persistent Allindex — Flash Receover
a ry Area
File 1" copy of REDO logs data tablespaces (Backups, Archived redo)
SYSTEM and UNDO logs Temporary tablespaces 2" copy of Disk Groups
tablespi tablesp: Contror Fite
Figure - 13 ASMn Instance Disk Group Layout
The ASM disk groups to be created for the Branch Database are:
Disk Group Name Usage ona Description
scale of 1to5
(low ~ 5 very high)
BRDB_SYS 3 Used for the control file, system, sysaux and undo
tablespaces
BRDB_REDO1A...1D 5 Used for maintaining the online redo-logs
BRDB_REDO_2A...2D 5 Used for temp tablespaces and for maintaining the local
copies online redo logs.
BRDB_DATA 5 Used for storing the data
BRDB_INDEX 3 Used for storing the indexes and control file.
BRDB_FLASH 3 Used for the flash recovery area and archived redo-logs
BRDB_BRA_Pn/Sn (n- 1 Used for backups (not shown in the table above)
1,2 and 3)
BRDB_STANDBY_REDO I 5 Used for the Branch Standby redo logs (not shown in
above table)
Table 3 — ASM Disk Group Usage Notes
6.3 Database Components
6.3.1 Cluster Configuration Files
An Oracle10g release2 Real Application Cluster requires two cluster configuration files that must be
created and maintained locally. Note that the installation of clusterware software and creation of the
following files is covered in [R9].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 75 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
OCR: The Oracle Cluster Registry stores cluster configuration details of all clustered Oracle
databases on the machine (node). Since the nodes hosting the Branch database will be
used exclusively, the OCR will contain information about the Branch database cluster
only.
The OCR is created when Oracle clusterware is installed but will be populated post
database creation by issuing a number of “srvetl” commands.
The OCR is used by clusterware to start / stop databases, instances, listeners etc when
the clusterware daemon starts up or stops respectively.
Voting Disk: The voting disk is used as means of synchronization and communication between RAC
instances when one or more instances fail / start up.
Both files require a clustered file system or a cluster-aware logical volume manager to maintain them, as
the files need to be accessible to all four nodes. Oracle OCFS will be used for storing these files.
Both of the files are vital to the functioning of the BRDB RAC cluster and need to be backed up. The
backup approach is discussed in Section 12.5.
6.3.2 ASM Disk Groups
Already covered in Section 6.2.3.
6.3.3 Initialization Parameters
The initialization parameters file for both the ASM and the Branch Database instances will be stored as
SPFILEs. This allows for maximum flexibility in maintaining the cluster. Each node will have a local PFILE
(per instance) that simply points to the ‘shared’ SPFILE for the database. The ‘shared’ SPFILE can be
shared across nodes using OCFS.
6.3.4 Character set
The Branch Database will use the WE8ISO8859P15 character set as per Oracle's recommendations on
8-bit character sets for databases that store data, which do not use windows encoding. The NLS
Character set will be AL16UTF16.
[
6.3.5 Control Files
There will be three copies of the control file.
The first copy of the control file will be in the ASM disk group SYSTEM and the second in the ASM disk
group BRDB_INDExX. The third copy of the control file will reside outside of ASM in the OCFS2 managed
space.
6.3.6 Redo Logs
Four online redo log groups will be used per database node (or per thread). Size of the redo logs will be
set to 400M? each.
® The size is chosen to allow the redo-logs to fill up every 1-1.5 minute at peak times. The final size may
vary by 100MB on either side depending on the average size of each customer session message.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 76 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Each online redo-log group will contain two members. The first member of every group will be created on
synchronously replicated disks. The second member will reside on non-replicated fast disks.
All online redo log files with reside within ASM. The first member of each redo-log group will be in the
ASM disk group REDO_1A to REDO_2D and the second in the disk group REDO_2A to REDO_2D..
6.3.7. Flash Recovery Area
Flash recovery area is a location on disk where the database can create and manage a variety of backup
and recovery-related files. As a minimum, BRDB will use the flash recovery area to store all the archived
redo log files before they have been written to tape.
Flash recovery area can be enabled by setting the following parameter values in the spfile:
DB_RECOVERY_FILE_DEST_SIZE (which specifies the disk quota, or maximum space to use for flash
recovery area files for this database) — This should be set to the same size as the archived redo log storage
from the BRDB Sizing [R11].
DB_RECOVERY_FILE_DEST (which specifies the location of the flash recovery area) — This should point to
the ASM disk group named FLASH.
Oracle's Flashback Query feature should not be enabled.
6.3.8 Archived Redo Logs
Two copies of the Archived redo log file should be created.
The first copy will reside inside the Flash Recovery Area and will be specified as mandatory.
The second copy will reside outside ASM on NAS storage and will be optional.
Refer to the BRDB Sizing [R11] for details on archived redo log sizes and locations.
6.3.9 Tablespace Definitions
The following tablespaces are in BRDB Application Representation in Designer10g. The implementation
details are in BRDB Sizing [R11]. For performance considerations, the fact tables containing outlet-
specific data will have their partitions distributed across multiple (128) tablespaces.
All tablespaces including SYSTEM will be ‘locally’ managed. All temporary tablespaces will be created
using Oracle temporary files.
No tablespace should have its data-file set to “auto-extend” as is the standard database design practice.
The auto-extend feature usually hides flaws in the system and usually lead to problems in the medium or
long run that are difficult to overcome.
All tablespaces will reside within ASM. The disk group to be used is highlighted in the BRDB sizing
spreadsheet.
* BRDB_CONTROL_DATA
* BRDB_CONTROL_INDEX
* BRDB_COMMON_DATA
* BRDB_COMMON_INDEX
* BRDB_COUNTER_REF_DATA
* BRDB_COUNTER_REF_INDEX
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 77 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
e BRDB_COUNTER_MISC_DATA
e BRDB_COUNTER_MISC_INDEX
e BRDB_FH_PART_nnn_DATA where nnn ranges from 000 to 127
* BRDB_FH_PART_nnn_INDEX where nnn ranges from 000 to 127
* BRDB_META_DATA
« BRDB_META_INDEX
* BRDB_REF_DATA
* BRDB_REF_INDEX
e BRDB_REPORT_DATA
« BRDB_REPORT_INDEX
« BRDB_TEMPppp where ppp ranges from 1 to 4
¢ — BRDB_UNDOppp where ppp ranges from 1 to 4
* BRDB_SSC_DATA
« BRDB_STREAMS_DATA
«© BRDB_TWS_DATA
e BRDB_WORKING
* BRDB_XDB_DATA
« SYSTEM
« USERS
« TOOLS
6.3.10 CASE Tool Schema Definitions
ERwin is being used a modelling tool for Branch Database. PDF files containing the schema definition
can be found in [R36].
6.3.11 Table, Index and Meta data Definitions
Note that all table definitions detailed in this document are derived from the BRDB Application
Representation in ERwin. ERwin is the primary source of these definitions therefore should be checked
prior to using the definitions listed in this section.
For details of some Branch Database schema objects, please refer to the following appendices:
Appendix C — User, Role Sequence Definitions
6.4 BRDB Database Build
A set of database build scripts will be supplied as a part of the Branch database application delivery.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 78 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
6.4.1 Building the Branch Database and Tablespaces
Asset of build scripts will be delivered to create the branch database and required tablespaces.
The details of database build scripts will be present in related Low Level Design.
6.4.2. Security Measures for access control
On completion of database creation, the following security measures should be undertaken to prevent
unauthorised access to the Branch Database. This is in accordance with the HADDIS standards ([R7])
and the HNG-X Security Architecture ([R23]).
Refer to Section 12.1.1 for some of the security changes required.
6.4.3 Schema Build
The definition of all branch database logical storage objects i.e. tables, indexes etc can be obtained from
the ERwin data modeller repository. All objects have been defined as owned by the user OPS$BRDB.
A number of placeholders have been used in the schema definition in ERwin:
#FH# — The Fad-Hash value. All associated lines need to be replicated 128 times and the number #FH#
replaced with a number ranging from 000 to 127 (along with the leading zeros).
#AMP1# — The input command-line parameter #1. This should be replaced with “&1” which will be later
substituted in the build scripts.
#AMP2# — The input command-line parameter #2. This should be replaced with “&2” which will be later
substituted in the build scripts.
#UTYPE# - Indicates if the user is live or training. Possible values are “LV” or “TR”. For building the Live
schema, use the value of “LV”.
A set of build scripts will be delivered to create these two sets of the Branch Database application
schema.
The details of schema build scripts will be present in related Low Level Design.
6.4.3.1 Training Schema Build
The training schema will co-exist with the BRDB Live schema and all training schema objects will be
owned by the schema owner OPS$BRDBTR.
When building the training schema, the placeholder “#UTYPE#” used in ERwin should be substituted with
the value of “TR”.
Refer to Section 5.6 for differences between the “live” and “training” schemas. Also refer to Section 18.1
for the list of tables that must be “shared” (read-only) by the “live” schema with the training schema.
6.5 Network Configuration
6.5.1 Services
The Branch Database will have the following services presented to the consumer applications (BAL,
Batch Applications, Support, Monitoring etc). Services will be registered in the Cluster Registry using the
“srvctl” utility.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 79 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE
Service Name Instance/s Name Comments
BRDB1 BRDB1 Service will be available on the specific node and will be used
BRDB2 BRDB2 to connect to specific instance. Failure to connect to that
instance should result in an Oracle Error.
BROBS BROBS TAF will not be configured for this service.
BRDB4 BRDB4
BRDB BRDB1, BRDB2, BRDB3, BRDB4 —_I Alll four Branch Database instances are available for this
service.
TAF will not be configured for this service.
6.5.2 Listener
A listener with the name of LISTENER_hostname will be in Port #1529 for TCP/IP
requests. The actual listener names will be LISTENER! [RRELEVANT he listener configuration
will not refer to any Branch Database services. Instead thé Sérvi Wil régister themselves with the
listener as per Oracle's recommendations for version 10gR2 instances. Refer to Section 22.1.2 for further
details on setting any Net services specific initialisation parameters that facilitate this.
6.5.3 Local Naming
Local naming (TNSNAMES) will be configured for each of the services listed in 6.5.1.
In addition the following aliases will be configured in the TNSNAMES configuration file:
Alias Name Instance / Comments
Service Name
BRDB BRDB Load balance feature will be used. TNS addresses for all four Branch Database nodes
will be specified.
BRSS1 BRSS1 Connect to the BRSS Instance
DRS DRS Connect to the DRS Instance
TES TES Connect to the TES Instance
APOP1 APOP1 Connect to the APOP1 Instance.
NPS1 NPSSERVICE1_2 Connect to the NPS1 Instance. No feature of TAF will be used.
NPS2 NPSSERVICE2_1 Connect to the NPS2 Instance. No feature of TAF will be used.
RDDS RDDS Connect to the RDDS Instance
RDMC RDMC Connect to the RDMC Instance
TPS TPS Connect to the TPS Instance
APS APS Connect to the APS Instance
LFS LFS Connect to the LFS Instance
6.6 Replication to the SSC Support (History) Database
This section lists some of the changes required to the Branch Database to enable Streams replication to
BRSS.
6.6.1 Initialization Parameters
The number of initialisation parameters need to be set to enable Streams to Capture and Propagate data
to BRSS. The minimum values for the following parameters should be as follows:
JOB_QUEUE_PROCESSES: 500
STREAMS_POOL_SIZE: 100MB
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 80 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Refer to Appendix E — Suggested Oracle Initialisation Parameters for the full list of suggested Oracle
Initialisation Parameters.
6.6.2 Streams Administrator
The Oracle user STRADMIN will be used to administer Oracle Streams.
6.6.3 Supplementary Logging
To allow the log-mining feature of Oracle Streams to work, minimal supplementary logging must be
enabled at database level. This can be done using the “Alter Database” SQL command.
6.6.4 Streams Capture
A new dedicated streams queue should be set up for the data capture. The streams queue table should
be called BRDB_BRSS_REPL_QUEUE_TABLE and owned by the Streams Administrator.
The capture mechanism should make use of the archived redo-logs for capturing log changes in BRDB.
A tule-set (handle for specifying capture rules) should be created and used to specify that the DML
changes should be captured for all tables owned by the schema owner OPS$BRDB.
It is recommended that a degree of parallelism value of 4 should be used for capturing information
however this parameter should be validated during performance testing.
6.6.5 Streams Propagation
The propagation should be set up to make use of the rule-set defined earlier. Using the same rule-set for
capture and propagation allows for ease of changing rules by amending the single rule-set.
The source queue created earlier should be associated with a destination queue created in BRSS.
As required, source schema to be replicated should be instantiated
Streams propagation should be disabled after creation and should be later enabled only after the
Streams apply environment has been set up and enabled in the Branch Support System.
6.7 Setting up Branch Standby Database
Branch Standby Database is discussed in detail in Section 8.
6.8 Interfacing with non-Oracle Database Systems
The Branch Database needs to interface with non-Oracle based Estate Management system (EMDB).
EMDB is Microsoft SQL Server based In this case EMDB will push data in to an interface table. This is
being done to save on licensing costs for Oracle Heterogeneous Agent.
6.8.1. Listener and Local Names (TNSNAMES)
The existing listener LISTENER_{node_name} will be modified to include the following SID_DESC in the
SID_LIST_LISTENER_{node_name} section for each node
(stD_D!
ID_NAME = em)
(ORACLE_HOME = /oracle/10g)
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 81 of 197
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJITSU
FUJ00235023
FUJ00235023
(PROGRAM
)
Anew local names configuration will be added on each node of the Branch Database:
em
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP) (HOST = <BDB Node-name>) (PORT = 1521))
(CONNECT_DATA =
(SID = em)
)
(HS = OK)
)
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 82 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7 BRDB Host Application
The BRDB host processes will written using PL/SQL and Pro*C. The PL/SQL compiler is built into the
Oracle10g enterprise edition database. Pro*C pre-compiler and its libraries will be installed as a part of
Oracle 10g (Release 2) database server installation.
As a part of platform build, all BRDB Linux users, their profiles, environment variables and the required
directories will be created on the rig.
[The details of the Linux Users, Profiles and Environment Variables will be available in the delivery
handover note.]
7.1 Application Development
7.1.1 Code reuse
In order to reduce the development costs and to maximise the benefits of pre-tested algorithms and code,
it is recommended that code from existing host systems should be reused wherever possible. This is
regardless of whether Pro*C or PL/SQL is used as the programming language.
The prime candidates for code re-use are:
» Process Control and Exception Handling common code
> Start-of-Day and Partition Management
> Audit, archiving and table housekeeping
> Optimizer Statistics
> File Housekeeping
» End-of-Day
7.1.2 Process Logging
All host processes will log significant steps on the standard output. Examples of significant steps are
process started/finished, partition creation SQL executed etc. All messages displayed must be prefixed
by a timestamp.
7.1.3 Debug facility
In any production environment a number of factors can affect the performance/execution of long running
processes. It is usually difficult to determine the cause of failure without taking a data snapshot to a
Development environment and re-creating the error scenario. It is particularly difficult to recreate
performance-related issues, as these are usually rig-specific.
With the view of easing the faultfinding process, all modules will include a number of conditional
statements that allow relevant debugging information to be displayed on standard output:
The output of debug information can be controlled by relevant System Parameters. The system
parameter name should be “DEBUG_LEVEL_FOR_xxx” where xxx is the module name e.g.
“BRDBC350".
The following debug flag values should be used. Note that these are common guidelines and should not
stop individual modules from displaying prominent information where necessary:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 83 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
0 — No additional debug information displayed. The process-logging requirement described earlier could
be merged with debugging and displayed for level — 0.
1 — First level of debugging. Message displayed for each milestone e.g. the action of fetching records
from a table, opening / closing files etc. Messages must be prefixed by a procedure/function name
identifier.
2 — Second level of debugging. Display all messages for previous levels plus messages for entry and
exits from control structures. Messages must be prefixed by a procedure/function name identifier.
3 - Third level of debugging. Display all messages for previous levels plus prominent data items
processed. . Messages must be prefixed by a procedure/function name identifier.
7.1.4 Process Control & Audit
7.1.4.1. Process Control Mechanism
Most BRDB host processes will be run as one or more stand-alone instances on the Host and will be part
of a process schedule controlled via TWS. All such processes will have a built-in restart facility.
Instances that run once during a BRDB processing day will make use of the process control table as
required by HADDIS [R7], to aid restarts. An entry will be made at the start of the process and the same
will be updated to indicate completion before the process exits.
If an entry were already present for that instance for the BRDB processing day, this will indicate a restart
and the instance would take actions accordingly.
If a process instance handles partitioned objects with each process being able to process multiple
partitions, a facility will be provided for the process to log the start and end points of each partition. In
case of a failure, this provides a facility to restart the process while skipping all partitions that had been
successfully processed prior to the failure and starting from the partition being processed when the failure
occurred. This provides the means to save on processing time for restarts after failures by going straight
to the partition level and also provides a mechanism of breaking down the process into logical steps if so
required.
Information about instances running more than once during a processing day will be obtained from the
Process information table and will be used to increment the run number in process control for recording
multiple executions. Checks will be made for previously failed runs for the instance and if found the same
run number would be used by the instance for a restart if required.
7.1.4.2 Process Control Table
As described above, this table will store control information about all processes that are invoked as
stand-alone instances. It will be non-partitioned with a primary key index. Entries will be stored in this
table for the maximum duration of transactional data retention i.e. 60 days. For table definition refer to
section Appendix A — Table and Index Definitions.
7.1.4.3 Process Control Routines
A set of common routines will be provided for the use of all BRDB application modules for performing
operations on the Process Control table. These will be written in Pro*C for use of Pro*C modules and in
PL/SQL for the use of database stored objects written in that language.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 84 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.1.4.4 Process Audit Mechanism
All BRDB processes will log an entry in the Process Audit Table as required by HADDIS [R7] at the start
and end of the process instance to provide process audit information.
7.1.4.5 Process Audit Table
As described above, this table will store audit information about all processes that are invoked as stand-
alone instances. It will be non-partitioned with a unique system generated primary key. Entries will be
stored in this table for the maximum duration of transactional data retention i.e. 60 days. For table
definition refer to Appendix A — Table and Index Definitions.
7.1.4.6 Process Audit Routines
A set of common routines will be provided for the use of all BRDB application modules for storing audit
information in the Process Audit table. These will be written in Pro*C for use of Pro*C modules and in
PL/SQL for the use of database stored objects written in that language.
7.1.5 Exception Handling
Exceptions will be grouped into two types, Data Exceptions and Operational Exceptions. Both types will
be implemented using similar methods. Both types will be reported and hence resolved by different
means.
All exceptions detected or generated will be logged by making a concurrent connection to the BRDB
Oracle database in order to avoid affecting the processing. This will use the Oracle concurrent commit so
as not to affect any transaction processing. An option will be provided to display the error details on
standard or error output.
Data Exceptions will be reported using reports and remain on the reports until resolved by support at
which point support will manually clear the exceptions.
Operational Exceptions will be reported using IBM Netcool®/OMNIbus™ software [local table, separate
server, remote client] to the Operations desk and will remain visible until resolved by Operations.
7.1.5.1 Data Exceptions
7.1.5.1.1 Input Data Exceptions
Input data exceptions are exceptions that occur when the Branch Access Layer receives a request from
the Counter that is either malformed (not well-formed XML structure) or fails validation e.g. missing
mandatory attributes. These will be logged by the Branch Access Layer in the Input Exceptions Store.
If the BAL marks a request as ‘Bad’ or the primary key values cannot be derived, the request cannot be
processed any further and will also be logged into Input Exceptions store.
These exceptions will be made accessible to support using an interface into the IBM
Netcool®/OMNlbus™ software.
7.1.5.1.2 Host Interface Data Transfer Exceptions
Exceptions that occur while transferring messages to and from the existing host applications will be
logged in Host Interface Feed Exceptions store (brdb_host_interface_feed_excp). These will include
errors like Null value for mandatory columns or size larger than maximum allowed etc. The messages will
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 85 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
be logged in a single table in the Branch Database regardless of the direction of data flow across the
interface.
These exceptions will be made accessible to support using an interface into the IBM
Netcool®/OMNibus™ software.
7.1.5.2 Operational Exceptions
Operational exceptions can occur during BRDB host processing due to a range of reasons, many of
which may be outside control of the process or the BRDB system. When exceptions occur the relevant
information needs to be recorded for fault analysis or correction. HADDIS [R7] requires that all
operational exceptions be loaded into a table to be viewed and updated by support to indicate they have
read and acted upon the exception. In this case the BRDB_OPERATIONAL_EXCEPTIONS table.
Operational Exception handling for BRDB will be modelled on existing host applications exception
handling. Operational Exceptions can be divided into two categories:
>» Anticipated operational exceptions raised by the application
» Unexpected operational exceptions raised by the application.
Operational Exceptions will be defined in a local reference data table using an eight-character identifier
as defined by HADDIS [R7]. This table also contains the probable causes, action to be taken and
exception severity.
7.1.5.2.1 Application Anticipated Operational Exceptions
The mechanism will be written both in Pro*C and PL/SQL and callable from both languages. Any other
programming language subsequently used in BRDB development for modules that cannot raise
Operational Exceptions itself will have the mechanism implemented for it. Currently, only Pro*C and
PL/SQL are to be used.
Information relevant to the type of Operational Exception such as Oracle or Linux generated will be
passed. All such exceptions will be stored in a common Operational Exceptions table. An option will be
provided to display the error details on standard or error output.
7.1.5.2.2_ Unexpected Operational Exceptions
PL/SQL provides in-built exception trapping mechanisms. These will be used to handle Operations
Exceptions from models written in these languages.
For Pro*C, Operational Exceptions will be handled by a high-level exception handler. This handler will be
modelled on the existing Host systems approach of ‘Try’, ‘Catch’ and ‘Finally’ macros, similar to that used
in the C++ and Java programming languages.
The utility will be written in Pro*C and will provide ‘Try’, ‘Catch’ and ‘Finally’ macros for trapping calls
made to a ‘Throw’ function. The information passed to the utility, that is the accessible diagnostic
information, will be stored in a common Operational Exceptions table and will be identified by a system-
generated sequence.
7.1.5.2.3 Report / Alert
As with the other Host Systems at HNG-X, access will be provided to support via Netcool@/OMNIbus™ to
view and respond to all Operational Exceptions as per HADDIS [R7].
One or more Netcool®/OMNIbus™ alerts will provide a conspicuous visual alarm when exceptions are
raised. The same alarm will also indicate the number of outstanding exceptions.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 86 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
A report written in Netcool®/OMNIbus™ scripting language will display a list of all exceptions that are
outstanding or unresolved, along with their probable causes, actions required and priority. The report will
be generated by support on ‘as-required’ basis.
All exceptions will need to be ‘resolved’. A call will be raised and investigated by support in co-ordination
with the support teams. A screen-based Netcool®/OMNibus™ utility will be provided to mark exceptions
as ‘resolved’.
7.2 Host Processes
BRDB is mainly used by the Branch Access layer to store and process transactional, reporting, event and
other forms of data as described earlier.
However, it also performs a number of activities that require host-based processes. Examples of such
activities are being able to provide transactional and other feeds to various existing host systems and
receive data from them, presenting an audit feed of the day's auditable messages received from the
Counter to the Audit-System and aggregating the current day's reporting transactions.
7.2.1 Start of Day (Application BRDBC001)
The Start of Day process performs the startup activities for the Branch Database. The activities include
incrementing the BRDB Host System Date, partition creation / deletion for all tables implemented as a
date-based rolling window and any other startup tasks required by the Branch Database.
7.2.1.1 Application Type
This is a PRO*C application that uses PL/SQL library functions developed as per HADDIS [R7] (along the
lines of functions used by TES-Host).
7.2.1.2 Inputs
No mandatory input parameters used.
The optional input parameters are:
Table-Group: Name of the table group to create partitions for
Table-Name: Name of the table within the Table-Group to create partitions for
Partition-Date (CCYYMMDD): The Partition-Date to create partitions for.
System-Date (CCYYMMDD): The System Date value to set in System Parameters.
7.2.1.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.1.4 Location
The module should reside in $BRDB_PROC directory on each Node.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 87 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.1.5 Scheduling
A single instance of the application runs every day on the Branch Database (Node-1) at a fixed time
(typically after midnight) as defined in the Scheduling High Level Design [R12].
7.2.1.6 Business Day
Business Day is read from “BRDB System Date” from table BRDB_SYSTEM_PARAMETERS and is
incremented.
7.2.1.7 Partitioned Tables
The partitioned tables whose partitions are created / dropped by the Start of Day process are defined in
the partition management metadata tables in Appendix D — Metadata and Static Reference Data
Definition.
7.2.1.8 Processing
The process will create new partitions in the Audit Store, Settlement and some reporting tables 1 day’? in
advance. For example, if the process is run on day N (Oracle SYSDATE), it will create the partition for
day N+1. This reduces the Branch Access Layer's dependency on the partition creation. Database
access and usage will not be affected for at least a day if the partition creation for the day failed for any
reason. Hence, the support will have enough time to resolve the problem before it becomes critical.
Partition maintenance will be achieved through a generic set of partition management functions driven by
partition management metadata as defined in HADDIS [R7].
The process will truncate and drop the partitions older than N (typically 3) calendar days for the tables
listed in Appendix D - Metadata and Static Reference Data Definition. For example, if the process is
run on day N (Oracle SYSDATE), it will truncate and drop the partitions older than 00:00:00 hours of the
N-3° day. Before deletion a check will be made to see if the partition to be dropped satisfies the criteria
laid out in database column brdb_partitioned_tables.delete_check_criteria, if specified.
If there is more than one eligible partition to be dropped, all will be dropped starting with the oldest. All
create and drop operations will use the Metadata and common functions as defined in the HADDIS [R7].
While dropping partitions for more than a day, checks must be made to ensure that the number of
remaining of partitions does not go below the (metadata driven) threshold, which is 3 calendar days for
Audit Store, Settlement and Recovery tables and 60 calendar days for Reporting. This check is to prevent
the housekeeping process inadvertently dropping valid partitions if the reference date (the retention
period is applied to) is wrongly set to a future date.
Finally the values of the following system parameters (stored in the BRDB_SYSTEM_PARAMETERS
table) will be updated:
BRDB HOST SYSTEM DATE - Date incremented by one day.
T&T Copy Complete flag — Value reset to ‘N’
GREV Copy Complete flag — Value reset to ‘N’
1° This, in effect, becomes 2 days as all create and drop operations will use midnight as the
day boundary.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 88 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.1.9 Handling Failures and Rerun ability
In the event of an Instance failure, the failed job needs to be executed against another node of the
Branch database. Details are available in Scheduling High Level Design [R12]. Other types of failures
need to be handled as per the HADDIS guidelines.
It is recommended that the Process Control functionality be used to control the Process for each Table-
Group and table affected. Note that if the optional command-line parameters are passed in, Process-
Control mechanism should not be used.
Since this process is expected to run a number of SQL DDL statements, care should be taken to ensure
that the BRDB System Date is never re-incremented in case of a restart after failure. PI refer to the TES-
Host Start of Day process for the additional functionality implemented to protect against such issues.
7.2.2. Message Journal Auditing (BRDBC002)
The message journal auditing process will generate the text files for a given day's auditable messages by
reading records from the Message Journal table (BRDB_RX_MESSAGE_JOURNAL).
The data in the Message Journal will be divided among several audit files to:
¢ reduce the size of each audit file
¢ allow efficient use of the audit files later on
7.2.2.1 Application Type
This is a PRO*C application
7.2.2.2 Inputs
Two mandatory input parameters are passed on command-line:
> Business-Day is passed on command-line in CCYYMMDD format.
>» The Branch Database Node Number (1...4)
A further optional parameter Fad-Hash can be passed on command-line. This is present to allow for
regeneration of a subset of audit files if there is any reason for doing so e.g. output files got corrupted,
file-system got full etc.
Note. The value of the BRDB_SYSTEM_PARAMETER for BRDB_BRDBC002_MAX_FILE_SIZE must be
set to a value in the range 200 bytes to 4 Gigabytes. Setting a value below 200 will write a single audit
record to each file and therefore will exceed the 999 files limit (detailed below).
7.2.2.3, Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.2.4 Location
The module should reside in $BRDB_PROC directory on each Node.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 89 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.2.5 Scheduling
The application runs every day in the form of four instances after 1 am local time.. Each instance will run
on a separate node of the Branch Database.
7.2.2.6 Audit Source Tables
There is a_ single source table for all Auditable messages. The table name_ is
BRDB_RX_MESSAGE_JOURNAL and all messages in it are meant to be audited.
7.2.2.7 Audit file record format
The data to be audited is present in the Oracle column
BRDB_RX_MESSAGE_JOURNAL.JOURNAL_HEADER and
BRDB_RX_MESSAGE_JOURNAL.JOURNAL_XML. The journal header column is of type varchar2 and
the journal XML column is of type BLOB and optionally holds ‘gzip’ compressed data. The header column
stores the ‘http' header of the message sent by the Counter to the Branch Access Later and journal XML
stores the payload.
Data needs to be sorted on Journal-Date, Fad-Hash, Branch-Accounting-Code, Node-ld and Journal-
Sequence-Number when fetching from the table.
The file does not have any header or trailer records. There is no need for writing any begin or end tags
around the file records. One record is written per message and comprises of ‘http’ header and payload
separated by new line. The following additional headers are added to simplify the processing by Audit
system.
* — http-Header-Length: <nnn>
* Content-Length-Inflated: <nnn>
The payload will be inflated (uncompressed), where required, before it is written to the file. The entire file
is then compressed using ‘gzip’.
Sample uncompressed audit file is attached below.
2
AUDIT 20081218 039 001.aud
7.2.2.8 Audit-Store file generation
One or more files will be created for each Fad-Hash value resulting in minimum of 128 files. If there are
no transactions for the Outlets belonging to a Fad-Hash, empty files will still be created. There is a further
constraint that each audit file needs to be approximately 100MB) uncompressed. The limit size is held in
the BRDB_SYSTEM_PARAMETERS value for BRDB_BRDBC002_MAX_FILE_SIZE. When the data
being written to a file exceeds the limit, the file should be closed after completion of the record being
written and a new file should be created with the file sequence number incremented by 1. Note that the
file sequence number should always start with 1 for the first file for a Fad-Hash value. The program will
return an error if more than 999 files are created for a single fad-hash.
As the data needs to be fetched in a sorted order, the most suitable index (if more than one) must be
used for this purpose.
All the files for a Fad-Hash value (and there may be more than one file depending on size) will be made
available to the Audit copy process once all the transactions for the Fad-Hash value have been
successfully written to the audit files. The files need to be created in an interim location until then.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 90 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The audit store records need to be fetched from the correct Oracle instance (and Node) for a Fad-Hash
value. Refer to Section 5.1 for details on the reasons and the mechanism for doing so. Fad-hashes will
be fetched for the correct instance by using the view BRDB_FAD_HASH_CURRENT_INSTANCE.
As records are being written to the audit files, the process must optionally be able to monitor if the set of
Journal-Sequence-Numbers for a node in a Branch is dense. The check should only be performed when
the value of mandatory System-Parameter ‘JOURNAL_SEQ_DENSE_SET_CHECK_ENABLED' is
“TRUE”. When a missing journal entry is encountered, a message should be written on standard output
along the lines of “...records between sequence numbers M and N are missing...”. Once the list of
auditable messages for a node is completed, an Operational exception should be raised to indicate the
count of missing sequence numbers.
7.2.2.9 Directories and Files
The final location of the Audit files created by this module is pointed to by the environment variable
$BRDB_COUNTER_AUDIT_OUTPUT.
The actual directory locations will be covered in the Host delivery release notes.
The file names will be of the following format:
“AUDIT_” + Business Date in CCYYMMDD format + “_" + Three digit Fad-Hash ‘0’ padded from left + “_”
+ Three digit File-Sequence-Number ‘0' padded from left + “.aud.gz”
7.2.2.10 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun for the pending Fad-Hash
values. If the failure reason is a Branch Database node/instance failure, recovery jobs will be run on the
other nodes of the Branch Database for pending Fad-Hashes that belong to the failed node. Details are
available in the Scheduling High Level Design [R12].
It is recommended that the Process Control functionality be used to control the Process at Fad-Hash
level.
7.2.3 Heritage Host Systems Interface (BRDBX003)
The Legacy Host Interface application provides the process control and business logic required to
implement any of the legacy host interfaces defined in 5.3.4 where the Branch Database owns the
interface application logic.
7.2.3.1 Application Type
The Interfaces will be implemented as PL/SQL stored packages/procedures/functions. The interface
functionality may be handled by common PL/SQL objects as appropriate. There will be a single point for
calling all host interfaces, which will be implemented in the form of an interface wrapper script developed
as a Linux Shell script.
7.2.3.2 Inputs
The interface wrapper will accept the following mandatory command-line input parameters:
» Batch Interface Name: This is the logical name of the Batch interface and is expected to
correspond to a stored PL/SQL object that will be the access point to implement the interface.
>» Input Trading/Business Date: This date is used to filter the records being passed across the
batch interface. Format is CCYYMMDD.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 91 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
» Node/instance Id: This indicates the Branch Database Node that the batch interface job
instance needs to execute against. Values range from 1...4.
In addition the interface wrapper will accept optional parameters that may be needed for specific
interfaces.
All input parameters will be passed to the PL/SQL object that implements the interface.
7.2.3.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.3.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
The interface will reside within the Branch Database.
7.2.3.5 Scheduling
Multiple instances of the interface wrapper script run at different times during the day. With a few
exceptions, each instance will run on a separate node of the Branch Database.
Refer to the Scheduling High Level Design [R12] for more details.
7.2.3.6 Processing Details
The design principles behind the host interface and its logical implementation are discussed in Section
5.3.
The wrapper script validates the command-line input parameters and calls the relevant host systems
interface PL/SQL object to pass on the parameters. The script traps / handles Node / Instance failures
and returns appropriate return status back to the scheduler.
The interface PL/SQL object formulates the SQL statement required to implement each step of the host
interface. The application logic required to implement various host interfaces is discussed in Section
5.3.4.
7.2.3.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun from the point of failure. If the
failure reason is a Branch Database node/instance failure, a number of recovery jobs will be fired on the
other nodes/instances of the Branch Database. Details are available in the Scheduling High Level Design
[R12].
The use of Process Control functionality is covered in the description of the Legacy Host Interfaces (see
Section 5.3).
The level of Control / point of restart for an interface will depend on whether it has been implemented as
a single instance or four instances.
Typically for interfaces that are implemented as a single instance, the restart point is entire interface run
for the day. This covers all smaller interfaces where the amount of time lost in the event of a rerun is
insignificant.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 92 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
For interfaces implemented as four instances (one per database node), the restart point is at a Fad-Hash
level. This covers all interfaces where finer control may be needed due to the large volumes of data being
transferred.
There may be exceptions to this rule and these would be highlighted in Section 5.3.4.
7.2.4 Audit, Archive & Purge (Application BRDBC004)
The audit, archiving and purge process will run outside core business hours, typically after midnight. The
objects covered by the audit function of this process are as per the HADDIS [R7] guidelines.
Note that the audit function of this process differs from the audit file generation functionality required for
the counter generated auditable messages.
The process will:
e Generate an audit file from the data in the database access audit table (SYS.AUD$) where
Record Insert Timestamp is between 00:00:00 and 23:59:59 for the previous calendar day.
e Audit the Process-audit information.
e Archive and delete Process Control and Audit information and any other tables as per the criteria
defined by metadata.
e Purge data from non-partitioned tables as per rules defined in metadata.
e Mark data partitions as “ARCH” or “NARCH” depending on whether they have been archived or
not, once the partitions have aged as per the retention policy in metadata. These will then be
partition managed by BRDBC001.
7.2.4.1 Application Type
This is a PRO*C application
7.2.4.2 Inputs
» No parameters are accepted.
7.2.4.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.4.4 Location
The module should reside in $BRDB_PROC directory on each Node.
7.2.4.5 Scheduling
Assingle instance of the application runs every day on the Branch Database (Node-1) after the completion
of the overnight bulk-copy jobs to existing host systems.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 93 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.4.6 Audited / Archived Tables
The audit, archive and purge candidate tables are defined in BRDB_ARCHIVED_TABLES table in
Appendix D — Metadata and Static Reference Data Definition.
7.2.4.7 Audit Record Formats
The audit data files will be text files containing the table name, date and time of archive, field delimiter
used, table structure including the column names and type/length, and the variable length records. The
file record formats will be as per the HADDIS [R7] guidelines.
The structure of each file will be as follows:
<map>
<table>BRDB_PROCESS_CONTROL
<date>12082003_011931
<trim>
<separator>I
<colTRANSMISSION_DAY_NUMBERININUMBER(3)
<col>TRANSMISSION_FILE_NUMBERININUMBER(3)
<col>SUB_FILE_SEQUENCE_NUMBERININUMBER(5)
<col>DATA_CENTREINICHAR(1)
<col>ORG_UNIT_IDININUMBER(10)
<col>TOTAL_BDC_TRANSACTIONSIINUMBER(6)
<end>
186I68I1IWI13403I17INININI05072003_23394 1I19]505038I05072003_000000}5{4I0}4{o]IIII1611010
186I68I2IWI17924I17INININI05072003_23394 1 I1I7261I05072003_000000j0(0{0} 1/0}III1011010
486I67I1 [W[6864]9INININIO5072003_233930}1I5004 7005072003 _000000}0)0}0) 1I0}}II{II0II010
‘strailer>
Audit files will be copied to a separate directory on the BRDB Host and then collected by the Audit Server
on a daily basis. The details of the audit directory/file names etc. will be included in the low-level design
of the module.
The audit, archive and deletion criteria are set in BRDB_ARCHIVED_TABLES table in Appendix D —
Metadata and Static Reference Data Definition.
7.2.4.8 Archive File Format
The archive output files will be Oracle database dump files created on a per-table group basis.
7.2.4.9 Directories and Files
The location of the Audit and Archive files created by this module are pointed to by the environment
variables $BRDB_HOST_AUDIT_OUTPUT and $BRDB_ARCHIVE_OUTPUT.
The actual directory locations will be covered in the Host delivery release notes.
The filenames will contain the Group Prefix, Table Prefix and timestamp of creation as per HADDIS [R7].
The file extension for Audit files will be
The file locations and names are as per the table below:
File Type File Location File Name format File
Extension
Audit As pointed to by environment 3-character Group Prefix + 3- “aud”
variable character Table Prefix + Business
$BRDB_HOST_AUDIT_OUTPUT I Date (in CCYYMMDD format)
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 94 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
variable
$BRDB_ARCHIVE_OUTPUT
File Type File Location File Name format File
Extension
Archive As pointed to by environment 3-character Group Prefix + 3- “dmp.Z”
character Table Prefix + Business
Date (in CCYYMMDD format)
Table 4 — Guidelines for Installing & Configuring Oracle
7.2.4.10 Handling Failures and Rerun ability
In the event of an Instance failure, the failed job needs to be executed against another node of the
Branch database. Details are available in the Scheduling High Level Design [R12]. Other types of failures
need to be handled as per the HADDIS guidelines [R7].
It is recommended that the Process Control functionality be used to sub-divide and control the Process
for each type of action e.g. Audit, Archive and Purge.
7.2.5 Gathering Optimiser Statistics (BRDBX005)
On a daily basis, a process that gathers Optimiser statistics using Oracle utilities is run. It can either
gather schema, table or system statistics. If called for table statistics it gets the details of the tables or
table partitions to gather statistics on and any additional parameters to use from the table
BRDB_ANALYZED_OBJECTS. The TWS scheduled job call to BRDBX005 will gather SCHEMA
statistics.. The job call utilises parameter flags and there ParameterN below refers to the flag value, eg:
$BRDB_SH/BRDBX005.sh —i 1 -s SCHEMA
Additionally the Optimiser will also gather system level statistics and be able to update the data dictionary
with the statistics gathered.
7.2.5.1
This is a Linux shell script based application that invokes PL/SQL package based functions.
Application Type
7.2.5.2
Three input parameters are passed on command-line:
Inputs
» Parameter1 — (Mandatory) The job Instance Name. This is a logical value used to allow multiple
runs of the same Object Group during a processing day.
>» Parameter2 — (Mandatory) Type of Statistics: Possible values are “SCHEMA” or “TABLE” or
“SYSTEM".
> Parameter3 — (Mandatory for -s TABLE or -s SYSTEM) varies based on whether Table or
System statistics are gathered.
o For Table statistics, Parameter —- 3 consists of one or more Object-Groups that
correspond to the database column BRDB_ANALYZED_OBJECTS.OBJECT_GROUP.
Several object groups can be supplied in a comma separated list.
o For System statistics, Parameter — 3 is either “GATHER” or “IMPORT”.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 95 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.5.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.5.4 Location
The Optimizer script should reside in $BRDB_SH directory on each Node.
The PL/SQL packages will reside within the Branch Database.
7.2.5.5 Scheduling
The application runs every day in the form of one or more jobs. Each instance can run on a separate
node of the Branch Database. However they are usually scheduled as a single job to run on Node2.
Details are available in the Scheduling High Level Design [R12].
7.2.5.6 Target Tables
lf invoked for TABLE statistics the complete list of objects to be analyzed i.e. entries in
BRDB_ANALYZED_OBJECTS can be found in Appendix D — Metadata and Static Reference Data
Definition. This is currently not invoked in the TWS schedule BRDB_ORA_STATS.
7.2.5.7 Processing Details
The Oracle statistics gatherer uses the Oracle built-in DBMS_STATS package to gather statistics on
Objects such as tables and indexes. Up to date statistics on large tables/indexes allow Oracle's Cost
Based Optimizer to accurately determine the optimal execution path for DML statements involving those
objects.
The Statistics gatherer should be able to gather system level statistics using the DBMS_STATS package.
If the input parameter - 3 value is “GATHER”, the statistics should be gathered and stored in the
BRDB_OBJECT_STATS_ARC table using a suitable alias. For parameter value of “IMPORT”, the
gathered statistics should be imported into the data dictionary. Input parameter 3 is not used when input
parameter 2 is ‘SCHEMA’.
The System level statistics will not be gathered on a daily basis. Instead jobs will be manually submitted
as and when appropriate by support. Refer to the BRDB Support Guide for details
7.2.5.8 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun for all pending/partially
processed object groups. If the failure reason is a Branch Database node/instance failure, the job will be
rerun on another node/instance. Details are available in the Scheduling High Level Design [R12].
It is recommended that the Process Control functionality be used to control the Process at Instance-
Name and Object-Group level.
7.2.6 File Housekeeping (BRDBX006)
The file housekeeping process deletes ‘old’ file-system files using standard Linux utilities. The file
template of files to be deleted is defined in the metadata table BRDB_FILES_TO_HOUSEKEEP.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 96 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.6.1 Application Type
This is a Linux shell script based application.
7.2.6.2 Inputs
None
7.2.6.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.6.4 Location
The script should reside in $BRDB_SH directory on each Node.
7.2.6.5 Scheduling
The application runs every day in the form of a single instance after the completion of the jobs
BRDBC002 — BRDBC005. The instance will run on the first node of the Branch Database. Refer to the
Scheduling High Level Design [R12] for more details.
7.2.6.6 Target Directories
The directories containing these files are detailed in the Scheduling High Level Design [R12].
The main target directories for file housekeeping are:
e —/app/brdb/trans/audit
« _ /app/brdb/trans/support/archive
7.2.6.7 Processing Details
The file housekeeping process selects all rows from the BRDB_FILES TO _HOUSEKEEP table,
evaluates the age of the files referenced and deletes all files older than the stored retention period value.
Files to housekeep include:
. Audit Files
e Support Archive Files
Where hard links have been created to Audit directories, the Audit System will be responsible
housekeeping the resulting files.
In order to minimise development effort, it is highly recommended to use existing functionality used by
APOP-Host system. However re-using functionality is not a requirement.
7.2.6.8 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun for all pending files. If the failure
reason is a Branch Database node/instance failure, the job will be rerun on another node/instance.
Details are available in the Scheduling High Level Design [R12].
It is recommended that the Process Control functionality be used to control the execution at Process level
i.e. just log one entry in the Process-Control table for each run of this process.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 97 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.7. Data Aggregation Tools (BRDBX007)
The Data Aggregation provides the process control and business logic required to perform the data
aggregations described in Section 5.4.
7.2.7.1 Application Type
The aggregation mechanism will be implemented in the form of PL/SQL _ stored
packages/procedures/functions. The functionality may be handled by common PL/SQL objects as
appropriate.
There will be a single point for calling all aggregation objects, which will be implemented in the form of a
wrapper script developed as a Linux Shell script.
7.2.7.2 Inputs
The interface wrapper will accept the following mandatory command-line input parameters:
>» Aggregation Logical Name: This is the logical name of the SQL Aggregation to be performed
and is expected to correspond to a stored PL/SQL object that will be the access point to
implement the aggregation.
> Input Trading/Business Date: This date is used to filter the records used for aggregation.
Format is CCYYMMDD.
» Node/Instance Id: This indicates the Branch Database Node that the aggregation job instance
needs to execute against. Values range from 1...4.
In addition the aggregation wrapper will accept the following optional parameters that may be needed for
specific aggregation jobs.
> Optional Parameter #1: This is an alphanumeric parameter that can be up to 100 characters
long.
> Optional Parameter #2: This is an alphanumeric parameter that can be up to 100 characters
long.
» Optional Parameter #3: This is an alphanumeric parameter that can be up to 100 characters
long.
All input parameters will be passed to the PL/SQL object that performs the aggregation.
7.2.7.3. Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.7.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
The aggregation business logic will reside within the Branch Database.
7.2.7.5 Scheduling
Multiple instances of the aggregation wrapper script run at different times during the day. With a few
exceptions, each instance will run on a separate node of the Branch Database.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 98 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Refer to the Scheduling High Level Design [R12] for more details.
7.2.7.6 Processing Details
The design principles behind the data aggregation tool and its logical implementation are discussed in
Section 5.4.
The wrapper script validates the command-line input parameters and calls the relevant data aggregation
PL/SQL object to pass on the parameters. The script traps / handles Node / Instance failures and returns
appropriate return status back to the scheduler.
The aggregation PL/SQL object formulates the SQL statement required to implement each step of the
aggregation required. The application logic required to implement various data aggregations to be
performed is discussed in Section 5.4.
7.2.7.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun from the point of failure. If the
failure reason is a Branch Database node/instance failure, a number of recovery jobs will be fired on the
other nodes/instances of the Branch Database. Details are available in the Scheduling High Level Design
[R12].
The level of Process Control / point of restart for a data aggregation job will depend on whether it has
been implemented as a single instance or four instances.
Typically for aggregation jobs that are implemented as a single instance, the restart point is entire run for
the day. This covers all smaller aggregations where the amount of time lost in the event of a rerun is
insignificant.
For aggregations implemented as four instances (one per database node), the restart point is at a Fad-
Hash level. This covers all aggregation jobs where finer control may be needed due to the large volumes
of data being processed.
There may be exceptions to this rule and these would be highlighted in Section 5.4.
7.2.8 Check Job Completion (BRDBC008)
The check job completion too! is an important component of the overnight schedule and is used by the
scheduler to determine if a batch schedule that consists of multiple (Fad-Hash specific) restart points has
completed successfully.
7.2.8.1 Application Type
This is a Pro*C application.
7.2.8.2 Inputs
The check job tool accepts the following mandatory command-line input parameters:
> Process Name: This is the name of the process that runs the batch job in question e.g.
BRDBC002.
> Input Business/Selection Date: This indicates the business day for the processing. Format is
CCYYMMDD.
The check job tool can also accept the following optional command-line input parameters:
> Input Parameter 1: First component used to form the “Job Instance Name”.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 99 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
> Input Parameter 2: Second component used to form the “Job Instance Name”.
> Input Parameter 3: Second component used to form the “Job Instance Name”.
7.2.8.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.8.4 Location
Script should reside in $BRDB_PROC directory on each Node.
7.2.8.5 Scheduling
The process runs a number of times every day at the completion of each batch job schedule involving
running jobs that are controllable at Fad-Hash level. The job will run on Node-1 of the Branch Database.
Refer to the Scheduling High Level Design [R12] for more details.
7.2.8.6 Processing Details
The process forms the “Job Instance Name” template using Input Parameter 1(if present) + “ - “ + Input
Parameter 2 (if present) + “ - “ + Input Parameter 3 (if present). If none of the optional parameters are
present, the Instance-Name template remains as NULL.
For each Fad-Hash value (0...127), the Instance Name is completed by appending “ - “ + Fad-Hash to
the “Job Instance Name” template and is checked against the Process-Control using input Process Name
and Business Date. Run-Number must be left as 1. If the query returns that the instance was never run or
did not finish successfully, the check tool exits with failure.
If all instances finished successfully, the check tool exits with success.
The check tool must indicate success/failure status of each Process-Control entry on standard output to
aid support.
7.2.8.7 I Handling Failures and Rerun ability
The check tool is designed to fail if the jobs instances that it is checking for have not finished
successfully. Recovery actions have been defined in the Scheduling High Level Design [R12] in the event
of failures.
It is recommended that the Process Control functionality should not be used to control the execution.
7.2.9 End Of Day (BRDBC009)
The BRDB End of Day process will run as the last activity prior to the database backup activities.
7.2.9.1 Application Type
This is a Pro*C application.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 100 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.9.2 Inputs
None.
7.2.9.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.9.4 Location
Script should reside in $BRDB_PROC directory on each Node.
7.2.9.5 Scheduling
The application runs every day in the form of a single instance after the completion of all other host
application instances (except the interactive batch jobs). The job will run on Node-1 of the Branch
Database.
7.2.9.6 Processing Details
It is highly recommended to use existing functionality used by TES-Host system.
End of Day will set the values of the system flags that control the execution of the Track & Trace and the
Guaranteed Reversals feed to NPS, to allow such processes to exit with Success. This will allow the
interactive Batch Interfaces to exit cleanly.
Additionally the process will check whether instances listed in BRDB_OPERATIONAL_INSTANCES table
have restarted, in which case that instance's “Is-Available” flag will be reset to “Y". The check should be
in the form making a TCP/IP (not bequeath) connection to the instance to run a dummy SQL. This will
implicitly check if (a) the listener is up and (b) the instance (and hence the ASM) is up.
The possible outcomes of the check and action to be taken are summarised below:
BRDB Instance / ASM/ BRDB-Operational- Action to be taken
node / Service Instances
Is-Available flag value
Up (ie. dummy SQL returns Y None. This is the expected result.
‘expected response)
Up (i.e. dummy SQL returns N Reset the Flag value to Y. Write a diagnostic message to STDOUT.
‘expected response)
Down (dummy SQL fails N Raise a B (medium) priority exception to highlight that the node is
due to any reason) down
Down (dummy SQL fails Y Raise an A (high) priority exception to highlight that the node is down
due to any reason) but metadata indicates that the node is up.
This will require an immediate response from first line to investigate
and reset the flag in BRDB-Operational-Instances table.
7.2.9.7. Handling Failures and Rerun ability
In the event of a failure, the failed job instance should rerun from the beginning of the job. If the failure
reason is a Branch Database node/instance failure, the job will be rerun on another node/instance.
Details are available in the Scheduling High Level Design [R12].
It is recommended that the Process Control functionality be used to control the execution at Process
level.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 101 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.10 Detect and Report Node Failures using FAN (BRDBX010 build
directory)
The failure detection script uses Oracle's Fast Application Notification (FAN) facility. FAN is a feature that
filters and publishes only high-level failure events such as the unavailability of a Node / Branch Database
Instance or unavailability of the underlying cluster drivers.
The failure detection script will be one of the scripts called by the Oracle supplied failure notification
wrapper script. This script will be called ‘fan_event_handler.ksh’. This script will then call a second
script
This second script .'brdb_inst_unavail.ksh’ uses the Failure Notification events passed in on command-
line to update the BRDB_OPERATIONAL_INSTANCES table. This will allow the Branch Access Layer to
determine the correct instance to access for an incoming Fad-Hash request.
Please note this script is not called by the TWS schedule.
7.2.10.1 Application Type
This is a Linux Shell Scripts.
7.2.10.2. Inputs
The first script is called by Oracle background processes and accepts the following command line
parameter pairs in the format PARAMETER=VALUE :-
e Version
° Service
e Database Name
* Instance Name
« Host Name
« Status
e Reason
© Card
« Timestamp
The second script must accept the following Oracle FAN input parameters :-
e Event type
e =©Status
« Database Name
« Host Name
e Event String
Ideally it should accept all the input parameters that Oracle’s FAN is capable of passing to the script.
7.2.10.3 Outputs
Return Code 0 for Successful Execution
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 102 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Return 1 for all other types of Failures
7.2.10.4 Location
The second script should reside in $BRDB_SH directory on each node of the Branch Database cluster.
It should be called by a first script, which resides in the $ORA_CRS_HOME/racgJ/usrco directory on
each Branch Database Node. Note that the wrapper script might be calling other alerting/monitoring
scripts hence any changes to the wrapper script must be made with care.
7.2.10.5 Scheduling
There is no scheduling involved. The script resides on the Branch Database nodes and will be invoked by
Oracle's FAN in the event of a high priority event.
7.2.10.6 Processing Details
The wrapper script should perform two functions:
» Propagate the notification event as a ‘Fatal’ event onto the SYSLOG for onward routing to Event
Monitoring. This can be achieved by using the OS level command “logger”.
» Call the application component of the failure detection script in the $BRDB_SH directory.
The failure detection script that resides in the $BRDB_SH directory performs the following functions:
» Check for all failures at Node and ASM level as well as Instance level where the database name
is “BRDB” (to protect against failure of any other database sharing the node with BRDB).
> If the failure Status is “down” or “nodedown’”, script should use the BRDB service to connect to
the database and update the “IS_AVAILABLE” status for the failed node in the
BRDB_OPERATIONAL_INSTANCES table to “N”.
7.2.10.7 Handling Failures and Rerun ability
Writing the event to SYSLOG should not cause the script to fail but if in the rare event of this occurring,
the failure cannot be detected and will pass un-noticed.
If the function of updating the BRDB_OPERATIONAL_INSTANCES table cannot be performed, the script
should log another event on the SYSLOG to that effect and also log an Operational Exception.
The script is not controlled by Process Control.
7.2.11 Update System Parameters (BRDBX011)
The Update-Parameters script will be executed at various times during the Business Day to set / reset the
values of the System Parameter that is passed on the command-line.
7.2.11.1 Application Type
This is a Linux Shell Script with optional PL/SQL elements.
7.2.11.2. Inputs
The script accepts the following mandatory command-line input parameters:
>» Parameter Name: This is the name of an existing Branch Database System Parameter.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 103 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
>» Parameter Type: Indicates the data-type of the System Parameter. Possible values are:
o N—Number
o D-Date (format YYYYMMDD)
o T-Text (Alphanumeric value)
>» Parameter Value: Value to set the parameter to.
7.2.11.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.11.4 Location
Script should reside in $BRDB_SH directory on each Node.
7.2.11.5 Scheduling
The script will be run at multiple times during the business day in the form of a single instance The script
will run on Node-1 of the Branch Database.
7.2.11.6 Processing Details
The script needs to use the three input parameters to formulate the SQL Statement to execute against
the BRDB_SYSTEM_PARAMETERS table. The SQL statement should match the following template:
UPDATE brd tem parameters
SET
parameter date = TO DATE (input-parameter-value, ‘YYYYMMDD’) ~ If input-parameter-type is‘)!
parameter number = input-parameter-value - I{ input-parameter-type is ‘N‘
or.
parameter text = input-parameter-value - If input-parameter-type is ‘tT’
WHERE parameter name = input-parameter-name
7.2.11.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance should rerun from the beginning of the job. If the failure
reason is a Branch Database node/instance failure, the job will be rerun on another node/instance and
this will be handled by TWS. Details are available in the Scheduling High Level Design [R12].
It is recommended that the Process Control functionality should not be used to contro! the execution at
Process level. However every run must involve creating Process-Audit entries as per HADDIS guidelines
[R7].
7.2.12 SSC Transaction Correction Tool (BRDBX015)
This utility will allow SSC to correct transactions by adding compensating correction records to
transactional / accounting / stock tables in the BRDB database. The utility will also audit the changes
made and ensure that the changes + audit are performed as a single commit unit. There will be no
updating / deleting of records in the Branch database. This is done by reading and executing the SQL in
transaction files that are stored in the file system.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 104 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.12.1 Application Type
This is a Linux shell script based application. The core functionality will be implemented in an Oracle
PL/SQL package, which will be called by the Linux shell script.
The shell script will be owned by Linux user “supporttooluser” and it is deliberately kept separate from the
standard $BRDB_SH directory so that access to the script and the associated components can be
restricted to authorised users.. The PL/SQL package PKG_BRDB_TXN_CORRECTION will be owned by
Oracle user “OPS$SUPPORTTOOLUSER”. The PL/SQL package PKG_BRDB_TXN_CORRECTION will
execute with the permissions of the OPS$SUPPORTTOOLUSER account and can only insert rows into
the transaction tables as controlled by an entry in BRDB_SYSTEM_PARAMETERS. The account will not
have update or delete privileges.
The BRDBX015.sh script logs into Oracle as ‘/' (i.e. OPS$<SSCusername>), therefore in order to run, all
of the Oracle OPS$ users for the SSC users require database privileges on the package as follows:
Object Name Object Ins I Sel Upd I Del I Exe
Type
PKG_BRDB_TXN_CORRECTION Package x
Note that the create_db_user.sh script has been changed to grant the above privilege to new SSC Oracle
users when they are created.
7.2.12.2 Inputs
The utility accepts the following mandatory command-line input parameter:
> Transaction-File-Name: Name of the file (including path) that contains the compensating
transaction correction record.
» Branch Code: The number of the branch specific to this correction transaction.
7.2.12.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.12.4 Location
The script should reside in /app/brdb/trans/support/brdbx015 directory on each Node.
Each of the transaction tables that are allowed to have balancing transactions inserted on them has an
associated template file. Each file contains a template of an INSERT statement for that table, in the
required format, and listing all of the columns on the table. Users should create their own transaction file
based upon the relevant template file, substituting the values they require into the SQL. Note that some
of the column values specified in the template should not be changed — these are annotated with
comments as appropriate.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 105 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
The collection of template files are available from source control along with the other components. They
are also included in the Branch Support Guide.
The completed transaction file, based on the template file, contains a SQL INSERT statement that
creates the required balancing transaction. The file must be placed in this directory:
/app/brdb/trans/support/brdbx0 1 5/input
When execution is complete the file is then moved to directory ‘/app/brdb/trans/support/brdbx0 1 5/output’
and the log file is created in directory ‘/app/brdb/trans/support/brdbx015/log’. Log file will be named using
the following convention:
<transaction_file_name>_<CCYYMMDDHHMISS>.log
7.2.12.5 Scheduling
The utility will not run on a regular basis. It will be used manually by SSC (third-line) support, please refer
to the Branch Support Guide [R43] for usage..
7.2.12.6 Processing Details
Warning: The use of this powerful tool has inherent risks. If the SQL statement is
incorrect or badly written, it is possible to cause unintended consequences, some of
which may cause serious problems to the Branch Database. It is expected that only a
small number of skilled staff will run this tool and that they will have detailed guidance
as to when and how to use the tool.
Having logged into their own Unix user, the SSC team members will change directory to the
/app/brdb/trans/support/brdbx015 directory and place their transaction file in the
/app/brdb/trans/support/brdbx015/input sub-directory. They will then invoke BRDBX015 manually. The
shell script module will be owned by the Unix user “supporttooluser”.
e From the Unix command prompt, execute the following
./BRDBX015.sh MyTransactionFile.sq! 2001
where the first parameter is the transaction file name and the second parameter is the branch code
where the balancing transaction is going to be applied. Note that the branch code must exist in the
database, and must not be for a closed branch. If this is not the case, then an error message will
be shown and the run aborted.
The tool will read the contents of the input transaction file, which will be in the form of single SQL-insert
statement.
The SQL also includes a number of bind variables (e.g :bind_branch_code). Actual values for these fields
will be substituted into the SQL before it is executed. The available bind variables are listed below,
together details of the values that will be substituted for them if they appear in a transaction file
e — :bind_branch_code : substituted with the values of the branch code
argument of BRDBX015
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref DES/APPIHLDIO020
Version: V1.0
Date: 17-Nov-2009
Page No: 106 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
e — :bind_SSC_user : substituted with the Oracle user that is carrying out the
actual insert i.e. SUPPORTTOOLUSER
e — :bind_instance_name : substituted with the name of the Oracle instance upon
which the tool is run
The correction tool places a number of constraints on the contents of the transaction file. These are
necessary in order to provide a defined baseline upon which it can base its operation. If any of the
constraints are violated then validation will detect it and abort the run with a meaningful error message.
The constraints are as follows:
* The transaction file must be less than 32K in size
e The transaction file must only contain Unix-style end of line markers (EOL), not DOS
format end of line markers (CR/EOL)
«The transaction file can only contain a single SQL statement. If more than one balancing
transaction is required then more than one transaction file must be created, each of
which is executed with a separate run of the tool
e If the transaction file contains an introductory comment, then it must be a ‘/* ...... *? style
comment, not a ‘-- .' style comment
e The closing ‘*/’ of the introductory comment must have a trailing space (i.e. w)
e The run symbol at the end of the SQL must be a ‘;’ , not ‘/’, and must have a trailing
space (i.e. ‘.....5 ')
e The SQL must be a valid SQL statement according to the normal Oracle SQL parsing
rules (e.g. valid syntax, objects accessible etc)
* The SQL must begin with ‘INSERT INTO OPS$BRDB.' and be of the form ‘INSERT
INTO SELECT ..... FROM dual, (SELECT ..... FROM .... WHERE .....)’.
« The table name must be one of the tables named in the
BRDB_TXN_CORRECTION_ALLOWED_TABLES1 or
BRDB_TXN_CORRECTION_ALLOWED_TABLES2 configuration parameters
e All of the columns that exist on the table in question must be explicitly named. It is not
necessary for every listed column to be on a separate line, but this is advisable for
readability.
e The values to be inserted must be provided by the ‘SELECT ... FROM dual ...’. Each
value must be on a separate line. Trailing comments are allowed, but must be a ‘-- .....
style comment. Any such comment must not include any commas. All columns must
have values provided for them (even if that value is NULL).
* Certain columns are common between a subset of the transaction tables. In some cases,
these columns should be set to the same value no matter what table is in use. With the
exception of the bind variables listed earlier, the value that the SQL will try to insert is
under the control of the user (i.e. it is determined by the value specified in the SQL).
However, the tool can be configured to validate that the value specified in the SQL
matches that expected. In order to do this, set the
BRDB_TXN_CORRECTION_ENFORCED_VALUES configuration parameter to include
the field and the required value.
The parameter is populated as a comma-delimited list of name/value pairs, where the
name is the name of the column name, and the value is the value to be enforced. As
released, this configuration parameter is set to:
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 107 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
NODE_ID=99,APP_SERVER_NODE_NAME=999,BRANCH_USER=:bind_SSC_user,B
RDB_INSTANCE_NAME=:bind_instance_name
which, for example. ensures that if a ‘node_id’ column exists on the transaction table, it's
value is specified as 99. If there is no ‘node_id’ on the transaction table, then no value is
enforced for that field. Note that if the parameter does not exist, then no values are
enforced in the SQL.
Since all transaction tables are partition and sub-partitioned by fad hash. It is vital that the insert
statement set the value of the fad hash to the correct value corresponding to the branch code.
Development have created within the templates SQL code that derives the fad hash correctly, this should
be used as the basis of the SQL preparation and not amended as per the comments within the template
file.
If valid, the SQL statement is modified by substituting actual values for bind variables, and the modified
SQL statement is executed and logged in the journal as an XML string.
The SQL statement being executed will be logged in the table BRDB_TXN_CORR_JOURNAL. The
format of the data to be written to the column JOURNAL_XML is:
“<?xml version="1.0" encoding="UTF-8"?>
<Support_Insert>
<Unix_User>Unix User Name</Unix_User>
<Oracle_User>Oracle User Name</Oracle_User>
<Sql>SQL Statement</SqI>
</Support_Insert>”
where :
« Unix User Name is the Unix user name under which the user logged in
e Oracle User Name is Oracle user that is carrying out the actual insert i.e.
SUPPORTTOOLUSER
e SQL Statement is the final (ie. after substituting actual values for bind variables) SQL
that is executed to insert the balancing transaction
More details on the process and the risks will be defined in the Branch Database Support Guide [R43].
7.2.12.7 Handling Failures and Rerun ability
In the event of a node / instance failure, if the failure reason could be interpreted from the Oracle Error,
the utility needs to fail with error code 99. For any other failures, the exit code should be 1 and an
operational exception should be logged.
The Process Control functionality should not be used to control the execution at Process level. However
the Process Audit log (brdb_process_audit) must be populated once at the beginning and then end of
execution.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 108 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.13 BRDB transfer to DWh (BRDBX020)
This utility is the file transfer for BRDB Branch Migration Status data feed to DWh
7.2.13.1 Application Type
This is a Linux shell script based application.
7.2.13.2 Inputs
The utility accepts the following mandatory command-line input parameter:
> Input Business Date: This date is used to source files. Format is CCYYMMDD.
7.2.13.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.13.4 Location
The script should reside in $BRDB_SH directory on each Node.
7.2.13.5 Scheduling
The utility will be run on a daily basis via the BRDB TWS schedule.
7.2.13.6 Target Directories
See REPOSITORY env variable.
7.2.13.7 Processing Details
The utility will perform the following functions:
1. Accept command line input for the effective date.
2. Deduce the source file and directory based on the BRDB_MSU_OUTPUT env variable and
the effective date.
3. Form the destination directory based and file name based on the REPOSITORY env
variable, system name and effective date.
4. Check the availability of the source and destination directories and the source file.
5. Moves the source file to the destination directory. NOTE: This means that the source
directory will not have the file, once it has been successfully moved to the destination directory.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 109 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.13.8 Handling Failures and Rerun ability
In the event of a node / instance failure, if the failure reason could be interpreted from the Oracle Error,
the utility needs to fail with error code 99. For any other failures, the exit code should be 1 and an
operational exception should be logged.
7.2.14 Pause / Start Streams Propagation (BRDBX021)
This utility will pause or restart the propagation of Streams messages to the BRSS system.
7.2.14.1 Application Type
This is a Linux shell script based application.
7.2.14.2 Inputs
The utility accepts the following mandatory command-line input parameter:
> Action-Type: The type of action to perform on Streams Propagation. Allowable values are
“PAUSE” and “RESTART”.
7.2.14.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures
7.2.14.4. Location
The script should reside in $BRDB_SH directory on each Node.
7.2.14.5 Scheduling
The utility will not run on a regular basis. It will be used either manually or called from another script as
required.
7.2.14.6 Target Directories
No files or directories are written to by this utility.
7.2.14.7 Processing Details
The utility will perform two actions depending on the value of input parameter “Action-Type”. For the
“PAUSE” action, the utility will pause the propagation of LCRs to the remote queue in the BRSS system.
For the “RESTART” action, a previously paused propagation of LCRs to BRSS will be restarted.
There are a number of ways of pausing / restarting queue propagation such as unscheduling / scheduling
propagation or by disabling and enabling a propagation schedule. The exact method used will be
determined in the Low Level design.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 110 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The utility can ‘hard-code’ the names of Oracle objects associated with streams replication to BRSS such
as rule, propagation schedule, queue name etc.
7.2.14.8 Handling Failures and Rerun ability
In the event of a node / instance failure, if the failure reason could be interpreted from the Oracle Error,
the utility needs to fail with error code 99. For any other failures, the exit code should be 1 and an
operational exception should be logged.
The Process Control functionality should not be used to control the execution at Process level. However
the Process Audit log (brdb_process_audit) must be populated once at the beginning and then end of
execution.
7.2.15 Hydra-specific XML Data Processor (BRDBX030)
The XML data processor parses XML data present in an Oracle database column and loads it in
relational form into one or more target tables.
This is a hydra-specific tool and is expected to be put out of use once the hydra phase is complete. The
source XML tag names and the target table and column names are hard-coded with the view of simple
implementation.
7.2.15.1 Application Type
The XML data processor will be implemented in the form of a PL/SQL stored package.
There will be a single wrapper script developed as a Linux Shell script to provide access to the PL/SQL
object and to pass command-line input parameters.
The script will call the end-of-day processing first then call the in-day processing second. This is a logical
requirement because the stock units and stock positions are required before the in-day process ‘flips’ the
branch status from Horizon to HNG-x. In-day processing will only be performed for ‘NORMAL’ runs.
7.2.15.2 Inputs
The XML processor will accept the following mandatory command-line input parameters:
» Input Trading/Business Date: This date is used to filter the records used for parsing. Format is
CCYYMMDD.
>» Node/instance Id: This indicates the Branch Database Node that the aggregation job instance
needs to execute against. Values range from 0...4.
IDN: Node-Id is not strictly needed but provides with the flexibility of being able to run the parser
on multiple nodes if performance issues arise.] NOTE. When the script is run on a single node
then the command line parameter for Node/instance Id should be 0 (zero). This will then iterate
through each fad_hash / instance goup.
> Run Mode: ‘NORMAL’ (default) or ‘CATCHUP’ - This determines whether or not to apply TPS
filtering.
All input parameters will be passed to the PL/SQL object that performs the XML processing.
7.2.15.3 Outputs
Return Code 0 for Successful Execution
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 111 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.15.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
The XML processing business logic will reside within the Branch Database.
7.2.15.5 Scheduling
A single instance of the XML processor will be run in ‘NORMAL’ mode once during the processing day
following the completion of the Aggregation and pre-processing (BRDBX033) once every Sunday in
‘CATCHUP'’ mode. NOTE. The module has been designed to be able to run on all four nodes
concurrently. This feature is required if the rollout of branches become compressed and a large number
of branches are migrating concurrently.
Refer to the Scheduling High Level Design [R12] for more details on scheduling of the XML processor
jobs.
7.2.15.6 Processing Details
The XML processing step forms the second part of the processing involved for the hydra-specific ongoing
and ‘in-day' feeds from TPS. The logical implementation of the XML processing required including the
XML tag-names — database column mappings are discussed in [R40] and [R28].
The process must be able to logically partition the branches by fad_hash code so that concurrent runs of
the job on different nodes do not interfere with each other. The split of branches across instances will be
controlled by the mapping of branch codes to fad hash to available instances.
The processing will use a series of temporary / working tables to decompose the XML statements into
their constituent parts. These tables are ‘list’ partitioned by either fad_hash or instance node id.
The wrapper script validates the command-line input parameters and calls the relevant PL/SQL objects in
order. The script traps/handles Node/Instance failures and returns appropriate return status back to the
scheduler.
The XML data processor PL/SQL object reads the XML data that is stored in a CLOB in the source
tables, parses and converts the XML into relational form and loads the target tables.
7.2.15.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun from the point of failure. If the
failure reason is a Branch Database node/instance failure, the failed job instance will be fired on one of
the other nodes/instances of the Branch Database. Details are available in the Scheduling High Level
Design [R12].
The level of Process Control / point of restart for the XML data processor is at the level of a single XML
statement, which means that the processing must be repeated in the event of a restart after failure.
However given the program will only select un-processed rows, the time of night the process is expected
to run and the scope of the process (hydra-specific), a selective rerun is acceptable.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 112 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.16 BRDB Reset JSN, SSN, USN (BRDBX031)
Counters do not always logoff tidily in the HNG-X environment, hence the information maintained in table
BRDB_BRANCH_NODE_INFO for JSN/USN/SSN can be out of date. A tidy counter logoff will update the
values in BRDB_BRANCH_NODE_INFO correctly.
To combat this the job searchs the underlying BRDB tables for the maximum value for each JSN, USN
and SSN used that day. If the value is greater in the base table then the BRDB_BRANCH_NODE_INFO
(BBNI) value is out of date and can be updated with the value from the base table. For JSN & USN we
don't have to worry about rollover but as SSN is a NUMBER(6) in the base table this will rollover every
@7 years for a counter. As such for SSN the script caters for SSN rollover from 999,999 to O+.
7.2.16.1 Application Type
The BBNI maintenance script will be implemented in the form of a Linux Shell script.
7.2.16.2 Inputs
The Linux Shell script takes a single parameter of business day, whose format is CCYYMMDD.
7.2.16.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.16.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
7.2.16.5 Scheduling
A single instance of the script will be run once during the processing day following the completion of
aggregation. The module is able to run on any available node.
Refer to the Scheduling High Level Design [R12] for more details on scheduling of the BBNI maintenance
job.
7.2.16.6 Processing Details
Truncate the table WKG_BRDB_JSN_USN_SSN
Populate the WKG_BRDB_JSN_USN_SSN fields from BRDB_BRANCH_NODE_INFO.
For each counter (node-id) that exists in BRDB_RX_MESSAGE_JOURNAL find the current
maximum JSN (CURRENT_MAX_JSN) in table BRDB_RX_MESSAGE_JOURNAL and update it
in WKG_BRDB_JSN_USN_SSN.
d) If the value for the CURRENT_MAX_JSN now in WKG_BRDB_JSN_USN_SSN is greater than
that currently in BRDB_BRANCH_NODE_INFO then update BRDB_BRANCH_NODE_INFO.
CURRENT_MAX_JSN.
RRR
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 113 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
e) For each counter (node) that exists in BRDB_RX_RECOVERY_TRANSACTIONS find the current
maximum USN (CURRENT_MAX_USN) in table BRDB_RX_RECOVERY_TRANSACTIONS and
update it in WKG_BRDB_JSN_USN_SSN.
f) If the value for the CURRENT_MAX_USN now in WKG_BRDB_JSN_USN_SSN is greater than
that currently in BRDB_BRANCH_NODE_INFO then update BRDB_BRANCH_NODE_INFO.
CURRENT_MAX_USN.
g) For each counter (node) that exists in BRDB_RX_REP_SESSION_DATA find the current
maximum SSN (SESSION_ID) in table BRDB_RX_REP_SESSION_DATA and update
CURRENT_MAX_SSN in WKG_BRDB_JSN_USN_SSN
h)_ If the value for the CURRENT_MAX_SSN now in WKG_BRDB_JSN_USN_SSN is greater than
that currently in BRDB_BRANCH_NODE_INFO then update BRDB_BRANCH_NODE_INFO.
CURRENT_MAX_SSN. If the existing value of CURRENT_MAX_SSN now in
BRDB_BRANCH_NODE_INFO is > 990,000 and the value in WKG_BRDB_JSN_USN_SSN is
between 0 and 009,000 then update BRDB_BRANCH_NODE_INFO. CURRENT_MAX_SSN
with the value in WKG_BRDB_JSN_USN_SSN.CURRENT_MAX_SSN. Also the field
CURRENT_MAX_SSN_JOURNAL_DATE will be updated.
7.2.16.7 Handling Failures and Rerun ability
In the event of a failure, the failed job needs to be able to rerun from the start. If the failure reason is a
Branch Database node/instance failure, the failed job instance will be fired on one of the other
nodes/instances of the Branch Database. Details are available in the Scheduling High Level Design [R12]
7.2.17 Hydra-specific XML Data Pre-Processor (BRDBX033)
The XML data processor parses XML data present in an Oracle database column and loads it in
relational form into one or more target tables.
This is a hydra-specific tool and is expected to be put out of use once the hydra phase is complete. The
source XML tag names and the target table and column names are hard-coded with the view of simple
implementation.
7.2.17.1. Application Type
The XML data processor will be implemented in the form of a PL/SQL stored package.
There will be a single wrapper script developed as a Linux Shell script to provide access to the PL/SQL
object and to pass command-line input parameters.
The script will call the end-of-day pre-processing.
7.2.17.2 Inputs
The XML processor will accept the following mandatory command-line input parameters:
> Input Trading/Business Date: This date is used to filter the records used for parsing. Format is
CCYYMMDD.
>» Node/instance Id: This indicates the Branch Database Node that the aggregation job instance
needs to execute against. Values range from 0...4.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 114 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
[DN: Node-id is not strictly needed but provides with the flexibility of being able to run the parser
on multiple nodes if performance issues arise.] NOTE. When the script is run on a single node
then the command line parameter for Node/Instance Id should be O (zero). This will then iterate
through each fad_hash / instance goup.
>» Run Mode: ‘NORMAL’ (default) or ‘CATCHUP’ - This determines whether or not to apply TPS
filtering.
All input parameters will be passed to the PL/SQL object that performs the XML processing.
7.2.17.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.17.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
The XML processing business logic will reside within the Branch Database.
7.2.17.5 Scheduling
A single instance of the XML processor will be run in ‘NORMAL’ mode once during the processing day
following the completion of the TPS filter branches (BRDBX034) and TPS-BRDB hydra-specific interface
(see Section Error! Reference source not found.) once every Sunday in ‘CATCHUP’ mode. NOTE. The
module has been designed to be able to run on all four nodes concurrently. This feature is required if the
rollout of branches become compressed and a large number of branches are migrating concurrently.
Refer to the Scheduling High Level Design [R12] for more details on scheduling of the XML processor
jobs.
7.2.17.6 Processing Details
The XML processing step forms the first part of the processing involved for the hydra-specific ongoing
feeds from TPS. The logical implementation of the XML processing required including the XML tag-
names — database column mappings are discussed in [R40] and [R28].
The process must be able to logically partition the branches by fad_hash code so that concurrent runs of
the job on different nodes do not interfere with each other. The split of branches across instances will be
controlled by the mapping of branch codes to fad hash to available instances.
The processing will use a series of temporary / working tables to decompose the XML statements into
their constituent parts. These tables are ‘list’ partitioned by either fad_hash or instance node id.
The wrapper script validates the command-line input parameters and calls the relevant PL/SQL objects in
order. The script traps/handles Node/Instance failures and returns appropriate return status back to the
scheduler.
The XML data processor PL/SQL object reads the XML data that is stored in a CLOB in the source
tables, parses and converts the XML into relational form and loads the target tables.
7.2.17.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance needs to be able to rerun from the point of failure. If the
failure reason is a Branch Database node/instance failure, the failed job instance will be fired on one of
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 115 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
the other nodes/instances of the Branch Database. Details are available in the Scheduling High Level
Design [R12]
The level of Process Control / point of restart for the XML data processor is at the level of a single XML
statement, which means that the processing must be repeated in the event of a restart after failure.
However given the program will only select un-processed rows, the time of night the process is expected
to run and the scope of the process (hydra-specific), a selective rerun is acceptable.
7.2.18 Hydra-specific TPS filter loader (BRDBX034)
This loader will pull branch_codes from rdds for those branches pending migration within the next 14
days.
7.2.18.1 Application Type
The loaded will be implemented in the form of a PL/SQL stored package.
There will be a single wrapper script developed as a Linux Shell script to provide access to the PL/SQL
object and to pass command-line input parameters.
7.2.18.2 Inputs
The processor will accept the following mandatory command-line input parameters:
> Input Trading/Business Date: This date is used to filter the records used for parsing. Format is
CCYYMMDD.
All input parameters will be passed to the PL/SQL object that performs the processing.
7.2.18.3 Outputs
Return Code 0 for Successful Execution
Returns 99 for a failure due to Node/Instance failure and 1 for all other types of Failures.
7.2.18.4 Location
The wrapper script should reside in $BRDB_SH directory on each Node.
The processing business logic will reside within the Branch Database.
7.2.18.5 Scheduling
A single instance of the loader will be run once during the processing day following the completion of
‘start of day’. NOTE. The module has been designed to be able to run on one node only.
7.2.18.6 Processing Details
Merge into brdb_hydra_tps filter all branch_codes in the rdds view rd_migrating_branches where
target_migrationj_day is less than 14 days ahead.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 116 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
7.2.18.7 Handling Failures and Rerun ability
In the event of a failure, the failed job instance should be re-run
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 117 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
8 Branch Standby Database Solution
The Branch Database acts as the sole persistent store for Counter trading data. Unavailability of the
Branch Database would mean loss of all trading capabilities at the Counter. The Branch Database
solution needs to provide an alternate capability to prevent it from being the single point of failure that
results in a site DR.
The Branch Database will use SRDF replicated Service Level-1 storage) for its data store to protect the
data against a storage device failure. However SRDF does not provide any protection against table /
index level block corruptions that may lead to either loss of data or prevent the database from functioning.
As discussed later in Section 12.6.4, Oracle block corruptions can potentially result in the Branch
Database being unavailable for a length of time that may result in violation of availability targets (see
12.2.1).
In this scenario, alternate means of trading will be provided via a standby database, which will be an
asynchronously updated clone of the BRDB. The standby database will be implemented using Oracle
Data Guard technology, which provides a highly efficient means of maintaining a continually updated
database copy.
The standby database data-store will reside in a separate EMC frame (cabinet) from the Branch
Database. This will be done to mitigate against any software problems that affect the entire storage frame
(cabinet).
In order to provide speedy reporting on corruptions, Data Guard will be used to check for corruptions in
source database blocks before they are applied to the BRDB-Standby.
8.1 Standby Database Configuration
The BRDB-Standby will be implemented as a “physical standby” database i.e. the database will provide
an identical copy of BRDB in terms of database block structures and will be maintained by applying
changes made to the standby and archived redo-log files of BRDB.
The BRDB will be configured to propagate changes to standby database in “Maximum Performance”
mode, which provides the highest level of data protection that is possible without affecting the
performance of the primary database. This is accomplished by allowing a transaction to commit as soon
as the redo data needed to recover that transaction is written to the local online redo log. The primary
database's redo data stream is also written to the standby database, but that redo stream is written
asynchronously with respect to the transactions that create the redo data.
Commits in BRDB will not be synchronous with propagation of changes to BRDB-Standby. Thus in the
event of a switch to standby, the standby will contain changes up to the last transaction in the most
recent redo log file. Transactions in the online redo-logs will need to be recovered by using the online
redo logs from primary.
The physical standby database is maintained by applying redo data from the standby redo log files. When
LGWR writes to the redo logs on the primary, a network server process (LNS) will read these logs and
communicate with an RFS (Remote File Service) process, which will write to the standby logs. The write
to the standby logs will be asynchronous so there is no pressure for a "Commit Complete" record to be
returned to the primary to allow processing to continue. This configuration overall means that the LGWR
processes on the primary RAC instances are under no extra workload to keep the standby log-files up-to-
date.
The archiver process(es) on the standby will then write the logs to an archive destination at which stage
the Managed Recovery Process (MRP) will apply the archive logs to the standby. In effect the redo logs
will be up-to-date on both sites, the only delay being the archiving of the logs on standby before they are
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 118 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
applied to the database. In the event of a failover, the standby should in theory be up-to-date by the time
the business decision is taken to fail the primary over.
With Oracle10g, there is the possibility of Real-Time Apply i.e. the MRP process reads the standby redo
logs (as opposed to the archive logs) and applies them immediately to the database. Bearing in mind the
overhead that such a configuration would present on the (already overloaded) single-node Standby, this
option has not been chosen. A further problem with Real-Time Apply is that there can only be 1 MRP.
process per server (yet multiple RFS processes) and there is a strong possibility that the MRP process
would not be able to keep up with the workload on the 1-node standby especially during peak times.
Use of the physical standby option means that the standby database cannot be open in read-write or
even read-only modes while log-apply continues. This is acceptable as there is no requirement for the
database to be used while the primary database (BRDB) is operational.
The main advantage of using a “physical standby” over the alternate “logical standby” is performance.
The Redo Apply technology used by the physical standby database applies changes using low-level
recovery mechanisms, which bypass all SQL level code layers; therefore, it is the most efficient
mechanism for applying high volumes of redo data and will present a reduced load on the BRDB-Standby
server.
The standby solution will use a Data Guard Broker to manage and monitor the Data Guard replication.
Using the broker will result in more meaningful alerts to appear in Grid Control if the replication were to
fail.
8.2 Setting up Branch Standby Database
As outlined in Section 8.1, the Branch Standby database will be implemented as a physical standby
database to ensure maximum performance of the primary and efficient use of standby resources.
This section outlines some of the important configuration changes required to the Branch Database and
Branch Standby Database.
8.2.1 Initial Setup
The BRDB-standby database will be setup as a clustered database with four nodes (instances). The
platform and the product component stack used will be the same as for the Branch Database (see
Section 6.1).
BRDB-Standby will use a separate cluster from the BRDB RAC cluster.
Storage will be managed by ASM as in case of the Branch Database (see Section 6.2). Branch Standby
Database will use non-SRDF replicated disks. Refer to [R11] for further details on the standby storage
configuration.
Note: The Standby database does not use the default Branch Standby Database disk group names,
but uses unique names, enabling a more flexible approach, e.g. should the need arise, the
standby database could use the same ASM instance as the Primary.
The initial setup of the database will be facilitated using an RMAN backup copy of the Branch Database
from the production environment and restoring it as a standby using RMAN.
Note: After the recovery of the backup onto the standby, it will be necessary to change the DBID inline
with Oracle recommendations.
Once the standby environment has been set up, three of the four nodes will be switched off and added to
the p-blade pool for use by other applications.. The BRDB-Standby database will operate as a single-
node Oracle RAC cluster.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 119 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
8.2.2 Configuration
8.2.2.1. Branch Database Configuration Changes
Enable database level forced logging
Create a database password file to store the password for the SYS user
Standby redo log files will be used as per Oracle's recommendation. The recommended number of
standby redo files is:
(Maximum number of log files for each thread (4) + 1) * Maximum number of threads (4)
This equates to 20 standby redo log files.
In addition, log and archived-redo log file name conversion must be set up to conform to the file naming
conventions.
Refer to Appendix E — Suggested Oracle Initialisation Parameters for the full list of suggested Oracle
Initialisation Parameters for the Branch Database and the Branch Standby including the changes
required to support the Data Guard implementation.
8.3. Branch Standby Database Backups
The BRDB-Standby will not be backed up and will be able to use BRDB backups for recovery of any data
that had originated from the primary (BRDB).
Although the Branch Standby Database will not be backed up daily, the Clusterware setup and
configuration as well as the database configuration files will be backed up so that the most recent known
cluster image can be restored from if needed.
The approach outlined for Branch Database backups in Sections 12.5.1 and 12.5.2 applies to Branch
Standby Database as well. OCR and Voting Disk backups need to be taken daily and retained for 7 days.
8.4 Switching to BRDB-Standby
Once a decision has been made to switch the live service to using BRDB-Standby, there are two options
available for the role transition (primary to standby):
> BRDB could ‘switchover’ with BRDB-Standby.
A switchover is used when the primary is operational but a role reversal is required for a
maintenance operation such as applying an OS patch.
There should be no data loss during a switchover except in the case of a logical corruption in the
BRDB online redo-logs (see Section 12.6.4).
BRDB could ‘failover’ to BRDB-Standby.
Failover is used if the primary becomes unavailable for any reason such as a fatal block
corruption (see Section 12.6.4) and there is no possibility of recovering from the problem within
operational service levels for failover, given agreement to proceed by CS Management..
Vv
There are a number of options available for managing the transitions to standby and role reversions.
These are (a) Manually executed SQL scripts, (b) using the Data Guard Command-line utility and (c)
using the Data Guard Broker GUI tool.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 120 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
There are security implications that rule out using the Data Guard Broker GUI tool. At the time of writing
this document, the Data Guard Command-line utility was considered error prone as it was failing to
complete the role reversal intermittently.
Hence all scripting for transition to standby and for managing role reversals will be done using manually
executed SQL scripts.
Note: The Data Guard Broker command-line utility (dgmgri) is in fact being used and will help support
teams better diagnose and control the Data Guard configuration (specifically when using OEM
Grid Control)
8.4.1 Switchover to Standby
The Branch Database design does not support a Switchover to Standby.
8.4.2 Failover to Standby
The automatic failover feature of Oracle should be disabled. A decision to failover to standby must drive a
pre-scripted but manually initiated process. The process will perform the following checks and functions:
e Check for missing archive logs on standby. This can be achieved using SQL, similar to the
following:
SQL> select thread#, low_sequencet, high_sequence# from v$archive_gap
« Ensure that all archive logs have been applied
SQL> select unique thread# as thread, max(sequence#)
SQL> over (partition by thread#) as last from v$archived_log
e Copy to standby any available primary archive logs that contain sequence numbers higher than
the highest sequence number on the target standby database. If there are then register those
files with the standby
SQL> alter database register physical logfile 'log-file-name'
e Repeat all of the above three steps until no more gaps are highlighted. There is a possibility that
additional gaps may be introduced / highlighted as archive log files are processed. This is
especially true if archive logs have to be manually registered with the database.
« Disconnect all NAS storage that has been connected to the primary and NFS-mount them to the
standby.
e — Start the now defunct primary in mount mode.
« Switch the log files for all four threads and send them across to the standby. This will allow all the
transactions present in the online redo logs at the time of failure to be recovered.
« Execute the following SQL or similar on the standby to initiate the failover:
SQL> alter database recover managed standby database finish force
e Once the standby database has caught up with the pending redo information, transition the
physical standby database to the primary database role as follows. Not that at this stage the
database can no longer be used as a standby.
SQL> alter database commit to switchover to primary
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 121 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
SQL> alter database open
« Perform cold backup of the new primary database using a BCV-split.
e Initiate Streams replication to BRSS from the new primary database.
* Change the DNS alias configuration so that all external access to “pbdb001...4” and
“pbdb001...4-vip” is now redirected to the new primary -“pbds001...4” “pbds001...4-vip”
respectively.
e Rebuild the old primary as a physical standby database and reconfigure Data Guard from new
primary to new standby database.
[DN: This ‘tole reversion’ i.e. old primary taking over the role of the standby can be achieved using other
means such as using the ‘flashback’ feature. See assumptions 1.4 on flashback]
8.4.3 Resuming Streams feed to Branch History
No changes required to the new primary to resume the Streams replication to Branch Support System.
Re-start of Streams will be required.
8.4.4 Role re-reversal
Once a role reversal has successfully completed, the (old standby) new primary will continue to operate
at the Branch Database and the old primary will function as the standby even after the problems that lead
to a failover have been resolved. Role re-reversal will not be initiated unless forced due to a failure on the
new primary.
The reasons for not re-reversing roles is that both the Primary and Standby use same or similar CPUs &
Memory and Tier-1 SAN storage and there would be no performance benefit in switching them back as
they were. A role re-reversal will lead to an outage, which may be counted as a service unavailability SLA
violation (see Section 12.2).
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 122 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
9 Platforms
This section provides a view of the platform and storage required to support the application systems
ported to IRE11 / IRE19.
9.1 Branch Database
9.1.1 Hardware Requirements
9.1.1.1 Platform
The Branch Database (BRDB) will use Fujitsu-Siemens BladeFrame environment. The BRDB
environment will be operational on four p-blades (slim-line servers) with identical hardware
configurations.
BRDB-Host (1...4) ae BRDB1...4
inna Oracle Instance
environment
Figure - 14 Branch Database Execution Environment
9.1.1.2 Processor
The minimum processor specification for each p-blade is: 4 X x86-based single-core processors with
clock speeds of 2.0 GHz.
9.1.1.3 Memory
The minimum memory required for each p-blade is 32GB.
9.1.2 Operating System
The Operating system required is Red Hat Enterprise Edition Linux version 4.5 at a suitably stable
patchset.
9.1.3 Coexistence
The Branch Database Oracle instances and execution environments have exclusive access to resources
‘on each node of the BRDB-Host. Hence co-existence is not relevant.
9.1.4 Storage
The storage requirements are defined in the relevant sizing and volumes document [R11].
All storage used by the Branch Database requires tier-1 storage, which must be synchronously replicated
to the DR site.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 123 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
9.2 BRDB-Standby Database
9.2.1 Hardware Requirements
9.2.1.1 Platform
The Branch Standby Database (BRDB-standby) will use Fujitsu-Siemens BladeFrame environment. The
BRDB environment will be operational on a single p-blade (slim-line server) but will require access to four
p-blades at the time of setup to create a 4-node cluster.
BRDB-Standby-Host ‘ BRDB-
Oracle Instance
Figure - 15 BRDB-Standby Platform Execution Environment
9.2.1.2 Processor
The minimum processor specification for the p-blade is: 4 X x86-based single-core processors with clock
speeds of 2.0 GHz.
9.2.1.3 Memory
The minimum memory required for the p-blade is 32GB.
9.2.2 Operating System
The Operating system required is Red Hat Enterprise Edition Linux version 4.5 at a suitably stable
patchset.
9.2.3 Coexistence
The BRDB-standby database and associated application processes/components will have exclusive
access to resources on the BRDB-Standby-Host.
9.2.4 Storage
The storage requirements are defined in the relevant sizing and volumes document [R11].
All storage used by the BRDB-standby requires tier-1 storage, which must be synchronously replicated to
the DR site.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 124 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
10 Networks
Network aliases named “Iprpbdb001...4” (public) & “Iprpbdb001...4-vip” (vip) for the Branch Database
nodes will be defined in the VPN configuration against the logical names of the clustered platform nodes
as per DES/PPS/HLD/0006.
Additionally aliases named “lprpbds001...4” & “lprpbds001...4-vip” for the Branch Standby Database
nodes will also be defined.
This network alias will be referred to in all of the Oracle and application specific configuration files.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 125 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
11 Manageability
Standard POA data-centre management tools will be used to monitor the data-centre based subsystems.
Section 5.7 describes the support interface in place to facilitate the Branch Database support
management.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 126 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12 System Qualities
12.1 Security
The following sections address potential security issues as highlighted by [R23].
12.1.1 Overview
BRDB security is designed in line with HADDIS [R7] and the HNG-X Security architecture [R23].
All applications will be run under the batch scheduler through defined Linux users with only the necessary
access to run the application. These users will, where necessary, be accessible only locally on the Host,
that is they cannot be accessed remotely.
Oracle database connectivity and access control will be through defined Oracle Users and the Roles
granted to those Users would only be those that are necessary to run the application.
Data security will be maintained by constraining the database object by type and range and by restricting
access through Role to only those applications requiring such access. That is applications that require
only read access to tables will only be provided with a role granting ‘Select’ access and not ‘Update’
access.
An Oracle user's system and object privileges will be assigned via roles on a least permissions required
basis. Note that this precludes running batch processes using the schema owner (i.e. OPS$BRDB).
User names and passwords will be protected across the network by using Oracle encryption functionality,
which is the default.
System and DBA access to the Branch Database is by authorised operations staff only.
The Branch Database application creates files containing the day's auditable messages in the directory
pointed to by the environment variable $BRDB_COUNTER_AUDIT_OUTPUT. These files contain
security sensitive data and adequate operational measures must be taken to prevent unauthorised
access to these files and their data.
12.1.2 Oracle Level Security
The following security changes will need to be made as a part of BRDB database creation:
12.1.2.1 Lock and Expire Default User Accounts
All non-business Oracle users created as a part of Oracle installation should be reviewed and the ones
that are not required for the day-to-day running of the database should be locked.
12.1.2.2_ Revoke unnecessary privileges on SYS objects
Privileges on powerful database packages need to be revoked from server user group PUBLIC. Oracle
recommends that privileges on UTL_SMTP, UTL_TCP and UTL_HTTP objects should be revoked from
the PUBLIC user group.
12.1.2.3. Roles and User Accounts
The Branch Database complies with HADDIS standards ([R7]) by providing named roles with
recommended maximum privileges. Assigning unnecessary privileges must be avoided.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 127 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Roles will be granted to users only if a user needs all of the privileges that have been assigned to the
role.
12.1.2.4 Password Policy Settings
Any Oracle / OS level users that are created as a part of the database build will be locked up on creation.
These will be manually unlocked and passwords will be assigned as per the security guidelines set out in
[R23].
12.1.2.5 Enabling Data Dictionary Protection
Data dictionary protection will not be enabled as doing so will impact the process of gathering statistics
which are a part of the Process Auditing feature referred to in the HADDIS standards.
12.1.2.6 Network Access
12.1.2.6.1Listener Administration Control
Prevent online administration by requiring the administrator to have write privileges on the
LISTENER.ORA file and the listener password:
Add or alter the following line to the LISTENER.ORA file
ADMIN_RESTRICTIONS LISTENER_{node_name}=ON
Then RELOAD the configuration.
12.1.3 Application Security
Only batch users and support users can have a presence on the Branch Database host.
Users must not have read-write access to the application executables. The support users must not have
execute privileges on the application executables and batch users must not have read privileges.
As per HADDIS, all application access to the database must use OS-level authentication with the
exception of error logging, where a named user ORAEXCP will be used. This user must have minimum
possible privileges.
12.1.4 Network Security
The Branch Database will reside in its own DMZ and hence be protected by the firewall from any
unauthorized access from the network.
The Branch Access Layer's access to the BRDB nodes will be through Key Management (KMNG),
Agents are through Oracle Wallets, which provide password encapsulation and encryption features.
Refer to [R21] for further details.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 128 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.2 Availability
12.2.1 Targets
Service Level Max downtime core I Percentage
hours per year availability
Outages in Core Hours where the Core Solution (Central & Branch I 11" 99.89568%
Network, Core Infrastructure and Branch Database) is unavailable at
> 10% of Branches per SLT year
Outages in Core Hours where the Banking Solution (CAPO, A&L, I 1'? 99.72181%
Link) is unavailable at > 10% of Branches per SLT year. This
includes time when the Banking Solution is unavailable because the
Core Solution is unavailable.
Outages in Core Hours where Other Services (ETU, DVLA, PAF, I 11% 99.51316%
APOP, DCS) are unavailable at > 10% of Branches per SLT year.
This includes time when the Other Services are unavailable
because the Core Solution is unavailable.
Table 5 — Branch Database Availability Targets
12.2.2 Restart/Recoverability
Process Control supports process restart and recoverability. For more details see Section 7.1.4.
The Restart/Recoverability at database/instance level are discussed in Section 12.6.
12.2.3 Fail-over
The Branch Database runs on the BladeFrame Linux environment. Resilience and fail-over are
implemented using an Oracle Dataguard based standby Branch database and remotely mirrored EMC
file store.
For a detailed discussion of Failure scenarios and failover, refer to Sections 12.6 and 12.7.
12.3 Usability
There is no direct human interaction with the Branch Database other that what may be required for
unplanned maintenance activity.
Any direct user access is strongly discouraged as inappropriate access to data on the branch database
will cause the performance to drop significantly that will most likely result in timeouts at the PO Branches
thus affecting the Branch trading and potentially causing SLT violations.
11 SLT value is 3 hours but 2 of those 3 hours have been allocated to Branch Network (1) and Core
Infrastructure (1)
‘2 Downtime for Core Solution + NPS Database (1) + Firewall Farm (CAPO, A&L, LINK: 1.5) + Service
(CAPO, A&L, LINK: 1.5) + N/W Connection (A&L: 1)
‘3 Downtime for Core Solution & Banking + Firewall Farm (ETU, DCS, DVLA: 1.5) + Service (ETU, DCS,
DVLA, PAF, APOP: 2.5) + NW Connection (ETU, DCS, DVLA: 3) + APOP (2) + PAF (1)
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 129 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.4 Performance
12.4.1 Service-specific Volumes & Throughput
This section lists the service-specific volume and throughput figures. The volumes have been used to
size the database storage objects and the throughput figures have been considered when designing the
structure of the tables and host processes.
Only the most performance intensive services have been listed. All figures have been obtained from the
HNG-X System Qualities Manual [R4]
12.4.1.1 Overall Targets
12.4.1.1.1 Throughput'*
Design limit (Peak 5 minute TPS) Allowance for actual per second peak
1068. 1388
Table 6 - Branch Database Throughput Target
12.4.1.1.2Volumes
Design limit (Peak 5 minute TPS) Allowance for actual per second peak
77,986,779 269,932,941
Table 7 — Branch Database Overall Volumes.
12.4.1.2 Settlements, EPOSS Events and Audit
Service Peakmonth I Peakweek I Peak2 Peak day I Peakhour I Peak 5min
days avg TPS
EPOsS 126,246,451 I 42,383,331 I 18,744,387 I 10,323,021 I 1,476,192 413
APS 48,770,033 I 13,814,266 I 6,751,466 I 3,637,887 673,009 215
NBS 41,040,766 I 11,081,007 I 5,289,984 I 3,064,320 741,888 245
Dcs 5,052,000 I 1,517,721 679,139 346,110 95,242 26
ETU 2,751,844 673,699 256,540 145,440 20,705 6
DVLA 4,757,116 I 2,745,745 I 1,354,513 885,329 122,396 36
PAF 14,363,767 I 4,802,916 I 2,260,397 I 1,320,945 194,695 55
Settlement I 143,557,723 I 43,335,142 I 20,626,183 I 11,479,010 I _ 2,076,311 638
APOP 8,200,000 I 2,050,000 I 1,045,000 660,000 120,000 39
Table 8 — Settlement Transaction Throughput & Volumes
‘4 Although the throughput is expressed as number of transactions, since there will be one commit per
transaction in the Branch Database (with the exception of recoverable transactions such as Banking or
Postal Services, where an exra commit is counted as a separate service). Thus the number of services
match the number of commits.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 130 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.4.1.3 Reporting Transactions
Service Contracted peak I Design limit peak I Live5minavg I Live 5min avg TPS
5 min avg TPS 5 min avg TPS TPS at overall
peak period
Reports 100 120 5 40
Table 9 -Reporting Throughput & Volumes
12.4.1.4 Session Management
Service Contracted peak I Design limit peak I Live 5 min avg Live 5 min avg TPS
5 min avg TPS 5 min avg TPS TPS at overall
peak period
Log On/Off 100 120 5 48
Table 10 - Session Management Throughput & Volumes
12.4.1.5 Recovery Management
Service Contracted peak I Design limit peak I Live 5 min avg Live 5 min avg TPS
5 min avg TPS 5 min avg TPS TPS at overall
peak period
Banking, 2 ? 2 ?
Debit Card,
ETU&
Postal
Services?
Table 11 — Recovery Management Throughput & Volumes
12.4.1.6 Help
Service Contracted peak I Design limit peak I Live 5 min avg Live 5 min avg TPS
5 min avg TPS 5 min avg TPS TPS at overall
peak period
Help Text I 50 60 N/A N/A
Table 12 - Help Service Throughput & Volumes
12.4.2 Response Time Targets
As per [R4], the following response time targets exist. All of the following targets are defined as round trip
times from the counter:
e Network Banking transactions will take on average 2.5 seconds or less within the total of the
HNG-X systems and infrastructure. This is the total time to and from the counter, excluding the
time in the banks' infrastructure and systems.
« Settlements will take on average 2 seconds or less.
¢ No Settlement within the 95" Percentile will take 7 seconds or more.
12.4.3. Batch Job Execution Targets
To ensure that the BRDB batch schedule completes within an expected timeframe, the following targets
on execution time have been defined for a few BRDB Host processes.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 131 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
12.4.3.1 Bulk copy to / from Legacy
The following targets are set for processing days when no transactions fail to be copied across the
interfaces due to data-type / size / format mismatch errors.
Interface Heading
Peak Day/ 2-Day (Design
Interface Transfer Time target
Limits) (elapsed minutes — including all
overheads'5)
EPOS, AP, NWB, DCS, Peak day 60
ETU & Bureau Peak 2 days 90
Transactions and EPOSS
Events to TPS
AP Transactions to APS Peak day 20
Peak 2 days 30.
NWB, DCS & ETU Peak day 30
Transactions to DRS Peak 2 days 45
Cash, PCOL & PDEL Peak day 15
transactions to LFS Peak 2 days 20
Track & Trace to NPS Peak day Within 5 minutes of each
transaction being logged in
BRDB during core hours
Peak 2 days N/A
Guaranteed Reversals to I Peak day Within 3 minutes of each
NPS reversal being logged in BRDB
during core hours
Peak 2 days NA
(Hydra) Peak day 120
EPOS, AP, NWB, DCS,
ETU & Bureau
Transactions from TPS to
BRDB
Peak 2 days 180
(Hydra) Peak day 30
‘Ongoing’ Reconciliation
Totals from TPS to BRDB
Peak 2 days 60
(Hydra) Peak day 30
‘In-day’ feed from TPS to
BRDB
Peak 2 days NA
Table 13 - Bulk Copy Throughputs
The performance targets being set for batch bulk copy processes is that in the worst peak 2 days
scenario, the copy processes should not take more than four hours (240 minutes) to complete.
12.4.3.2 Counter Message Audit File Generation
On a daily basis the BRDB Host applications are required to generate files containing auditable
messages to be copied across to the Audit Server.
15 The elapsed time should measure from the time the job/s are invoked by the scheduler to the time the
control
‘©Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2008
Page No: 132 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Peak Day (design limit) Peak 2 Days (design limit)
File Generation Time target 120 180
(elapsed minutes — including all
overheads)
Table 14 — Audit File Throughputs
The performance targets being set for audit file generation is that in the worst peak 2 days scenario, the
process should not take more than three hours (180 minutes) to complete.
12.4.4 System Performance and Tuning
12.4.4.1. Instance Tuning
Refer to Appendix E — Suggested Oracle Initialisation Parameters for the full list of suggested Oracle
Initialisation Parameters for the Branch Database and the Branch Standby including those required for
instance tuning.
Shared pool for instances should not need to be overly big. Insert statements are relatively simple and
use host variables so once they are read into memory for the first time there should be no further parses
for these statements needed. This leaves memory free for fetches and executions.
12.4.4.2 Database Tuning
Some of the points listed here may have also been covered in relevant sections elsewhere.
Again refer to Appendix E — Suggested Oracle Initialisation Parameters for the full list of suggested
Oracle Initialisation Parameters for the Branch Database and the Branch Standby including those
required for database tuning.
Size of the redo logs is set to 400M each so that at full load the logs fill every 1-1.5 minutes, which
ultimately results in a database checkpoint.
All tablespaces in the database will be locally managed and reside within ASM.
12.4.4.3 Oracle Cost Based Optimisation
As recommended by Oracle, the Oracle Cost Based Optimiser will be used to optimise query
performance. This will require statistics to be generated on a daily basis by a scheduler controlled script.
Both Schema and Dictionary level statistics will be gathered every day. System statistics will be collected
once a week.
Where a BRDB process needs to possibly override the optimiser's execution of a query, hints will be
used to direct the optimiser. These hints will be defined and refined during the development process and
will be stored in the BRDB_SQL_HINTS table.
Please note that Oracle's implementation of Hints has changed from Oracle9i to Oracle10g. With
Oracle10g, the weight associated by the optimiser to a user-supplied hint is much less resulting in a
lesser likelihood of the optimiser actually using the hint.
12.4.4.4 Other considerations
Oracle Database Resource Management (DRM) provides the means for managing and controlling
database resources so that available resources are appropriately allocated to the business critical tasks.
DRM provides the two key features of resource plans and consumer groups.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 133 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The Branch Database will not use either of resource plans or consumer groups due to the operational
performance overhead that they present.
12.5 Backups
This section provides a brief overview of the backup requirements for various components of the Branch
Database system. It is essential for the Branch Database to be available for operational use while the
backups take place.
Each of the sub-topics in the following sections are discussed in the context of the Branch Database only.
The Branch Standby Database backups are discussed in Section 8.3.
12.5.1 OCR and Voting Disk
The OCR (Oracle Cluster Registry) and the Voting Disk files are essential for the running of the Branch
database cluster. Refer to Section 6.3.1 for a brief description of these files.
The OCR file is fairly static and changes only when amended using Server Control (srvctl) commands.
The file resides as a partition in a directory managed by OCFS2 and the size is expected to be less than
100MB. It is sufficient for the OCR file to be backed up on a daily basis alongside the overnight database
backup.
The Voting Disk gets written to and read from very frequently however changes are recorded only in the
event of a cluster-managed service becomes (un) available. The file resides as a partition in a directory
managed by OCFS2 and the size is expected to be around 400MB.
As Oracle only requires a valid Voting Disk file in the correct location regardless of the age of the file for
the RAC to work, it is sufficient for the Voting Disk file to be backed up on a daily basis alongside the
overnight database backup.
The backups of the OCR & Voting Disk must be retained for 7 calendar days.
12.5.2 Configuration Files
12.5.2.1 Initialisation Parameters File
The SPFILE is a binary file containing Oracle initialisation parameters for all four nodes of the cluster.
The file contents rarely change and size is size is expected to be less than 10MB. The file resides in a
directory managed by OCFS2.
It is sufficient for the SPFILE file to be backed up on a daily basis alongside the overnight database
backup. Retention period for the purpose of recovery must be a minimum of 7 calendar days.
12.5.2.2 Local Naming (TNSNAMES)
The TNSNAMES file is a text file containing aliases for all services / instances that the Branch Database
node connects to. File contents rarely change and size is a few KB. The file resides in the RHEL
filesystem formatted directory $ORACLE_HOME/network/admin.
It is sufficient for the TNSNAMES file to be backed up on a daily basis alongside the overnight database
backup. Retention period for the purpose of recovery must be a minimum of 7 calendar days.
12.5.2.3. Listener Configuration
File type, location and backup retention period are same as for TNSNAMES (above).
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 134 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE &
12.5.3 Database Backup
This section covers the backup of database control files, online redo log files, database data files and
archived redo logs.
The use of ASM to manage all data files mandates the use RMAN for performing backups and recovery.
The overall approach is to perform Level-n (full & incremental) hot backups onto ASM diskgroups at both
data centres for resilience.
The reason incremental backups have been chosen is that the size of the database is large (~400GB)
and a full hot backup might take too much time. As the retention period of the largest tables in Branch
database is set to 3 days, it can be said that the database receives roughly a third of its data volumes
every day. A Level-1 incremental backup will reduce the size of the backup set by a third but will also
mean that recovery will take a proportionally longer time as for recovery, the most recent Level-0 backup
will need to be restored and the incremental Level-1 backups applied on top.
Hence the backup approach will take a middle position of taking a full Level-O backup twice a week
(Sunday and Wednesday) and Level-1 (incremental) backup on remaining days.
The following figure presents the daily backup schedule for the Branch Database RMAN backups. The
term LO is used synonymous with Level-0 and L1 is used alongside Level-1.
All backups driven by Oracie RMAN
™~ ‘ASM Diskgroup
rN ‘Sunday I Level —0 Backup oo
Monday Level=1 Backup I
Tuesday I Level — 1 Backup
I Wednesday I Level — 0 Backup
I Week -1 —
I Thursday I Level—1 Backup I AllLO
j 1 Friday lon Backup) Dackups “I~ ASM Diskgroup ASM Diskgroup
id PI written to BROB_BRA_P3_ BRDB_BRA_S3 I)
‘Saturday I Level 1 Backup I BROB_BR — — ~
I Sunday Level=O Backup. APT&
SI — ,
Week -2 ASM Diskgroup ‘ASM Diskgroup :
Saturday [Level — 1 Backup be. es RDB _BRA_S: : storage in
\ ALA Backup sets SREty
1 Sunday ILevel-0 Backup I backups a atchived to
I - - - tape after 7 Tape
\ ra —— days backups
I Week - 3 ASM Diskgroup ‘ASM Diskgroup : retained for
\ Saturday [Level-1Backup+- S2 > \BROB_BRAP2 : : I BRDB BRA S2 Sweeks
I 1 Sunday I Level— 0 Backup : a
BRDB ASM BRDB ASM
I Diskgroups in: Diskgroups in
\ These are based
I Sunday I Level — 0 Backup ‘on class-4 SAN on raid-5 NAS
] storage located in
I Branch Database storage located in REIS
Backup Schedule :
Data retention is7 : Data retention is 7
days days
Figure - 16 BRDB Backup Approach
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 135 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
The backup approach can be summarised as follows:
e Level-0 backups will be taken on all Sundays and Wednesdays. Backups will include control files
and all non-temporary data files. The target locations are ASM diskgroup BRDB_BRA_P1, which
is based on SAN storage and located in the DMX at IRE11 and diskgroup BRDB_BRA_S1, which
is based on NAS storage that is physically located in the DMX array at IRE19 but accessible the
Branch Database nodes in IRE11.
e Level-1 incremental backups will be taken on all other days of the week. Backups will include
control files and all non-temporary data files. The target locations are ASM diskgroup
BRDB_BRA_P2, which is based on SAN storage and located in the DMX at IRE11 and diskgroup
BRDB_BRA_S2, which is based on NAS storage that is physically located in the DMX array at
IRE19 but accessible the Branch Database nodes in IRE11.
e All archived redo log files created since the last LO/L1 backup will be backed up. The source is
ASM diskgroup BRDB_FLASH and the target locations are ASM diskgroup BRDB_BRA_P3,
which is based on SAN storage and located in the DMX at IRE11 and diskgroup BRDB_BRA_S3,
which is based on NAS storage that is physically located in the DMX array at IRE19 but
accessible the Branch Database nodes in IRE11.
e In all of the above cases, the backup sets written to IRE19 can be initiated using a separate
RMAN backup session if it presents a more efficient approach. The Backup High Level Design
[R35] should specify the approach to be taken in this regard.
e Backups need to be taken as ‘backup-sets' (as opposed to image copies), should be compressed
as directed by the Backup design [R35].
e An RMAN catalog should be used to manage the backups. Creation of the catalog is outside the
scope of this design document. Refer to the Backup design [R35] for further details on the RMAN
catalog.
e Naming conventions for backup sets should be as per standard Oracle naming conventions
unless specified by the Backup design [R35].
e RMAN will check for physical block corruptions by default. RMAN should be used to check for
logical block corruptions as a part of the backup operation.
e The Level-1 backups should take no more than 2 hours under normal operational circumstances.
Level-0 backups should take no more than 3 hours. Means for improving efficiency such as
parallelising by use of multiple backup channels should be explored and used if applicable.
e Backup sets should be retained on disk for a minimum of 7 calendar days. After that they should
be archived off to tape where they will be retained for a further 3 weeks period. Either of the
backup diskgroup sets could be used to archive off to tape and the most network efficient means
should be chosen. The tape infrastructure and the procedures used should be as per standard
RMGA practice for HNG-X.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 136 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.6 Failure & Restart/Recovery
This section lists the various Oracle failure scenarios in detail and discusses the action to be taken in
response to each different type of failure.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 137 of 197
FUJITSU
FUJ00235023
FUJ00235023
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
12.6.1
Problem Scenarios & Recovery Options - Summary
Problem Type
Problem Detail
Recovery Action Details
Instance / Node
Failure
A single Branch Database
instance crashes
CRS ability of automatically restarting the failed instance will be disabled. The instance will be ‘logically’ removed from the list of Branch Database
instances that are available for handling Branch requests. This happens automatically by Oracle RAC-FAN utility (BRDBX010),
The failed instance will be automatically added into the list of ‘available’ instances at end of business day. There is an option of manually making the
instance ‘available’ before that and the steps involved in doing that need to be discussed in the support guide.
Refer to Section 12.6.2 for further discussion on this topic.
‘A single Branch Database
Node crashes & restarts
The failure notification will occur via ITM Tivoli agent and via Grid Control (from Oracle perspective).
Bladeframe technology will attempt to automatically restart the failed ‘pserver’ on a different physical blade in the LPAN. Once RHEL4 initialises in the
new blade, the BRDB database instance will automatically start via oratab.
As with single database instance failure, the instance failed node will not be used until end of day.
A single Branch Database
instance crashes but fails to
restart
This is not a valid failure scenario, as the Branch Database instances are not restarted on failure. This problem option has been included for
completeness
A single Branch Database
Node crashes but fails to
restart
The failure notification will occur via ITM Tivoli agent and via Grid Control (from Oracle perspective).
If Bladeframe cannot automatically restart the failed ‘pserver’ on a different physical blade in the LPAN, it will flag an error via the PAN manager and
support can follow it up.
As with single database instance failure, the BAL / Branch Database host will not attempt to use the database instance that was running before the
node failed until end of day or when the node starts, whichever occurs later.
Two or more instances of the
Branch Database crash
Automatic restart by CRS has been disabled.
The Oracle RAC-FAN utility (BRDBX010) will have automatically ‘voted-out' the failed instances logically.
Instances need to be manually restarted. Once the instances restart and if no further problems are encountered, support should manually make the
instances logically ‘available’ to accept counter requests, as per instructions in the Branch Database support guide.
However if the instances that have come back up present further problems e.g. network issues, then the instances should be treated as non-
restartable and the recovery action for that failure scenario should be followed.
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020.
Version: V1.0
Date: 17-Nov-2009
Page No: 138 of 197
FUJITSU
FUJ00235023
FUJ00235023
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
Problem Type
Problem Detail
Recovery Action Details
Two or more — Branch
Database Nodes crash &
restart
The failure notification will occur via ITM Tivoli agent and via Grid Control (from Oracle perspective).
Bladeframe technology will attempt to automatically restart the failed pservers on the same / different physical blade in the LPAN as defined by the
LPAN configuration.
If the pserver can be restarted and RHEL4 can start without any issues, the recovery actions for Branch Database instance crash & successful restart
(see above) should be followed.
If the pserver / RHEL4 cannot be restarted, the recovery actions for node failure of two or more nodes with no subsequent restart (see below) need to
be followed.
Two or more instances of the
Branch Database crash but
fail to restart
This scenario is a continuation from the previous problem
A manual restart of the failed instances does not resolve the issue, the recommended resolution option should be failover to BRDB-Standby. If the
failure occurs during core business hours, it is more advantageous to attempt a failover. Whereas if the problem occurs outside of core business
hours and at least two branch database nodes are available, these may be sufficient to support the reduced business traffic. In such cases it may be
beneficial to carry on using BRDB to support the reduced business while attempting to fix the problem and restart the failed nodes before start of core
business hours.
Any failover to BRDB-Standby should always be manually initiated and after consultation with Service-delivery as will be outlined in the Support
Guide.
Refer to Section 8.4.2 for detailed discussion on the failover to BRDB-Standby.
Two or mode — Branch
Database nodes crash but fail
to restart
If the Bladeframe PAN manager cannot automatically restart the failed blades, either on the same or alternate pblades, an error will be flagged and
support will need to investigate.
The recommended resolution action is for the Branch Database to switch to BRDB-Standby platform. Failover will be manually initiated and will need
to follow the steps outlined in Section 8.4.2.
Media Failure
Alertlogs, RMAN — backup
(check logical), dbv, Grid
Control detects a corrupt block
If the block corruption results in a node / database failure, as may be expected if the corruption affects the data dictionary in the system tablespace or
the online-redo logs, the resolution options discussed as a part of Instance failure (above) should be followed.
If the block corruption does not result in a node / instance failure, block recovery using RMAN “blockrecover” command should be attempted. Block-
recovery will make use of the backup sets to recover the last known image of the block and any changes made using the archived and online redo
logs.
The monitoring / verification
tools detect a data file
corruption
As discussed for block corruption above, if the file corruption results in database instance/s failure, the resolution options discussed as a part of
Instance failure (above) should be followed.
If the file corruption does not result in a node / instance failure, the corrupt file and its contents can be recovered by standard RMAN recovery options.
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020.
Version: V1.0
Date: 17-Nov-2009
Page No: 139 of 197
FUJITSU
FUJ00235023
FUJ00235023
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
Problem Type _I Problem Detail Recovery Action Details
The monitoring / verification I The Branch Database writes archived redo log files to two different locations and each location resides in a separate EMC DMX. This makes the
tools detect a data file I possibility of redo-log corruptions due to hardwate issues unlikely. There is relatively a greater chance of redo logs being corrupt due to a logical
corruption along -—_with I corruption in the Oracle / EMC buffers. However such corruptions will be detected quickly by the Data Guard physical standby replication. Hence the
corruption of online / archived
redo log files
potential of data loss in the event of such a corruption is low.
As discussed before, if such a corruption results in database instance/s failure, failover to BRDB-Standby should be considered. If database instances
do not fail, RMAN-based database point-in-time recovery should be performed
Refer to Section 8.4.2 for detailed discussion on the failover to BRDB-Standby.
The monitoring / verification
tools detect a corruption of the
database control file
This will most likely result in a database failure, as the corruption will be replicated across all copies of the control file.
Although recovery is a straightforward"® process, itis recommended that the Branch Database service switch to BRDB-Standby
The Voting / OCR disks get
corrupted
This will most likely result in a database failure along with all other Oracle cluster services. These files are small in size and change infrequently
hence are backed up daily. They should be restored and the cluster should be restarted. If the cluster fails to start, a switch to standby should be
considered.
Network Network slows down which I There are two options available: Stay on the BRDB cluster while the problem is resolved or switch to BRDB-Standby. The decision to do either should
Problems results in Counter requests I be made in consultation” with Linux Support & CS
timing out
User Errors User inadvertently drops a I The dropped table can be recovered using standard RMAN backup recovery procedures. RMAN will need access to the most recent Level-0 backup
table
and all subsequent Level-1 backups along with copies of archived redo log files since the Level-0 backup.
Refer to section 12.5 for details on the location and retention period of the various backup components.
Problem Scenarios & Recovery Options - Summary
16 Recovery steps are: restore a previous backup of the control file and apply any file-level changes made since then and manually add any temporary files i.e.
temporary tablespaces. Perform full RMAN database recovery to bring the restored control file in line with the change numbers in the data files.
‘7 As there are a number of variables such as extent of the network issue, time when the problem occurs etc, design cannot provide any meaningful input into the
decision-making.
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020.
Version: V1.0
Date: 17-Nov-2009
Page No: 140 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.6.2 Instance Failure
An Instance failure occurs when software or hardware problems disable an instance. After instance
failure, the CRS daemon automatically attempts to restart the failed instance. This facility needs to be
disabled.
The reason for doing so is that if an instance fails in a RAC environment, the SMON process in available
instances will automatically perform instance recovery on behalf of the failed instance. The combination
of Oracle FAN (see Section 7.2.10) and a connection re-attempt by the Branch Access Layer will quickly
redirect traffic to the available instances through the use of the brdb_operational_instances mapping
table. If the failed instance was restarted soon afterwards, that instance would not get any traffic going to
it at all. In such cases Oracle attempts a very basic form of load balancing such as transferring ownership
of 1/4" of the blocks in use in the cluster to the restarted instance which will result in performance
degradation as has already been proven in prototyping.
The Branch DB architecture [R3] suggests that a BRDB cluster running 3 nodes will be able to handle the
Branch traffic without any drop in performance. Hence the failed node will remain down until a restart is
manually initiated by support at non-busy time in the processing day.
12.6.3 Media Failure
A media failure is a physical problem that arises when Oracle tries to write or read a file that is required to
operate the database. An example is disk head crash causing loss of all data on a disk.
All Branch database components essential for the operation of the database will reside on SRDF
replicated Raid-1 disks. SRDF will ensure that every byte saved to the disk on the local (primary) site is
synchronously replicated and saved to the secondary (DR) site before a positive response is returned
back to the OS or disk management software such as ASM.
RAID-1 technology ensures that every byte of data written is mirrored on an erstwhile location in the disk
array so even if a disk in the disk array were to fail, there will be no data loss.
The combination of SRDF and RAID-1 ensure that the possibility of media failure is greatly minimised.
The Oracle database will be running in archivelog mode and the archived redo logs are copied across to
multiple locations so even if a media failure were to occur, provided the archived redo logs are
accessible, a straightforward database point in time recovery will ensure that there is no data loss.
12.6.4 Block Corruptions
A block corruption is said to occur when Oracle detects that the block wrapper (block header & footer) of
one or more blocks is corrupt/invalid.
Once Oracle detects a corrupt block, it writes the following error message to the alert log for the instance
that detects the corruption:
ORA-01578: ORACLE data block corrupted (file # %s, block # %s)
Where file# is the file ID of the Oracle datafile and block# is the block number, in Oracle blocks,
within that file.
Any potential downtime is dependent on how quickly block corruptions are detected.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 141 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.6.4.1 Detecting Block Corruptions
An Oracle error #1578 does not always mean that the block on disk is truly physically corrupt as the error
message might just be indicating that there is a corruption in the cache. A number of means are available
to verify that the block on disk is corrupted (either physically or logically):
Block Corruption Detection mechanisms to be used
» DB_BLOCK_CHECKSUM parameter
DB_BLOCK_CHECKSUM determines whether DBWn and the direct loader will calculate a
checksum (a number calculated from all the bytes stored in the block) and store it in the cache
header of every data block when writing it to disk. This allows Oracle to detect block corruptions
whenever the block is read. If the block is corrupted, error messages are written to the alert log
but processes may not necessary fail.
This parameter will be set to TRUE (default) for the Branch Database.
>» RMAN
RMAN can detect both logical and physical corruptions when performing backups by using the
“BACKUP VALIDATE” command:
BACKUP VALIDATS CHECK LOGICAL DATABASE ARCHIVELOG ALL;
Each new corrupt block is recorded in the control file and in the alert-log. The Oracle view
V$DATABASE_BLOCK_CORRUPTION provides a list of all corrupt blocks and indicates whether
the corruption is logical or physical.
RMAN will be used to detect logical and physical block corruptions through the entire Branch
Database.
> Oracle Alert-Log
Oracle records any block corruption errors that it detects in the alert log. Since corruptions may
not necessarily cause the Instance or processes to fail, these errors may go un-noticed. However
the HNG-X Solution provides for a centralised Enterprise Manager Grid Control based Monitoring
setup, which will be used to monitor errors in the Alert log. Refer to
» DB_BLOCK_CHECKING parameter
Setting this initialisation parameter to TRUE causes Oracle to proactively check for corruptions
and hence aid early detection. There is an overhead of between 1% and 10% associated with
this, which is unacceptable for the Branch Database. If block corruptions occur more frequently
this parameter can be reviewed.
The Branch Database will be delivered with this parameter value set as FALSE.
>» Corruption Detection SQL & DB-Verify
Corruptions can be detected at object-level by using the SQL “ANALYZE TABLE...VALIDATE
STRUCTURE...” and the db-verify utility to detect corruptions in data files.
Since the Branch Database will use RMAN to detect logical corruptions, the corruption detection
SQL and DB-Verify need not be used for Branch Database.
The Branch Database will make use of Oracle Dataguard to maintain the BRDB-standby database.
Dataguard transparently detects corruptions and ensures that the corrupted blocks are not replicated to
the standby database. Corruptions detected can be flagged to support via EM Grid Control.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 142 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
12.6.4.2 Recovering from Block Corruptions
Once block corruption has been detected, the key task is to recover lost data. There are four options
available for recovering data in the Branch Database:
» Use application-specific means of restoring data.
» Switch to using the BRDB-standby database
>» Restore from backups and recover using the archived redo-logs
» Restore from Oracle export files
Oracle block corruption will occur on all mirrored copies of the disk, both locally and at the remote DR
site, so failing over to DR is not an appropriate recovery method.
Index block corruptions are best resolved by rebuilding the index. There may be a performance impact of
rebuilding and recommendations about time of rebuilding have been made in the later sections.
The appropriate recovery option to choose will depend on the type and criticality of the object being
recovered and also whether the corrupted information has been consumed by all consumer systems. The
following section categorises the Branch Database objects and discusses recovery options for each
category:
12.7 Switch to BRDB-Standby
For detailed discussion on this topic, refer to Section 8.4.
12.8 Potential for Change
See the Changes Expected section 0.7.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 143 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
13 Implementation
13.1 Summary
The Branch Database environment will consist of a number of components. Some of these will need to
be in place well in advance of the beginning of pilot. This will allow enough time for configuring the
storage and network components and testing of the same.
13.2 Delivery Units
Branch Database system delivery will be divided into a number of logically related delivery units. Each
delivery unit may be further sub divided into one or more work packages. Work packages for subsequent
delivery units should follow work packages for preceding delivery units.
Delivery Unit 1 will contain the scripts/instructions to create ASM instances named “+ASM1...4” on the
new BRDB-Host (x4). It will also create the ASM disk groups (as defined in section 6.2.3). It will also
include the configuration changes to allow the ASM instance to accept connections across TCP/IP.
Work packages associated with this delivery unit will typically be applied to the live estate well in advance
of the pilot.
Delivery Unit 2 will contain the scripts/instructions to create all relevant Linux users, profiles,
environment variables and the required OS directories. This delivery unit will also contain the scripts to
create a 4-node clustered database for BRDB (non-clustered for test) along with tablespace definitions.
Additionally the delivery unit will contain the Oracle network configuration changes to allow the BRDB
instances to accept connections across TCP/IP.
Refer to sections 6.3.3 through to 6.3.8, 6.4 and 6.5 for more details.
Work packages associated with this delivery unit will typically be applied to the live estate well in advance
of the pilot but will follow Delivery Unit 1.
Delivery Unit 3 will provide the scripts to build the BRDB application schema objects such as tables,
views etc and PL/SQL based application deliverables. It will also deliver metadata, static reference data
and other related deliverables.
Additionally this delivery unit will define the rules for data capture and propagation to the BRSS using
Streams and the configuration changes for setting up a database level data capture and propagation to
BRDB-standby via DataGuard.
This delivery unit will also provide the application executables, shell scripts and execution environment
for the Branch Database host processes. Refer to Section 6.3.10, 6.3.11 and 6.4.3 for more details.
Work packages associated with this delivery unit will typically be applied to the live estate in advance of
the pilot but will follow Delivery Unit 2.
Delivery Unit 4 will provide the TWS execution environment and the BRDB-Host schedule definition for
running the Branch Database batch schedule.
Refer to [R12] for more details on BRDB job scheduling.
Work packages associated with this delivery unit should be applied to the live estate in advance of the
pilot but the schedule should remain deactivated.
Delivery Unit 5 will create the BRDB-Standby environment including the ASM instance, the clustered
single-node database along with the necessary configuration changes for running the BRDB-standby
database in physical standby mode.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 144 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
Delivery Unit 6 will prime the database objects and metadata for the first day of the BRDB-Host batch
schedule. This includes creating partitions for days D and D + 1, prepping the database with up to date
reference data and applying any changes to the Branches — Fad-Hash mappings.
Work packages associated with this delivery unit will be applied to the live estate on the day prior to
running the TWS schedule (see Delivery Unit 4).
Note that the enabling of data capture and propagation via Streams to the BRSS and via DataGuard to
BRDB-Standby should be done via additional work packages.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 145 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
14 Application Development
All application development must follow the guidelines set out in [R7].
As a minimum, the following low-level design documents will be produced. It is acceptable to produce
more low-level designs documents if needed for improving clarity and for a more detailed coverage.
e Database and Schema Build (including setting up the ASM disk groups)
Start of Day (Application BRDBC001)
* Audit-Store Auditing (BRDBC002)
« Common Legacy Host Interface (BRDBX003)
* Audit, Archive & DB-copy (Application BRDBC004)
* Gathering Optimiser Statistics (BRDBX005)
«File Housekeeping (BRDBX006)
« Data Aggregation Tool (BRDBX007)
* Check Job Completion (BRDBC008)
« End Of Day (BRDBC009)
* Detect and Report Node Failures using FAN (BRDBX010 Fan event)
« Update System Parameters (BRDBX011),
« SSC Transaction Correction Tool (BRDBX015)
e BRDB File Transfer to DWh (BRDBX020)
« Pause / Start Streams Replication (BRDBX021)
« Maintain JSN SSN USN (BRDBX031)
e Hydra specific XML Data Processor (BRDBX030 & BRDBX033 & BRDBX034)
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 146 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
15 Testing and Validation
This section lists some of the important areas to focus on in the Branch Database system from a test
perspective. There is no distinction made in the areas to focus on for different types of testing. It is left to
the test designer to decide upon which test environment is best suited for each focus area.
Application Components
e Ensure that the BRDB Start-of-Day process creates new partitions one day in advance for all
transactional and event tables. Also ensure that old partitions are being housekept in order to
conserve space.
e The BRDB feed for Audit Server must contain all auditable messages logged by the BAL in the
BRDB during a calendar day on behalf of the Counter.
Integration
e Ensure that the Branch Access Layer (BAL) can access all four nodes of the Branch Database
(BRDB).
* The BAL access of BRDB for outlet specific data should always be a ‘Fad-Hash’ aware access.
Refer to section 5.1 for accessing data in a Fad-Hash aware manner.
ef a Branch Database node fails, the BAL should use an alternate (metadata-defined) node for
accessing the database. BRDB node failure should not result in a transaction failure at the
Counter.
e Ensure that all BRDB — Batch application batch data feeds can restart from logical start point
prior to the failure such that they minimise the re-work required on a restart. With the exception of
erroneous records, which should be accounted for as exceptions, there should be no data loss in
the dataset that reaches the target database.
Performance & Volume
e Peak transaction throughputs must be tested using an adequately simulated test environment.
¢ BRDB must be able to notify of node failures to all consumer applications by changing the Fad-
Hash mapping metadata.
e The audit-store audit file generation needs to complete within the time limits specified.
Business Continuity Testing
e Data replication to the Branch Support System must not lose data.
e Data replication to the Branch Standby Database must not lose data.
« Database backups (both level — 0 and level — 1) must be adequately tested for data integrity and
backup performance.
e Recovery of BRDB using database backups must be tested.
e Block corruptions must be simulated where possible and the actions to be taken in the event of
block corruptions such as switchover to the BRDB-standby database must be tested. Refer to
Section 12.6.4 for discussions around the different types of data affected by block corruptions
and the recovery actions to be taken for each type.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 147 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
16 Risks and Assumptions
Risks and assumptions have been covered in section 1.4.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 148 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
17 Requirements Traceability
The SRS for this topic architecture captures incoming requirements. The requirements system has a
skeleton copy of the document (section numbers only). The skeleton document identifies the section
where the requirement is being addressed.
Section will be updated to reference the document once it is published.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 149 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
18 Appendix A -— Table and Index Definitions
Table and index definitions for Branch Database will be in [R36]:
18.1 Live Schema objects shared with Training
The following tables will reside in the “Live” schema but will be shared with the “Training” schema by the
use of public synonyms:
IBRDB_ANALYZED_OBJECTS
IBRDB_ARCHIVED_TABLES
IBRDB_BRANCH_ROLES
IBRDB_BRANCH_ROLE_SERVICES
IBRDB_EXCEPTION_CODES
IBRDB_FAD_HASH_INSTANCE_MAPPING
IBRDB_FAD_HASH_OUTLET_MAPPING
IBRDB_FAD_HASH_VALUES
IBRDB_FILES_TO_HOUSEKEEP
IBRDB_HOST_INTERFACES
IBRDB_LOCAL_APP_INTERESTS
IBRDB_ORACLE_ERROR_CODES.
IBRDB_PARTITIONED_INDEXES
IBRDB_PARTITIONED_TABLES
IBRDB_PARTITION_CREATES
IBRDB_PARTITION_STATUS_HISTORY
IBRDB_PROCESSES
IBRDB_PROCESS_AUDIT
IBRDB_PROCESS_CONTROL
IBRDB_SQL_HINTS
IBRDB_SUBPARTITION_RANGES
IBRDB_SYSTEM_PARAMETERS
IBRDB_TABLE_GROUPS.
IBRDB_TABLE_PARTITIONS
IRDDS_ACCOUNTING_NODES
IRDDS_BRANCH_OPENING_PERIODS
IRDDS_DELIVERY
IRDDS_DELIVERY_TYPE
IRDDS_DESKTOP_MEMO.
IRDDS_DESKTOP_MEMO_DISTR
IRDDS_PACKAGE
RDDS_PACKAGE_CONTENT
IRDDS_PACKAGE_TYPE
IRDDS_PRODUCTS
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 150 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
19 Appendix B — View Definitions
View definitions for Branch Database will be in [R36]
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 151 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
20 Appendix C — User, Role Sequence Definitions
and Database Links
20.1 Linux User Definitions
User Name Groups Description
pathway User owns the Branch Database “Live” schema, application executables
and the business data on file-system
pathway User owns the Branch Database training schema, application executables
and the business data on file-system
pathway Use for the BRDBX015 transaction support tool
H 4
E IRRELEVANT II 22 oinstall Owner of the Oracle installation on the Branch Database Nodes 1
pathway Users used fo run batch jobs on the BRDB-Hosts. Wherever BRDB is
accessed, the users connect to the Live BRDB schema.
pathway Generic reports user
20.2 Oracle User Definitions
20.2.1 Schema Owner
Default Temp
User Name Tablespace Tablespace Roles Granted I Privs Granted Description
OPS$BRDB- USERS BRDB_TEMP1 CONNECT, SELECT ANY I User owns all Branch
RESOURCE DICTIONARY, I Database live schema
Role DBA I CREATE_TABL I °biects.
granted only for I E,
the duration of
execution of the I CREATE_VIEW
schema build
scripts.
EMDB_USERS
OMDB_USERS.
TWS_USERS
Above 3 with
grant option
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2008
Page No: 152 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
schema build
scripts.
Default Temp
User Name Tablespace I Tablespace I Roles Granted I Privs Granted Description
OPSSBRDBTR I USERS BRDB_TEMP2 I CONNECT, SELECT ANY I User owns all Branch
RESOURCERo! I DICTIONARY, I Database training schema
@ DBA granted SQL92_SECURITY being
ly for the
o SELECT _, I set then any object owned
uration Of I DELETE == On
eee of the by a diferent user, which
ops$brdb.brdb_ I this is user has DELETE
branch_users,
brdb_branch_us
er_roles,
brdb_branch_us
er_sassions,
brdb_branch_us
er_last_logon,
privilege also needs
SELECT privileges.
brdb_password_
history.
Update on
ops$brdb.brdb_
branch_users.
Select on
ops$brdb.brdb_
branch_info.
20.2.2 Branch Access Layer
Default Temp Privs
User Name Tablespace Tablespace Roles Granted I Granted Description
USERS BRDB_TEMP1 BALLVROLE Used by the Branch Access
Layer to connect to the live
USERS BRDB_TEMPt schema in the branch
USERS BRDB_TEMP2 database
USERS BRDB_TEMP3
USERS BRDB_TEMP4
USERS BRDB_TEMP1 I BALTRROLE, Used by the Branch Access
f DELTRROLE Layer to connect to the
IRRELEVANT I I USERS BRDB_TEMP1 training schema in the
I I USERS BRDB_TEMP2 branch database
USERS BRDB_TEMP3
I I USERS BRDB_TEMP4
USERS BRDB_TEMP: DELTRROLE Used by the Branch
Access Layer to delete
training in the branch
a database
20.23 Batch Processes
Default Temp Privs
User Name Tablespace Tablespace Roles Granted I Granted Description
OPS$BRDBBLV1 USERS BRDB_TEMP1 BATCHLVROLE Used by BRDB host-based
batch processes to connect
OPS$BRDBBLV2 USERS BRDB_TEMP2 to the Live schema
OPS$BRDBBLV3 USERS BRDB_TEMP3
OPSSBRDBBLV4 USERS BRDB_TEMP4
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref DESTAPP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 153 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Default Temp Privs
User Name Tablespace Tablespace Roles Granted I Granted Description
20.2.4 Performance Monitoring
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
OPS$METRON USERS BRDB_TEMP1 I CONNECT SELECT I Used by the Metron
ANY performance monitoring tool
DICTIONA I to gather database statistics
RY on the Live schema only.
20.2.5 Application Exceptions
Default Temp Privs
User Name Tablespace I Tablespace Roles Granted I Granted Description
ORAEXCPLV USERS BRDB_TEMP4 BRDB_EXCEPTIO Used to make concurrent /
NSLV asynchronous connections
to the Oracle database to
log operational exceptions
from within batch processes.
Connect to the Live
schema.
APP_MONITOR_US I USERS BRDB_TEMP1 I APP_MONITOR I Select on I User is used by the ITM and
ER CONNECT ops$brdb. I Oracle Application Express
brdb_exce I to connect to the BRDB
ption_cod I database and fetch details
es, about operational exceptions
opsSbrdb. I in the Live schema
brdb_oper
ational_ex
ceptions
20.2.6 First Line Support
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
User-specific. USERS BRDB_TEMP2 DB_MONITOR Used by the Helpdesk/ISD
" (1 line) users
Optionally
UNXADM but
always done
manually.
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 154 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
20.2.7 Second Line Support
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
User-specific. USERS BRDB_TEMP2 I SMC Used by the SMC (2" line)
users
20.2.8 Third Line Support
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
User-specific. BRDB_SSC_ I BRDB_TEMP2 I SSC EXECUTE I Used by the SSC (3” line)
DATA Optionally privilege users
APPSUP but I 07
always done I pkg_brdb_
manually. txn_correc.
tion
SELECT
on
ops$brdb.
brdb_bran
ch_info
20.2.9 Audit Access
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
AUDITUSER USERS BRDB_TEMP3 AUDITOR, Used by the Audit users to
query BRDB for Fad-Hash
mappings and running
relevant audit-specific
queries on the Live
Schema.
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 155 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
20.210 Support Correction Tool Owner
Default Temp Roles
User Name Tablespace Tablespace Granted Privs Granted Description
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2008
Page No: 156 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
ed
Default
UserName I Tablespace
Temp
Tablespace
Roles
Granted
Privs Granted
Description
OPS$SUPPORT
TOOLUSER
USERS
BRDB_TEMP
4
CONNE
cT,
BALLVR
OLE
Select/insert/Update privileges on
BRDB_TXN_CORR_TOOL_CTL
BRDB_TXN_CORR_TOOL_JOURNAL
BRDB_PROCESS_AUDIT
BRDB_OPERATIONAL_EXCEPTIONS
Insert privilege on
BRDB_RX_APS_TRANSACTIONS
BRDB_RX_BUREAU_TRANSACTIONS
BRDB_RX_EPOSS_EVENTS
BRDB_RX_EPOSS_TRANSACTIONS
BRDB_RX_NWB_TRANSACTIONS
BRDB_RX_REP_SESSION_DATA
BRDB_RX_DCS_TRANSACTIONS
BRDB_RX_REP_EVENT_DATA
BRDB_RX_CUT_OFF_SUMMARIES
Select privilege on
BRDB_SYSTEM_PARAMETERS
BRDB_FAD_HASH_OUTLET_MAPPING
BRDB_FAD_HASH_CURRENT_INSTANC.
E
BRDB_BRANCH_INFO
BRDB_PROC_AUD_SEQ
BRDB_OPER_EXCP_SEQ
Execute privilege on
PKG_BRDB_COMMON
PKG_BRDB_EXCEPTION
PKG_BRDB_FEED_COMMON
SYS.UTL_FILE
Read privilege on
BRDBX015_DIR
User owns the
PL/SQL
packagels that
are used to
insert
balancing /
correction
transactions
into the
Branch
Database.
SCopyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE,
Ref.
Version: V1.0
Date:
Page No:
DES/APP/HLD/0020
17-Nov-2009
157 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE
Default Temp Roles
User Name Tablespace I Tablespace I Granted Privs Granted Description
202.11 Software Administrator Accounts
Default Temp
User Name Tablespace Tablespace Roles Granted Privs Granted Description
STRADMIN BRDB_STRE BRDB_TEMP4 CONNECT Administrator account
‘AMS_DATA RESOURCE ALTER ANY I for managing the
RULE streams capture and
DBA propagate functions.
SELECT_CATA Ae ser ANY
LOG_ROLE
CREATE ANY
RULE
CREATE ANY
RULE SET
CREATE
EVALUATION
CONTEXT
CREATE RULE
CREATE RULE
SET
DEQUEUE ANY
QUEUE
ENQUEUE ANY
QUEUE
EXECUTE ANY
RULE
EXECUTE ANY
RULE SET
MANAGE ANY
QUEUE
RESTRICTED
SESSION
SELECT ANY
DICTIONARY
UNLIMITED
TABLESPACE
20.212 Batch Applications Interface Users
Default Temp
User Name Tablespace Tablespace Roles Granted Privs Granted Description
BRDBRDDS USERS BRDB_TEMP1 RDDS_USERS User used by the RDDS
interface to copy data
out of the Branch
Database
BRDBRDMC USERS BRDB_TEMP2 RDMC_USERS User used by the RDMC
interface to copy data
out of the Branch
Database
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 158 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Default Temp
User Name Tablespace Tablespace Roles Granted Privs Granted Description
EMDB_SUP- USERS BRDB_TEMP2 EMDB_USERS SELECT on I User used by EMDB to
ops$brdb.brdb_ I maintain EMDB tables
branch_info. for BRDB Estate
ops$brdb.brdb__ I Management
branch_node_nf
°
ops$brdb.rdds_b
ranch_opening_
periods
CREATE VIEW
OMDBUSER USERS BRDB_TEMP4 OMDB_USERS User is used by the
OMDB (SYSMAN) to
read PONR for HNG-X
Branch Migration
20.213 Tivoli Workload Scheduler
Default Temp Privs
User Name Tablespace Tablespace Roles Granted Granted Description
TwS USERS BRDB_TEMP1 TWS_USERS User is used by the TWS
Scheduling solution
20.3 Oracle Role Def
initions
Role Name Roles Object & System Privileges Granted Description
Granted
BRDB_EXCEPTIO I CONNECT SELECT, UPDATE, INSERT —_ON I Branch Database Exception Recording
NSLV ops$brdb.brdb_operational_exceptions Role (for
SELECT ON
ops$brdb.brdb_exception_codes
SELECT ON
ops$brdb. brdb_oper_excp_seq
SELECT, UPDATE ON __ opsS$brdb.
brdb_operational_instances
BALLVROLE CONNECT SELECT on all OPS$BRDB sequences. Role assigned to all users used by the
SELECT_CATA I SELECT on all non-working OPS$BRDB Branch Access Layar to connect to the
LOG_ROLE tables and views live schema
INSERT, UPDATE on all non-working
OPSSBRDB tables
DELETE on _brdb_branch_decl item,
brdb_ps_barcodes
BALTRROLE CONNECT SELECT, INSERT, UPDATE ON ALL TABLES I Role assigned to all users used by the
OWNED BY OPS$BRDBTR Branch Access Layer to connect to the
SELECT_CATA Gaining coher
LOG_ROLE SELECT ON ALL SEQUENCES OWNED By I Halting schema
OPSSBRDBTR
DELETE on
opsSbrdbtr.brdb_branch_decI_item,
opsSbrdbtr.brdb_ps_barcodes
‘©Copyright Fujitsu Servic
es Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE, Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 159 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Role Name Roles Object & System Privileges Granted Description
Granted
SELECT ANY SEQUENCE
INSERT,UPDATE on
ops$brdb.brdb_branch_node_info
ops$brdb.brdb_branch_users,
ops$brdb.brdb_branch_user_sessions
ops$brdb.brdb_branch_user_roles
ops$brdb.brdb_branch_user_last_logon
ops$brdb.brdb_password_history
ops$brdb.rd_package_delivery
ops$brdb.rdds_checksum
BATCHLVROLE I CONNECT SELECTINSERTUPDATE,DELETE on I Role assigned to all users that are used
EXP FULL DA. I WKG_BRDB_JSN_USN_SSN to execute BRDB batch jobs against the
ee i Live schema
TABASE Select on non-working OPS$BRDB I ==
AUDITOR tables
Insert on all_non-working OPS$BRDB
tables
DELETE on tables which are purged by the
archive routine.
UPDATE on
brdb_bal_sql_definition_list, brdb_partitioned
_tables, brdb_sub_partition_ranges,
brdb_system_parameters,
brdb_process_control,
brdb_partition_creates,
brdb_tt_transactions, brdb_c0_reversals
SELECT on OPS$BRDB views.
SELECT on OPS$BRDB sequences
EXECUTE on _fn_compress_4 to 3,
pkg_brdb_common,
pkg_brdb_data_aggregation,
pkg_brdb_exception,
pkg_brdb_feed_common,
pkg_brdb_hydra_inday,
pkg_brdb_hydra_recon, _pkg_brdb_optimiser,
pkg_parfition_utils, wkg_truncate_for_x031
APPSUP CONNECT All System privileges that belong to the DBA I Role has been defined for use by ISD
role. Support which will act as first line
RESOURCE support team for the Branch Database
AUDITOR MONITOR SELECT ON Role defined for use by
CONNECT sys.aud$ Internal/External auditors of the system
The role has access to the live schema
ops$brdb.brdb_fad_hash_outlet_mapping I only
ops$brdb.brdb_branch_info
APP_MONITOR I CONNECT Role has been granted to
RESOURCE "APP_MONITOR_USER” in order to
support the application exception
monitoring using ITM and Oracle
Application Express products.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 160 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Role Name Roles Object & System Privileges Granted Description
Granted
Monitoring is provided for the Live
schema only.
DB_MONITOR I CONNECT SELECT ANY TABLE Role has been defined for use by ISD
EXP_FULL_DA I SELECT ANY DICTIONARY Support which will act as first line
TABASE support team for the Branch Database
EMDB_USERS I CONNECT SELECT, INSERT,UPDATE, DELETE on I Role used by the EMDB — BRDB
ops$brdb.emdb_managed_node, Interface which provides the BRDB with
opsSbrdb.emdb post office the EM view of branch and counter
MONITOR CONNECT SELECT ANY TABLE Role made available for all users that
require query-only access to the system
OMDB_USERS I CONNECT SELECT, INSERT ‘ON I Role used by the OMDB - BRDB
ops$brdb.brdb_branch_info, interface which provides the SYSMAN
with PONR for migrating Branches.
RDDS_USERS I CONNECT SELECT ON opsSbrdb.brdb_branch_info, I Role used by RDDS host applications
to read data from the Branch Database.
RDMC_USERS I CONNECT SELECT ON opsSbrdb.brdb_branch_info, _ I Role used by RDMC host applications
to read data from the Branch Database.
GEN_REPORTS I RESOURCE I SELECT on __opsSbrdb__tables I Generic reporting tool role
gen_rep_report_definitions,
gen_rep_report sections,
gen_rep_report_views.
SELECT/INSERT/DELETE on
gen_rep_report_parameters
SECURITY_MAN I CONNECT CREATE USER Role has been defined for use by
AGER GRANT ANY ROLE support staff who are authorised to
administer support users and to
SELECT ANY TABLE investigate security breaches.
DROP USER
ALTER USER
SMC MONITOR SELECT ANY DICTIONARY Role has been defined for use by SMC
Support which will act as second line
support team for the Branch Database
ssc MONITOR SELECT ANY DICTIONARY Role has been defined for use by SSC
(EDSC) Support which will act as third
RESOURCE line support team for the Branch
Database
DELTRROLE CONNECT EXECUTE on opsSbrdbtr. I Role is assigned to user responsible for
SELECT CATA I Pka_bal_training data the deleting training data
LOG_ROLE
SELECT ANY SEQUENCE
TWS_USERS CREATE SELECT on I Role is assigned to TWS_USER to
SESSION ops$brdb.brdb_operational_inst determine the status of BRDB
instances for batch job scheduling
UNXADM CONNECT Role has been defined for use by ISD
Support which will act as third line
RESOURCE (DBA) support team for the Branch
DBA Database
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref DESAPPIALD (0020
Version: V1.0
Date 17-Nov-2009
Page No: 161 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
20.4 Sequence Definitions
20.5 Database Links
Link Name Is Public? Username & Initial Password Connect String
RDDS Y RDDS
APS Y 1] APS
DRSNWB Y DRS
DRSEFT Y {I DRS
TPS Y TPS
LFS Y i] LFS
NPSTT1 Y NPSSERVICE1_2
NPSTT2 Y 1] NPSSERVICE1_2
NPSTT3 Y {I NPSSERVICE1_2
IRRELEVANT
NPSTT4 Y {I NPSSERVICE1_2
NPSGREV? Y {I NPSSERVICE2_1
NPSGREV2 Y {I NPSSERVICE2_4
NPSGREV3 Y H }I NPSSERVICE2_1
NPSGREV4 Y NPSSERVICE2_1
BRSS Y Hi {I BRSS
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2008
Page No: 162 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
21 Appendix D — Metadata and Static Reference Data
Definition
21.1 Partition Management metadata
21.1.1 Table Groups
Table Group
Description
Message Journal
Holds all journalised messages sent by the counter
Settlement Transactions
Holds Settlement transactional details
Event Store
Holds details of all events generated by the Counter (other than EPOSS events)
Report Session Data
Used to load input data for all transactions to be used for reporting
Recovery Transactions
Holds details of all transactions needing reversing in the event of failure
Guaranteed Reversals
Holds the Guaranteed Reversals table
Aggregations Contains all aggregation tables
Hydra Groups together Hydra-specific tables
Table 15 - BRDB_TABLE_GROUPS Metadata
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2008
Page No: 163 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
21.1.2 Partitioned Tables
Table I Table Name Primary I Next Primary I Next Tablespace I Partition Root Partition I Partitions I Old New Deletion
Group Partition I Partitio I Tablesp I Tables I RootName I Name Mechani I Per Day Partition Partitio I Check
Type n ace pace sm Other SQL I n Criteria
Other
sat
Aggreg I BRDB_RX_CUTO I D 1 TRAD_DT R
ations I FF_SUMMARIES
BRDB_TX_TRANS I D 1 TRAD_DT R
ACTION_TOTALS
BRDB_DAILY_CU I D 1 JRNL_DATE R
MMULATIVE_SUM
MARY
BRDB_DAILY_SU I D 1 JRNL_DATE R
MMARY
BRDB_TX_APS_T I D 1 TRAD_DT R
RANSACTION_TO
TALS
Hydra. I BRDB_HYDRA C I D 1 TRAD_DATE R
T_MODE_TOTALS
BRDB_HYDRA C I D 1 TRAD_DATE R
T_TOTALS
Messa I BRDB_RX_MESS I D 1 JRNL_DATE R
ge AGE_JOURNAL
Journal
Settlem I BRDB_RX_APS_T I D 1 JRNL_DATE R
ent RANSACTIONS
Transa BRDB_RX BURE I D 1 JRNL_DATE R
AU_TRANSACTIO
NS
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 164 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB_RX_EPOS I D 1 JRNL_DATE R
S_TRANSACTION
s
BRDB_RX_NWB_ I D 1 JRNL_DATE R
TRANSACTIONS
BRDB_RX_DCS_T I D 1 JRNL_DATE R
RANSACTIONS,
BRDB_RX_EPOS I D 1 EVENT_DATE R
S_EVENTS
Event I BRDB_RX_REP_E I D 1 REP_EVENT_ED R
Store I VENTS
Report I BRDB_RX_REP_S I D 1 JRNL_DATE R
Sessio I ESSION_DATA
n Data
Recove I BRDB_RX RECO I D 1 TXN_STRT_DATE R settlement_co
y VERY_TRANSACT mplete_timest
Transa I IONS amp IS NULL
tions
Guaran I BRDB_RX_GUAR I D 1 RECEIPT_DATE R nps_delivered
teed I ANTEED_REVER _timestamp IS
Revers I SALS NULL
als
Table 16 - BRDB_PARTITIONED_TABLES Metadata
Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APPTHLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 165 of 197
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
ed
21.1.3. Table Partitions
Table Name Column Name Parent Column Own
Tablespace
BRDB_RX_REP_EVENT_DATA EVENT_DATE
BRDB_RX_EPOSS_EVENTS. EVENT_DATE
BRDB_RX_NWB_TRANSACTIONS JOURNAL_DATE
BRDB_DAILY_CUMULATIVE_SUMMARY JOURNAL_DATE
BRDB_DAILY_SUMMARY JOURNAL_DATE
BRDB_RX_EPOSS_TRANSACTIONS. JOURNAL_DATE
BRDB_RX_DCS_TRANSACTIONS. JOURNAL_DATE
BRDB_RX_BUREAU_TRANSACTIONS JOURNAL_DATE
BRDB_RX_APS_TRANSACTIONS. JOURNAL_DATE
BRDB_RX_REP_SESSION_DATA JOURNAL_DATE
BRDB_RX_MESSAGE_JOURNAL JOURNAL_DATE
BRDB_RX_GUARANTEED_REVERSALS RECEIPT_DATE
BRDB_RX_CUT_OFF_SUMMARIES TRADING_DATE
BRDB_HYDRA_CT_TOTALS TRADING _DATE
BRDB_HYDRA_CT_MODE_TOTALS. TRADING_DATE
BRDB_TX_APS_TRANSACTION_TOTALS TRADING DATE
BRDB_TX_TRANSACTION_TOTALS TRADING DATE
BRDB_RX_RECOVERY_TRANSACTIONS TRANSACTION_START_
DATE
Table 17 - BRDB_TABLE_PARTITIONS Meta Data
21.1.4 Sub-partition Ranges
BRDB_RX_REP_EVEN I EVENT_DATE 1 D &CURRDT1 I YYYYMMDD
T_DATA
BRDB_RX_EPOSS_EV I EVENT_DATE 4 D &CURRDT1 YYYYMMDD
ENTS
BRDB_RX_NWB_TRA JOURNAL_DATE 1 D &CURRDT1 I YYYYMMDD
NSACTIONS
BRDB_DAILY_CUMUL JOURNAL_DATE 4 D &CURRDT1 YYYYMMDD
ATIVE_SUMMARY
BRDB_DAILY_SUMMA I JOURNAL_DATE 1 D &CURRDT1 I YYYYMMDD
BRDB_RX_EPOSS_TR I JOURNAL_DATE 4 D &CURRDT1 YYYYMMDD
ANSACTIONS
BRDB_RX_DCS_TRAN I JOURNAL_DATE 1 D &CURRDT1 I YYYYMMDD
SACTIONS
BRDB_RX_BUREAU_T I JOURNAL_DATE 1 D &CURRDT1 YYYYMMDD
RANSACTIONS,
BRDB_RX_APS_TRAN I JOURNAL_DATE 41 D &CURRDT1 I YYYYMMDD
SACTIONS
BRDB_RX_REP_SESS! I JOURNAL_DATE 1 D &CURRDT1 I YYYYMMDD
ON_DATA
BRDB_RX_MESSAGE_ I JOURNAL_DATE 4 D &CURRDT1 I YYYYMMDD
JOURNAL
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-09
Page No: 166 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design ‘
FUJITSU COMMERCIAL-IN-CONFIDENCE
BRDB_RX_GUARANTE I RECEIPT_DATE 1 D &CURRDT1 I YYYYMMDD
ED_REVERSALS
BRDB_RX_CUT_OFF_ I TRADING DATE 1 D &CURRDT1 I YYYYMMDD
SUMMARIES
BRDB_HYDRA_CT_TO I TRADING DATE 1 D &CURRDT1 I YYYYMMDD
TALS
BRDB_HYDRA_CT_M I TRADING DATE 1 D &CURRDT1 I YYYYMMDD
ODE_TOTALS
BRDB_TX APS TRAN I TRADING DATE 1 D &CURRDT1 I YYYYMMDD
SACTION_TOTALS
BRDB_TX_TRANSACTI I TRADING_DATE 1 D &CURRDT1 I YYYYMMDD
ON_TOTALS
BRDB_RX_RECOVER I TRANSACTION_ST I 4 D &CURRDT1 I YYYYMMDD
Y_TRANSACTIONS, ART_DATE
Table 18 - BRDB_SUBPARTITION_RANGES Meta Data
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE
Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-09
Page No: 167 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
21.2 Housekeeping & Maintenance Metadata
21.2.1 Archived Tables
Archiv I Archive Group I Table Name
e Description
Group
Alias
Table
Alias
Timestamp
Column
Name
Archive
Directory
Archi I Purge
ve After
Type I Proces
sing
‘Audit
Directory
Retenti
on
Period
Archi
ve
Thres
hold
Additional Criteria
AST Archived Statistics
Table
BRDB_OBJECT_ST
ATS_ARC
AST
D1
RP Y BRDB_ARCHI
VE_OUTPUT
2
And ROWNUM < 10001
AUD System audit table I SYS.AUDS
AUD
TIMESTAMP#
BRDB_ARCHI
RP Y \VE_OUTPUT
BRDB_HOS.
T_AUDIT_O
UTPUT
BRDB_BRANCH_D
BCH Branch Details ECL
BD2
INSERT_TIME
STAMP
BRDB_ARCHI
RP Y VE_OUTPUT
‘AND (zero_decl_yn ="Y' OR
(fad_hash,branch_accounting_cod
e,stock_unit) IN (SELECT
fad_hash,branch_accounting_cod
e,stock_unit FROM
brdb_branch_dec! MINUS
SELECT
fad_hash,branch_accounting_cod
e,stock_unit FROM
brdb_branch_stock_units WHERE
NOT (is_deleted = 'Y' AND
deleted _date <
(TO_DATE(pkg_brdb_common.fn
_get_short_date,YYYYMMDD’)-
28))))
BRDB_SU_PENDIN
G_TRANSFER_DET
BCH Branch Details
BT1
INSERT_TIME
STAMP
RP Y
AND rowid IN (SELECT t2.rowid
FROM brdb_su_pending_transfer
ti, brdb_su_pending_transfer_det
12 WHERE f/ status ='C’ AND
TO_DATE(pkg_brdb_common.fn_
get_short_date,,YYYYMMDD’) -
TRUNC(t7.update_timestamp) >
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE
Ref.
Version:
Date:
Page No
V1.0
17-Nov-09
168 of 197
DES/APP/HLD/0020_
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Archiv
Group
Alias
Archive Group
Description
Table Name
Table
Alias
Timestamp
Column
Name
Archi
Type
Purge
After
Proces
sing
Archive
Directory
Audit
Directory
Retenti
on
Period
Archi
ve
Thres
hold
Additional Criteria
19 AND t2.fad_hash = t1.fad_hash
AND t2.branch_accounting_code
= tt.branch_accounting_code
AND 12.node_id = t1.node_id AND
12.source_session_id =
t1.source_session_id)
BCH
Branch Details
BRDB_SU_PENDIN
G_TRANSFER
BT2
UPDATE_TIM
ESTAMP
RP.
AND STATUS =
BCH
Branch Details
BRDB_SUSPENDE
D_CUSTOMER_SE
ss
BSS
UPDATE_TIM
ESTAMP
RP
AND UPPER(session_status) =
‘COMPLETE’
BCH
Branch Details
BRDB_SU_OPENIN
G_BALANCE
BDS
INSERT_TIME
STAMP
RP
62
‘AND rowid IN (SELECT t2.rowid
FROM brdb_branch_info t1,
brdb_su_opéning_balance
t2 WHERE t2.fad_hash =
t1fad_hash AND
{2.branch_accounting_code =
t/.branch_accounting_code AND
(LEAST(t7.current_trading_period,
12)+
DECODE(SIGN(LEAST(t1 current
_trading_period, 12)-
LEAST(t2.trading_period, 12)), -1,
12, 0)) - (LEAST(2.trading_period,
12))>3)
BCH
Branch Details
BRDB_RX_BTS_DA
TA
BDS8
INSERT_TIME
STAMP:
RP
Y
62
‘AND rowid IN (SELECT t2.rowid
FROM brdb_branch_info t1,
brdb_rx_bts_data t2 WHERE
12fad_hash = t1 fad_hash AND
{2.branch_accounting_code =
7 branch_accounting_code AND
(LEAST(t?.current_trading_period,
12)+
DECODE(SIGN(LEAST(t1.current
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE
Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 169 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Archiv
Group
Alias
Archive Group
Description
Table Name
Table
Alias
Timestamp
Column
Name
Archi
Type
Purge
After
Proces
sing
Archive
Directory
Audit
Directory
Retenti
on
Period
Archi
ve
Thres
hold
Additional Criteria
“trading_period, 12)-
LEAST(t2.trading_period, 12)), -1,
12, 0)) - (LEAST(2.trading_period,
12)) > 3)
BCH
Branch Details
BRDB_PS_BARCO
DES
PSB
UPDATE_TIM
ESTAMP
RP
20
AND UPPER(ollection_state) IN
((OUTOFOFFICE',"EXCEPTION’)
BCH
Branch Details
BRDB_CUTOFF_T
OTALS
BD7
INSERT_TIME
STAMP
RP
62
‘AND rowid IN (SELECT t2.rowid
FROM brdb_branch_info t1,
brdb_cutoff totals t2 WHERE
12fad_hash = t ad_hash AND
{2.branch_accounting_code =
t7.branch_accounting_code AND
(LEAST(t1 current_trading_period,
12)+
DECODE(SIGN(LEAST(t1 current
_trading_period, 12)-
LEAST({2.trading_period, 12)), -1,
12, 0)) - (LEAST(E2.trading_period,
12)) > 3)
BCH
Branch Details
BRDB_CUTOFF_M
ARKERS:
BD5
INSERT_TIME
‘STAMP
RP
Y
62
‘AND rowid IN (SELECT 3.rowid
FROM brdb_branch_info
t1,brdb_cutoff_details 2,
brdb_citoff_markers t8 WHERE
12fad_hash = t1 fad_hash AND
12.branch_accounting_code =
t/.branch_accounting_code AND
18.fad_hash = t2.fad_hash AND
8.branch_accounting_code =
{2.branch_accounting code AND
13.stock_unit = t2.stock_unit AND
{3.report_id = t2.report_id AND
{8.cut_off_timestamp =
{2.cut_off_timestamp AND
(LEAST(t7.current_trading_period,
12)+
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE
Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 170 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
Archiv
Group
Alias
Archive Group
Description
Table Name
Table
Alias
Timestamp
Column
Name
Archi
Type
Purge
After
Proces
sing
Archive
Directory
Audit
Directory
Retenti
on
Period
Archi
ve
Thres
hold
Additional Criteria
DECODE(SIGN(LEAST(T current
_trading_period, 12)-
LEAST({2.trading_period, 12)), -1,
12, 0)) - (LEAST(t2.trading_period,
12))>3)
BCH
Branch Details
BRDB_CUTOFF_D
ETAILS
BDG
INSERT_TIME
STAMP:
RP
62
AND rowid IN (SELECT t2.rowid
FROM brdb_branch_info t1,
brdb_cutoff_details t2 WHERE
12.fad_hash = {1 ad_hash AND
12.branch_accounting_code =
t1.branch_accounting_code AND
(LEAST(t7.current_trading_period,
12)+
DECODE(SIGN(LEAST(t1.current
_trading_period, 12)-
LEAST(t2.trading_period, 12)), -1,
12, 0)) - (LEAST(f2.trading_period,
12))>3)
BCH
Branch Details
BRDB_BRANCH_U
SER_SESSIONS
BD4
SESSION_ST
ART_TIMEST
AMP.
RP
AND UPPER(session_status) IN
(LOGOUT, INVALIDATE’)
BCH
Branch Details
BRDB_BRANCH_S.
TOCK_UNITS
BD1
DELETED DA
TE
RP
205
AND is_deleted = 'Y"
BCH
Branch Details
BROB_BRANCH_D
ECL_ITEM
BD3
INSERT_TIME
STAMP
RP
AND
(fad_hash,branch_accounting_cod
e,stock_unit) IN (SELECT
fad_hash,branch_accounting_cod
e,stock_unit FROM
brdb_branch_decl_item MINUS
SELECT
fad_hash,branch_accounting_cod
e,stock_unit FROM
brdb_branch_decl)
CMJ
Counter Message
BRDB_RX_MESSA
BMJ
RP
Copyright Fujitsu Services Ltd 2009
COMMERCIAL-IN-CONFIDENCE
Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 171 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table I Timestamp I Archi I Purge Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
Journal GE_JOURNAL
RDDS_DESKTOP_ BRDB_RECEI
MEMO VED_TIMEST BRDB_ARCHI
DMO Desktop Memos RDM I AMP RP VeE_OUTPUT 62
RDDS_DESKTOP_ BRDB_RECEI
MEMO_DISTR VED_TIMEST BRDB_ARCHI
DMO. Desktop Memos RMD AMP: RP VE_OUTPUT 62
BRDB_DESKTOP_ BRDB_RECE!
MEMO_USER_DIST VED_TIMEST BRDB_ARCHI ‘AND counter_read_timestamp IS
DMO. Desktop Memos R BMD AMP RP VE_OUTPUT 62 NOT NULL
BRDB_DAILY_SUM
DSM Daily Summary MARY BDS RP 85
BRDB_DAILY_CUM
ULATIVE_SUMMAR
DSM Daily Summary Y BCS RP 5
BRDB_TX_TRANSA
DsM Daily Summary CTION_TOTALS BTO RP 6
BRDB_TX_APS_TR
ANSACTION_TOTA
Dsm Daily Summary Ls BAO RP 6
BRDB_RX_EPOSS
EVT Events Table _EVENTS BEE RP 4
BRDB_RX_REP_EV
EVT Events Table ENT_DATA BRE RP 63
BRDB_HYDRA_CT_
HYD Hydra TOTALS BHT RP 6
BRDB_HYDRA_CT_
HYD Hydra MODE_TOTALS BMT RP 6
LFS_PLO_HEADER BRDB_RECEI
Logistics, Stock VED_TIMEST
LFS and Cash LPH AMP RP Y 14
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 172 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table [Timestamp I Archi I Purge I Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
LFS_PLO_DETAILS BRDB_RECEI
Logistics, Stock VED_TIMEST
LFS and Cash LPD I AMP RP Y 14
LFS_RDC_HEADER BRDB_RECEI
Logistics, Stock VED_TIMEST
LFS and Cash LRH I AMP RP Y 14
LFS_RDC_DETAILS BRDB_RECEI
Logistics, Stock VED_TIMEST
LFS and Cash LRD I AMP RP Y 14
Logistics, Stock BRDB_POUCH_DE INSERT_TIME AND Ifs_delivered_timestamp IS
LFS and Cash L_HEADER BPH I STAMP RP Y 5 NOT NULL
BRDB_POUCH_DE AND
L_DETAILS (fad_hash,branch_accounting_cod
e.delivery_id) IN (SELECT
fad_hash,branch_ace
counting_code,delivery_id FROM
brdb_pouch_del_details MINUS
SELECT
fad_hash,branch_accounting_cod
Logistics, Stock INSERT_TIME e,delivery_id FROM
LFS and Cash BPX I STAMP RP Y 5 brdb_pouch_del_header)
Logistics, Stock BRDB_POUCH_CO. INSERT_TIME AND lfs_delivered_timestamp IS
LFS and Cash LL_HEADER PCH I STAMP RP Y 5 NOT NULL
BRDB_POUCH_CO AND
LL_DETAILS (fad_hash,branch_accounting_cod
e,collection_id) IN (SELECT
fad_hash,branch_accounting_cod
e,collection_id FROM
brdb_pouch_coll_details MINUS
SELECT fad_hash,
branch_accounting_code,collectio
Logistics, Stock INSERT_TIME n_id FROM
LES and Cash PCD I STAMP RP Y 5 brdb_pouch_coll_header)
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-09
Page No: 173 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table [Timestamp I Archi I Purge I Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
Logistics, Stock I BRDB_CASH_HEA INSERT_TIME ‘AND Ifs_delivered_timestamp IS
LFS and Cash DER BCH I STAMP RP Y 5 NOT NULL
BRDB_CASH_DET AND
AILS (fad_hash,branch_accounting_cod
e,trading_date) IN (SELECT
fad_hash,branch_accounting_cod
e,trading_date FROM
brdb_cash_details MINUS
SELECT
fad_hash,branch_accounting_cod
Logistics, Stock INSERT_TIME e,trading_date FROM
LFS and Cash BcD__I STAMP RP Y 5 brdb_cash_header)
NPS Transactional I BRDB_RX_GUARAN
NXN Table TEED_REVERSALS I BGR RP 6
NPS Transactional I BRDB_RX_TT_TRA
NXN Table NSACTIONS BIT RP Y 5
BRDB_OPERATION EXCEPTION BRDB_ARCHI
OPR Operational Table I AL_EXCEPTIONS I OPE I TIMESTAMP I RP. Y VE_OUTPUT 62
BRDB_HYDRA_EX INSERT_TIME BRDB_ARCHI
OPR Operational Table I CEPTIONS HEX I STAMP RP Y Ve_OUTPUT 31
BRDB_PARTITION_ STATUS_DAT BRDB_ARCHI
OPR Operational Table I CREATES BPN I E RP Y Ve_OUTPUT 62 AND status = ‘DEL’
AND rownum < 10001
‘AND rowid IN
(SELECT bpsh.rowid
FROM
brdb_partition_status_history
bpsh
BRDB_PARTITION_ CREATE_DAT BRDB_ARCHI WHERE NOT EXISTS
OPR I Operational Table I STATUS_HISTORY I BPH I E RP Y Ve_OUTPUT 62 (SELECT 1
Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APPHLD/0020
Version: V1.0
Date: 17-Nov-09
Page No: 174 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table I Timestamp I Archi I Purge Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
FROM
brdb_partitioned_tables bpt,
brdb_partition_creates bpc
WHERE
bpt-table_name =
bpsh.table_name
AND bpc.table_name =
bpt.table_name
AND bpc.partition_range_value
LTRIM(bpsh. partition_name,bptpa
ttition_roo
t_namelI'.’)
AND bpe.status <> 'DEL'))
BRDB_HOS
BRDB_PROCESS_ SYSTEM_DA BRDB_ARCHI I T_AUDIT_O
OPR Operational Table I AUDIT BPA TE RP Y VE_OUTPUT I UTPUT 62
BRDB_PROCESS_ SYSTEM_DA BRDB_ARCHI
OPR Operational Table I CONTROL BPC us RP Y VE_OUTPUT 62
INSERT_TIME
BRDB_RX_REPOR STAMP +
OPR Operational Table I T_REPRINTS BRR KEEP_DAYS I RP Y 0
BRDB_HOST_INTE
RFACE_FEED_EXC PROCESSIN
OPR Operational Table I P BIE G_DATE RP Y 5
BRDB_OPERATION BRDB_HOS
AL_INSTANCES_H INSERT_TIME BRDB_ARCHI I T_AUDIT_O
OPR Operational Table I ST OlH STAMP RP Y VE_OUTPUT I UTPUT 62
BRDB_PASSWORD INSERT_TIME AND rowid IN (SELECT rowid
OPR Operational Table I _HISTORY PWH I STAMP RP Y 0 FROM (SELECT rowid,
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 175 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table [Timestamp I Archi I Purge I Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
ROW_NUMBER() OVER
(PARTITION BY
fad_hash,branch_accounting_cod
e,branch_user ORDER BY
insert_timestamp DESC) pos
FROM brdb_password_history)
WHERE pos > 12)
BRDB_ANALYZED_ BRDB_ARCHI
OPR Operational Table I OBJECTS BAO FT VE_OUTPUT
BRDB_ARCHIVED_ BRDB_ARCHI
OPR Operational Table I TABLES ART FT VE_OUTPUT
BRDB_BAL_CONFI BRDB_ARCHI
OPR Operational Table I G PARAMETERS I BCP FT VE_OUTPUT
BRDB_BAL_SQL_D BRDB_ARCHI
OPR Operational Table_I EFINITIONS BSD FT Ve_OUTPUT
BRDB_EXCEPTION BRDB_ARCHI
OPR Operational Table I _CODES BEX FT. Ve_OUTPUT
BRDB_FAD_HASH_
INSTANCE_MAPPI BRDB_ARCHI
OPR Operational Table_I NG FHI FT VE_OUTPUT
BRDB_FAD_HASH_ BRDB_ARCHI
OPR Operational Table I OUTLET_MAPPING I FHO. FT VE_OUTPUT
BRDB_FAD_HASH_ BRDB_ARCHI
OPR Operational Table_I VALUES FHV FT Ve_OUTPUT
BRDB FILES TO_ BRDB_ARCHI
OPR Operational Table I HOUSEKEEP FHK FT Ve_OUTPUT
BRDB_HOST AGG BRDB_ARCHI
OPR Operational Table I REGATIONS BHA FT VE_OUTPUT
BRDB_HOST_INTE BRDB_ARCHI
OPR Operational Table I RFACE_FEEDS BIF FT VE_OUTPUT
OPR Operational Table_ I BRDB_OPERATION I BO! FT BRDB_ARCHI
Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APPHLD/0020
Version: V1.0
Date: 17-Nov-09
Page No: 176 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table I Timestamp I Archi I Purge Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
AL_INSTANCES VE_OUTPUT
BRDB_ORACLE_E BRDB_ARCHI
OPR Operational Table I RROR_CODES. OEC FT VE_OUTPUT
BRDB_PARTITION BRDB_ARCHI
OPR Operational Table I ED_INDEXES BPI FT VE_OUTPUT
BRDB_PARTITION BRDB_ARCHI
OPR Operational Table I ED_TABLES BPT FT VE_OUTPUT
BRDB_PROCESSE BRDB_ARCHI
OPR Operational Table I S BPR FT VE_OUTPUT
BRDB_ARCHI
OPR Operational Table I BRDB_SQL_HINTS I BSH FT VE_OUTPUT
BRDB_SUBPARTITI BRDB_ARCHI
OPR Operational Table I ON RANGES BSR FT VE_OUTPUT
BRDB_SYSTEM_P BRDB_ARCHI
OPR Operational Table I ARAMETERS BSP FT VE_OUTPUT
BRDB_TABLE_GR BRDB_ARCHI
OPR Operational Table I OUPS BTG FT VE_OUTPUT
BRDB_TABLE_PAR BRDB_ARCHI
OPR Operational Table I TITIONS BTP FT VE_OUTPUT
STATUS_CHA
BRDB_FILE_AUDIT NGE_TIMEST BRDB_ARCHI
OPR Operational Table I _TRAIL FAT I AMP RP Y Ve_OUTPUT 62
Recovery BRDB_RX_RECOV
Transactions ERY_TRANSACTIO
RCV Table NS BRT RP 4
RDDS_CHECKSUM INSERT_TIME
RDD RDDS Ref Data HIST RCH STAMP: RP Y 30
INSERT_TIME
RDD RDDS Ref Data RDDS_CHECKSUM I RCS STAMP. RP Y 30
RDD RDDS Ref Data I BRDB REF DATA I RDS I First Loc I RP Y 30
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 177 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Archiv I Archive Group I Table Name Table I Timestamp I Archi I Purge Archive Audit Retenti I Archi I Additional Criteria
e Description Alias I Column ve After I Directory Directory I on ve
Group Name Type I Proces Period I Thres
Alias sing hold
SLAS ON
BRDB_REM_OUT_ INSERT_TIME AND UPPER(pouch_status) IN
REM REM pouch POUCH_DETAILS PH1 STAMP: RP Y 5 ((DESPATCHED' DESTROYED’)
Report
Transactional BRDB_RX_REP_SE
RTN Table SSION_DATA BSD RP 62
Transaction BRDB_TXN_CORR JOURNAL_DA
TCT Correction Tool _TOOL_JOURNAL TCJ TE RP Y 4
TPS_HYDRA_INDA TRADING_DA
TPS Hydra Processing I Y_DATA HID I TE RP Y 30 AND processed_yn
TPS_HYDRA_REC TRADING_DA
TPS Hydra Processing I ON TOTALS HRT I TE RP Y 5 AND processed_yn IN (‘Y';E')
Transactional BRDB_RX_APS_TR
TXN Table ANSACTIONS BAT RP 4
Transactional BRDB_RX_BUREA
TXN Table U_TRANSACTIONS I BBT RP. 4
Transactional BRDB_RX_EPOSS
TXN Table _ TRANSACTIONS: BET RP 4
Transactional BRDB_RX_NWB_T
TXN Table RANSACTIONS BNT RP 4
Transactional BRDB_RX_DCS_TR
TXN Table ANSACTIONS BFT RP 4
Transactional BRDB_RX_DCS_TR
TXN Table ANSACTIONS BFT RP 4
Transactional BRDB_RX_CUT_OF
TXN Table F_SUMMARIES COF RP 4
TPS_TXN_CORRE TCD
CTION_DETAILS COUNTER_P
Transactional ROCESSED _
TXN Table TCD TIMESTAMP RP Y 40
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 178 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE &
Table 19 - BRDB_ARCHIVED_TABLES Metadata
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020_
Version: V1.0
Date: 17-Nov-09
Page No: 179 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
21.2.2 Analyzed Objects
Object Name Object I Object I Object Analyze Insert Partit I Sample Block Method
Group I Type I Group Method I Timesta I ion I Percenta I Samp! I Option
Descripti mp Num I ge e
on ber
BRDB_RX_MESS I MSJ TABLE Message DBMS_STA I SYSTIM I 3 10 TRUE FOR ALL
AGE_JOURNAL Journal TS ESTAMP INDEXED
COLUMN
Ss
BRDB_RX_REP_ I RSD TABLE Report DBMS_STA I SYSTIM I 3 10 TRUE FOR ALL
SESSION_DATA Session TS ESTAMP INDEXED
Data COLUMN
Ss
BRDB_SU_CUT_ I RAG TABLE Report DBMS_STA I SYSTIM 10 TRUE FOR ALL
OFF_MARKERS: Aggregation I TS ESTAMP INDEXED
COLUMN
s
BRDB_SU_CUT_ I RAG TABLE I Report DBMS_STA I SYSTIM 10 TRUE I FORALL
OFF_TOTALS Aggregation I TS ESTAMP. INDEXED
COLUMN
s
BRDB_SU_CUT_ I RAG TABLE Report DBMS_STA I SYSTIM 10 TRUE FOR ALL
OFF_DETAILS Aggregation I TS ESTAMP INDEXED
COLUMN
s
BRDB_RX_RECO I RCV TABLE Transaction I DBMS_STA I SYSTIM I 3 10 TRUE FOR ALL
VERY_TRANSAC Recovery TS ESTAMP INDEXED
TIONS COLUMN
s
BRDB_DAILY_SU I DSM TABLE Transaction I DBMS_STA I SYSTIM I 3 10 TRUE FOR ALL
MMARY Summary Ts ESTAMP INDEXED
COLUMN
s
BRDB_DAILY_C I DSM TABLE I Transaction I DBMS_STA I SYSTIM I 3 10 TRUE I FORALL
UMULATIVE_SU Summary TS ESTAMP INDEXED
MMARY COLUMN
s
BRDB_BROUGH I DSM TABLE Transaction I DBMS_STA I SYSTIM I 3 10 TRUE FOR ALL
T_FWD_STOCK_ Summary I TS ESTAMP INDEXED
HIST. COLUMN
Ss
Table 20 - BRDB_ANALYZED_OBJECTS Meta Data
Note that this is currently not used by the TWS overnight batch job, which performs Schema level
statistics.
21.2.3 Exception Codes
The complete list of application exception codes will be defined in the Branch Database Support Guide.
SCopyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE,
Ref:
Version: V1.0
Date:
Page No:
DES/APP/HLD/0020
17-Nov-2009
180 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
21.2.4 Files to Housekeep
Directory Name File Name Retention Delete
Period Subdirectories?
S{BRDB_ARCHIVE_OUTPUT} “* 5 N
Table 21 - BRDB_FILES_TO_HOUSEKEEP Meta Data
A number of standard Oracle directories which produce on going trace files and core dumps will be
housekept by /usr/local/bin/RMANBackup.sh:
/u01/admin/BRDB/adump — Audit_File_Dest: These contain copies of the SYS.AUD$ tables which are.
archived after 5 days. This directory's ‘*.aud' files should be retained for 7 days.
/u01/admin/BRDB/bdump — Background_Dump_Dest: trace ™.trc' files and core dumps can be tidied after
28 days.
/u01/admin/BRDB/cdump — Core_Dump_Dest: trace “.trc’ files and core dumps *.dmp' can be tidied
after 28 days.
/u01/admin/BRDB/udump — User_Dump_Dest: trace “.trc’ files and core dump *.dmp' files can be tidied
after 28 days.
$ORACLE_HOME/rdbms/audit — This contains ASM instance audit logs and the ‘*.aud’ files can be tidied
after 28 days.
$ORACLE_HOME/rdbmsi/log — trace “.trc' files can be tidied after 28 days.
Any trace or core dump files required for Oracle support calls will have been uploaded to Oracle Metalink
as evidence files within the retention period.
21.2.5 Processes
Process Name Process Description Process Day I Process in Use
Multiple Runs
BRDBCO01 Start of Day N Y
BRDBC002 Audit Store Auditing N Y
BRDBX003 Common Legacy Host Interface N Y
BRDBC004 Audit, Archive and DB-Copy N Y
BRDBX005 Gather Optimizer Statistics N Y
BRDBX006 File Housekeeping N Y
BRDBX007 Data Aggregation Tool N Y
BRDBC008 Check Job Completion Y Y
BRDBC009 End Of Day N Y
BRDBX011 Update System Parameters Y Y
BRDBX013 Updates the operational instances Y Y
BRDBX015 Transaction Correction Tool Y Y
BRDBX020 Transfer to DWh N Y
BRDBX021 Pause / Start Streams Replication Y Y
BRDBX030 Hydra specific XML Data Processor N Y
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 181 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design
FUJITSU COMMERCIAL-IN-CONFIDENCE
Process Name Process Description Process Day I Process in Use
Multiple Runs
BRDBX031 Reset JSN SSN USN N Y
BRDBX033 End Of Day Prep Hydra XML N Y
BRDBX034 RDDS migrating branch pull N Y
Table 22 - BRDB_PROCESSES Meta Data
21.3 Fad-Hash Mappings
21.3.1 Fad-Hash Values
This table contains 128 entries in total of a number ranging from 0...127.
21.3.2 Operational Instances
Instance Id Instance Description Is Available Host Name Service Name
1 I First Oracle Instance Y LPRABDBOO1 BRDB1
2 I Second Oracle Instance Y LPRABDBOO2 BRDB2
3 I Third Oracle Instance Y LPRABDBO03 BRDB3
4 I Fourth Oracle Instance Y LPRABDBOO4 BRDB4
Table 23 - BRDB_OPERATIONAL_INSTANCES Meta Data
21.3.3. Fad-Hash Instance Mapping
The attached mappings spreadsheet provides the Instances and their priorities for each Fad-Hash value.
"Fad-Hash
Spreadsheet.xs"
21.3.4 Fad-Hash Outlet Mapping
The attached mappings spreadsheet provides the list of Outlets that have been assigned Fad-Hash
values.
21.4 Host Processing Metadata
21.4.1 Host Interface Feeds
The table defines the names of the Host Interface Feeds.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 182 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
OFFICE
Interface Feed Name Interface Description Uses Fad- I Uses Auto Auto Repeat
Hash? Repeat? Seconds?
BRDB_APS_TXN_FROM_TP I BRDB APS transactions from TPS feed Y N
s
BRDB_APS_TXN_TO_APS I BRDB APS transactions to APS feed Y N
BRDB_APS_TXN_TO_TPS I BRDB APS transactions to TPS feed Y N
BRDB_BDC_TXN_FROM_TP I BRDB BDC transactions from TPS feed Y N
Ss
BRDB_BDC_TXN_TO_TPS I BRDB BDC transactions to TPS feed Y N
BRDB_CASH_TO_LFS I BRDB Cash Declarations to LFS feed Y N
BRDB_CNTR_REF_FROM_R I BRDB Counter Reference Data from N N
DDs I RDDS feed
BRDB_CUTOFF_SUMM_TO_ I BRDB Cutoff Summaries to TPS feed Y N
TPS
BRDB_DCS_TXN_FROM_TP I BRDB DCS transactions from TPS feed Y N
s
BRDB_DCS_TXN_TO_DRS I BRDB DCS transactions to DRS feed Y N
BRDB_DCS_TXN_TO_TPS I BRDB DCS transactions to TPS feed Y N
BRDB_EMDB_INTERFACE I BRDB Estate Management Interface N N
feed
BRDB_EPOSS_EVNT_TO_T I BRDB EPOSS events to TPS feed Y N
Ps
BRDB_EPOSS_TXN_FROM_ I BRDB EPOSS transactions from TPS Y N
TPS I feed
BRDB_EPOSS_TXN_TO_TP I BRDB EPOSS transactions to TPS feed Y N
s
BRDB_HOST_REF_FROM_R I BRDB Host Reference Data from RDDS N N
DDS I feed
BRDB_INDAY_XML_FROM_ I BRDB In-Day Migration Blob from TPS. N N
TPS I feed
BRDB_MEMOS_FROM_RDD I BRDB Desktop Memos from RDDS feed N N
Ss
BRDB_NWB_TXN_FROM_TP I BRDB NWB transactions from TPS feed Y N
s
BRDB_NWB_TXN_TO_DRS I BRDB NWB transactions to DRS feed Y N
BRDB_NWB_TXN_TO_TPS I BRDB NWB transactions to TPS feed Y N
BRDB_PCOL_TO_LFS I BRDB Pouch Collections to LFS feed Y Y 1
BRDB_PDEL_TO_LFS I BRDB Pouch Deliveries to LFS feed Y Y 1200
BRDB_PLO_FROM_LFS I BRDB Planned Order details from LFS Y N
feed
BRDB_RDC_FROM_LFS I BRDB Replenishment Delivery details Y N
from LFS feed
BRDB_RECON_XML_FROM I BRDB Reconciliation Blob from TPS N N
_TPS I feed
BRDB_REF_COPY_FROM_T I BRDB Outlets/Transaction Modes from N N
PS I TPS feed
BRDB_REV_TXN_TO_NPS I BRDB Reversal Records to NPS feed Y Y 0
BRDB_TT_TXN_TO_NPS I BRDB Track and Trace Records to NPS Y Y 180
feed
BRDB_TXN_CORR_FROM_T I BRDB Transaction Corrections from TPS. N N
Ps I feed
BRDB_TXN_TOT_TO_APS I BRDB Transaction Totals to APS feed Y N
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 183 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
OFFICE
Interface Feed Name Interface Description Uses Fad- I Uses Auto Auto Repeat
Hash? Repeat? Seconds?
BRDB_TXN_TOT_TO_TPS I BRDB Transaction Totals to TPS feed Y N
Table 24 - BRDB_HOST_INTERFACE_FEEDS Meta Data
21.4.2 Host Aggregations
The table defines the names of the Host Aggregation SQLs.
‘Aggregation Name ‘Aggregation Description Uses Fad- I SQL I Aggregation
Hash? Id SQL
BRDB_NON_CUMU_TXN_AGGR I Daily Non-cumulative Summary is a Daily Y 1 I To be defined in
summarisation at SU, TP, BP, Product and the Low Level
Transaction Mode level Designs
BRDB_CUMU_TXN_AGGR I Daily Cumulative Summary is a Y 4
Cumulative summarisation at SU, TP and
BP level
BRDB_TPS_TXN_TOTALS I Outlet level transaction totals of quantities Y 4
and amounts. This information is passed.
to TPS-Host to facilitate its transaction
reconciliation.
BRDB_APS_TXN_TOTALS I Outlet level transaction totals of quantities Y 1
and amounts. This information is passed
to APS-Host to facilitate its transaction
reconciliation.
OVERNIGHT_CASH_ON_HAND I The Overnight Cash statement is prepared Y 1
by aggregating all current Cash 2
declarations made at the Branch
3
Table 25 - BRDB_HOST_AGGREGATIONS Meta Data
21.5 Branch Specific Metadata
21.5.1 Branch Roles
The table defines the names of the Branch Roles to be pre-created in the database.
Branch User Role Description Assignable Branch Start Date End Date
Role Role Specific
User
ADMIN I Adminstrator Y N 01/01/1900 31/12/3000
AUDITOR I Auditor Y N 01/01/1900 31/12/3000
AUDITOR E I Emergency Manager Y N 01/01/1900 31/12/3000
MIGRATE I Migrate Y N 01/01/1900 31/12/3000
MANAGER I Manager Y Y 01/01/1900 31/12/3000
SUPERVISOR I Supervisor Y Y 01/01/1900 31/12/3000
CLERK I Clerk Y Y 01/01/1900 31/12/3000
TRAINER I Trainer Y N 01/01/1900 31/12/3000
SETUP I Setup Y N 01/01/1900 31/12/3000
SUPPORT I Support Y N 01/01/1900 31/12/3000
ENGINEER I Engineer Y N 01/01/1900 31/12/3000
SETUP I Setup Y N 04/01/1900 31/12/3000
Table 26 - BRDB_BRANCH_ROLES Meta Data
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 184 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design r ~
FUJITSU COMMERCIAL-IN-CONFIDENCE didi
21.5.2 Branch Service Roles
The table defines the relationship between Services and Branch Roles to be pre-created in the database.
Branch Role Branch Service Name Start Date End Date
ADMIN AttachUserToStockUnitService I 01/01/1900 31/12/3000
ADMIN ChangeUserOptionsService I 01/01/1900 31/12/3000
ADMIN ChangeUserRoleService I 01/01/1900 31/12/3000
ADMIN CloseBranchUserAccountService I 01/01/1900 31/12/3000
ADMIN CreateBranchUser I 01/01/1900 31/12/3000
ADMIN GenericOnlineService I 01/01/1900 31/12/3000
ADMIN GetOutstandingDeclarations I 01/01/1900 31/12/3000
ADMIN LockBranchService I 01/01/1900 31/12/3000
ADMIN LockStockUnitService I 01/01/1900 31/42/3000
ADMIN PollingService I 01/01/1900 31/12/3000
ADMIN ReportingService I 01/01/1900 31/12/3000
ADMIN RolloverBranchService I 01/01/1900 31/12/3000
ADMIN SetPasswordOnline I 01/01/1900 31/12/3000
ADMIN SetPasswordOtherUser I 01/01/1900 31/12/3000
ADMIN StockUnitRolloverBPService I 01/01/1900 31/12/3000
ADMIN StockUnitRolloverTPService I 01/01/1900 31/12/3000
ADMIN UnlockBranchService I 01/01/1900 31/12/3000
ADMIN UnlockStockUnitService I 01/01/1900 31/12/3000
ADMIN UpdateCutOffReportService I 01/01/1900 31/12/3000
ADMIN recoveryService I 01/01/1900 31/12/3000
AUDITOR AttachUserToStockUnitService I 01/01/1900 31/12/3000
AUDITOR CutOffDespatchReportService I 01/01/1900 31/12/3000
AUDITOR CutOffReportService I 01/01/1900 31/12/3000
AUDITOR GetBranchTradingPeriodService I 01/01/1900 31/12/3000
AUDITOR GetOutstandingDeclarations I 01/01/1900 31/12/3000
AUDITOR LockBranchService I 01/01/1900 31/12/3000
AUDITOR PackagelnventoryService I 01/01/1900 31/12/3000
AUDITOR PollingService I 01/01/1900 31/12/3000
AUDITOR ReportingService I 01/01/1900 31/12/3000
AUDITOR RolloverBranchService I 01/01/1900 31/12/3000
AUDITOR SecureExistingReversalService I 01/01/1900 31/12/3000
AUDITOR SetPasswordOnline I 01/01/1900 31/12/3000
AUDITOR UnlockBranchService I 01/01/1900 31/12/3000
AUDITOR UpdateCutOffReportService I 01/01/1900 31/12/3000
AUDITOR recoveryService I 01/01/1900 31/12/3000
AUDITOR E AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
AUDITOR E AttachUserToStockUnitService I 01/01/1900 31/12/3000
AUDITOR E BasketSettlementService I 01/01/1900 31/12/3000
AUDITOR E ChangeUserOptionsService I 01/01/1900 31/12/3000
AUDITOR E ChangeUserRoleService I 01/01/1900 31/12/3000
AUDITOR E CloseBranchUserAccountService I 01/01/1900 31/12/3000
AUDITOR E CreateBranchUser I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 185 of 197
FUJITSU
Branch Database High Level Design
COMMERCIAL-IN-CONFIDENCE
FUJ00235023
FUJ00235023
OFFICE
Branch Role Branch Service Name Start Date End Date
AUDITOR E CutOffDespatchReportService I 01/01/1900 31/12/3000
AUDITOR E CutOffReportService I 01/01/1900 31/12/3000
AUDITOR E DownloadDeliveryService I 01/01/1900 31/12/3000
AUDITOR E GenericOnlineService I 01/01/1900 31/12/3000
AUDITOR E GetBranchTradingPeriodService I 01/01/1900 31/12/3000
AUDITOR E GetOutstandingDeclarations I 01/01/1900 31/12/3000
AUDITOR E GetValidationCharacter I 01/01/1900 31/12/3000
AUDITOR E IsVRMValid I 01/01/1900 31/12/3000
AUDITOR E LabelEventService I 01/01/1900 31/12/3000
AUDITOR E LockBranchService I 01/01/1900 31/12/3000
AUDITOR E LockStockUnitService I 01/01/1900 31/12/3000
AUDITOR E PackagelnventoryService I 01/01/1900 31/12/3000
AUDITOR E PollingService I 01/01/1900 31/12/3000
AUDITOR E ReconcileBarCodesService I 01/01/1900 31/12/3000
AUDITOR E RecordStockDeclarations I 01/01/1900 31/12/3000
AUDITOR E ReportingService I 01/01/1900 31/12/3000
AUDITOR E RolloverBranchService I 01/01/1900 31/12/3000
AUDITOR E SecureExistingReversalService I 01/01/1900 31/12/3000
AUDITOR E SetPasswordOnline I 01/01/1900 31/12/3000
AUDITOR E SetPasswordOtherUser I 01/01/1900 31/12/3000
AUDITOR E StockUnitManagement I 01/01/1900 31/12/3000
AUDITOR E StockUnitRolloverBPService I 01/01/1900 31/12/3000
AUDITOR E StockUnitRolloverTPService I 01/01/1900 31/12/3000
AUDITOR E UnlockBranchService I 01/01/1900 31/12/3000
AUDITOR E UnlockStockUnitService I 01/01/1900 31/12/3000
AUDITOR E UpdateChecksumService I 01/01/1900 31/42/3000
AUDITOR E UpdateCutOffReportService I 01/01/1900 31/12/3000
AUDITOR E UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
AUDITOR E ValidateChecksumService I 01/01/1900 31/12/3000
AUDITOR E banking I 01/01/1900 31/12/3000
AUDITOR E recoveryService I 01/01/1900 31/12/3000
CLERK AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
CLERK AttachUserToStockUnitService I 01/01/1900 31/12/3000
CLERK BasketSettlementService I 01/01/1900 31/12/3000
CLERK CutOffDespatchReportService I 01/01/1900 31/12/3000
CLERK CutOffReportService I 01/01/1900 31/12/3000
CLERK DownloadDeliveryService I 01/01/1900 31/12/3000
CLERK GenericOnlineService I 01/01/1900 31/12/3000
CLERK GetBranchTradingPeriodService I 01/01/1900 31/12/3000
CLERK GetOutstandingDeclarations I 01/01/1900 31/12/3000
CLERK GetValidationCharacter I 01/01/1900 31/12/3000
CLERK IsVRMValid I 01/01/1900 31/12/3000
CLERK LabelEventService I 01/01/1900 31/12/3000
CLERK LookStockUnitService I 01/01/1900 31/12/3000
CLERK PackagelnventoryService I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 186 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
CLERK PollingService I 01/01/1900 31/12/3000
CLERK ReconcileBarCodesService I 01/01/1900 31/12/3000
CLERK RecordStockDeclarations I 01/01/1900 31/12/3000
CLERK ReportingService I 01/01/1900 31/12/3000
CLERK SecureExistingReversalService I 01/01/1900 31/12/3000
CLERK SetPasswordOnline I 01/01/1900 31/12/3000
CLERK StockUnitRolloverBPService I 01/01/1900 31/12/3000
CLERK ‘StockUnitRolloverTPService I 01/01/1900 31/12/3000
CLERK UnlockStockUnitService I 01/01/1900 31/12/3000
CLERK UpdateChecksumService I 01/01/1900 31/12/3000
CLERK UpdateCutOffReportService I 01/01/1900 31/12/3000
CLERK UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
CLERK ValidateChecksumService I 01/01/1900 31/12/3000
CLERK banking I 01/01/1900 31/12/3000
CLERK recoveryService I 01/01/1900 31/12/3000
ENGINEER SetPasswordOnline I 01/01/1900 31/12/3000
MANAGERS AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
MANAGERS AttachUserToStockUnitService I 01/01/1900 31/12/3000
MANAGERS BasketSettlementService I 01/01/1900 31/12/3000
MANAGERS ChangeUserOptionsService I 01/01/1900 31/12/3000
MANAGERS ChangeUserRoleService I 01/01/1900 31/12/3000
MANAGERS CloseBranchUserAccountService I 01/01/1900 31/12/3000
MANAGERS CreateBranchUser I 01/01/1900 31/12/3000
MANAGERS CutOffDespatchReportService I 01/01/1900 31/12/3000
MANAGERS CutOffReportService I 01/01/1900 31/12/3000
MANAGERS DownloadDeliveryService I 01/01/1900 31/42/3000
MANAGERS GenericOnlineService I 01/01/1900 31/12/3000
MANAGERS GetBranchTradingPeriodService I 01/01/1900 31/12/3000
MANAGERS GetOutstandingDeclarations I 01/01/1900 31/12/3000
MANAGERS GetValidationCharacter I 01/01/1900 31/12/3000
MANAGERS IsVRMValid I 01/01/1900 31/12/3000
MANAGERS LabelEventService I 01/01/1900 31/12/3000
MANAGERS LockBranchService I 01/01/1900 31/12/3000
MANAGERS LockStockUnitService I 01/01/1900 31/12/3000
MANAGERS. PackageinventoryService I 01/01/1900 31/12/3000
MANAGERS PollingService I 01/01/1900 31/12/3000
MANAGERS ReconcileBarCodesService I 01/01/1900 31/12/3000
MANAGERS RecordStockDeclarations I 01/01/1900 31/12/3000
MANAGERS ReportingService I 01/01/1900 31/12/3000
MANAGERS RolloverBranchService I 01/01/1900 31/12/3000
MANAGERS SecureExistingReversalService I 01/01/1900 31/12/3000
MANAGERS ‘SetPasswordOnline I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 187 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
MANAGERS SetPasswordOtherUser I 01/01/1900 31/12/3000
MANAGERS StockUnitManagement I 01/01/1900 31/12/3000
MANAGERS StockUnitRolloverBPService I 01/01/1900 31/12/3000
MANAGERS ‘StockUnitRolloverTPService I 01/01/1900 31/12/3000
MANAGERS UnlockBranchService I 01/01/1900 31/12/3000
MANAGERS UnlockStockUnitService I 01/01/1900 31/12/3000
MANAGERS UpdateChecksumService I 01/01/1900 31/12/3000
MANAGERS UpdateCutOffReportService I 01/01/1900 31/12/3000
MANAGERS UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
MANAGERS ValidateChecksumService I 01/01/1900 31/12/3000
MANAGERS banking I 01/01/1900 31/12/3000
MANAGERS recoveryService I 01/01/1900 31/42/3000
MIGRATE AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
MIGRATE AttachUserToStockUnitService I 01/01/1900 31/12/3000
MIGRATE BasketSettlementService I 01/01/1900 31/12/3000
MIGRATE ChangeUserOptionsService I 01/01/1900 31/12/3000
MIGRATE ChangeUserRoleService I 01/01/1900 31/12/3000
MIGRATE CloseBranchUserAccountService I 01/01/1900 31/12/3000
MIGRATE CreateBranchUser I 01/01/1900 31/12/3000
MIGRATE CutOffDespatchReportService I 01/01/1900 31/12/3000
MIGRATE CutOffReportService I 01/01/1900 31/12/3000
MIGRATE DownloadDeliveryService I 01/01/1900 31/12/3000
MIGRATE GenericOnlineService I 01/01/1900 31/12/3000
MIGRATE GetBranchTradingPeriodService I 01/01/1900 31/12/3000
MIGRATE GetOutstandingDeclarations I 01/01/1900 31/12/3000
MIGRATE GetValidationCharacter I 01/01/1900 31/12/3000
MIGRATE IsVRMValid I 01/01/1900 31/12/3000
MIGRATE LabelEventService I 01/01/1900 31/12/3000
MIGRATE LockBranchService I 01/01/1900 31/42/3000
MIGRATE LockStockUnitService I 01/01/1900 31/12/3000
MIGRATE PackagelnventoryService I 01/01/1900 31/12/3000
MIGRATE PollingService I 01/01/1900 31/12/3000
MIGRATE ReconcileBarCodesService I 01/01/1900 31/12/3000
MIGRATE RecordStockDeclarations I 01/01/1900 31/12/3000
MIGRATE ReportingService I 01/01/1900 31/12/3000
MIGRATE RolloverBranchService I 01/01/1900 31/12/3000
MIGRATE SecureExistingReversalService I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 188 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
MIGRATE ‘SetPasswordOnline I 01/01/1900 31/12/3000
MIGRATE SetPasswordOtherUser I 01/01/1900 31/12/3000
MIGRATE StockUnitManagement I 01/01/1900 31/12/3000
MIGRATE StockUnitRolloverBPService I 01/01/1900 31/12/3000
MIGRATE StockUnitRolloverTPService I 01/01/1900 31/12/3000
MIGRATE UnlockBranchService I 01/01/1900 31/12/3000
MIGRATE UnlockStockUnitService I 01/01/1900 31/12/3000
MIGRATE UpdateChecksumService I 01/01/1900 31/12/3000
MIGRATE UpdateCutOffReportService I 01/01/1900 31/12/3000
MIGRATE UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
MIGRATE, ValidateChecksumService I 01/01/1900 31/12/3000
MIGRATE banking I 01/01/1900 31/42/3000
MIGRATE recoveryService I 01/01/1900 31/12/3000
SETUP AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
SETUP AttachUserToStockUnitService I 01/01/1900 31/12/3000
SETUP BasketSettlementService I 01/01/1900 31/12/3000
SETUP ChangeUserOptionsService I 01/01/1900 31/12/3000
SETUP ChangeUserRoleService I 01/01/1900 31/12/3000
SETUP CloseBranchUserAccountService I 01/01/1900 31/12/3000
SETUP CreateBranchUser I 01/01/1900 31/12/3000
SETUP CutOffDespatchReportService I 01/01/1900 31/12/3000
SETUP CutOffReportService I 01/01/1900 31/12/3000
SETUP GenericOnlineService I 01/01/1900 31/12/3000
SETUP GetBranchTradingPeriodService I 01/01/1900 31/12/3000
SETUP GetOutstandingDeclarations I 01/01/1900 31/12/3000
SETUP GetValidationCharacter I 01/01/1900 31/12/3000
SETUP IsVRMValid I 01/01/1900 31/12/3000
SETUP LabelEventService I 01/01/1900 31/12/3000
SETUP LockBranchService I 01/01/1900 31/42/3000
SETUP LockStockUnitService I 01/01/1900 31/12/3000
SETUP PackagelnventoryService I 01/01/1900 31/12/3000
SETUP PollingService I 01/01/1900 31/12/3000
SETUP ReconcileBarCodesService I 01/01/1900 31/12/3000
SETUP RecordStockDeclarations I 01/01/1900 31/12/3000
SETUP ReportingService I 01/01/1900 31/12/3000
SETUP RolloverBranchService I 01/01/1900 31/12/3000
SETUP SecureExistingReversalService I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 189 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
SETUP ‘SetPasswordOnline I 01/01/1900 31/12/3000
SETUP SetPasswordOtherUser I 01/01/1900 31/12/3000
SETUP StockUnitManagement I 01/01/1900 31/12/3000
SETUP StockUnitRolloverBPService I 01/01/1900 31/12/3000
SETUP StockUnitRolloverTPService I 01/01/1900 31/12/3000
SETUP UnlockBranchService I 01/01/1900 31/12/3000
SETUP UnlockStockUnitService I 01/01/1900 31/12/3000
SETUP UpdateChecksumService I 01/01/1900 31/12/3000
SETUP UpdateCutOffReportService I 01/01/1900 31/12/3000
SETUP ValidateChecksumService I 01/01/1900 31/12/3000
SETUP banking I 01/01/1900 31/12/3000
SETUP recoveryService I 01/01/1900 31/42/3000
SUPERVISORS AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
SUPERVISORS AttachUserToStockUnitService I 01/01/1900 31/12/3000
SUPERVISORS BasketSettlementService I 01/01/1900 31/12/3000
SUPERVISORS CutOffDespatchReportService I 01/01/1900 31/12/3000
SUPERVISORS CutOffReportService I 01/01/1900 31/12/3000
SUPERVISORS DownloadDeliveryService I 01/01/1900 31/12/3000
SUPERVISORS GenericOnlineService I 01/01/1900 31/12/3000
SUPERVISORS GetBranchTradingPeriodService I 01/01/1900 31/12/3000
SUPERVISORS GetOutstandingDeclarations I 01/01/1900 31/12/3000
SUPERVISORS GetValidationCharacter I 01/01/1900 31/12/3000
SUPERVISORS IsVRMValid I 01/01/1900 31/12/3000
SUPERVISORS LabelEventService I 01/01/1900 31/12/3000
SUPERVISORS LockBranchService I 01/01/1900 31/12/3000
SUPERVISORS LockStockUnitService I 01/01/1900 31/12/3000
SUPERVISORS PackagelnventoryService I 01/01/1900 31/12/3000
SUPERVISORS PollingService I 01/01/1900 31/12/3000
SUPERVISORS ReconcileBarCodesService I 01/01/1900 31/42/3000
SUPERVISORS RecordStockDeclarations I 01/01/1900 31/12/3000
SUPERVISORS ReportingService I 01/01/1900 31/12/3000
SUPERVISORS RolloverBranchService I 01/01/1900 31/12/3000
SUPERVISORS SecureExistingReversalService I 01/01/1900 31/12/3000
SUPERVISORS SetPasswordOnline I 01/01/1900 31/12/3000
SUPERVISORS StockUnitRolloverBPService I 01/01/1900 31/12/3000
SUPERVISORS StockUnitRolloverTPService I 01/01/1900 31/12/3000
SUPERVISORS UnlockBranchService I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 190 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
SUPERVISORS UnlockStockUnitService I 01/01/1900 31/12/3000
SUPERVISORS UpdateChecksumService I 01/01/1900 31/12/3000
SUPERVISORS UpdateCutOffReportService I 01/01/1900 31/12/3000
SUPERVISORS UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
SUPERVISORS ValidateChecksumService I 01/01/1900 31/12/3000
SUPERVISORS banking I 01/01/1900 31/12/3000
SUPERVISORS recoveryService I 01/01/1900 31/12/3000
SUPPORT AttachUserToStockUnitService I 01/01/1900 31/12/3000
SUPPORT ChangeUserOptionsService I 01/01/1900 31/12/3000
SUPPORT ChangeUserRoleService I 01/01/1900 31/12/3000
SUPPORT CloseBranchUserAccountService I 01/01/1900 31/12/3000
SUPPORT CreateBranchUser I 01/01/1900 31/42/3000
SUPPORT SetPasswordOnline I 01/01/1900 31/12/3000
SUPPORT SetPasswordOtherUser I 01/01/1900 31/12/3000
TRAINER AddValidPouchesToCollGroupSve I 01/01/1900 31/12/3000
TRAINER AttachUserToStockUnitService I 01/01/1900 31/12/3000
TRAINER BasketSettlementService I 01/01/1900 31/12/3000
TRAINER ChangeUserOptionsService I 01/01/1900 31/12/3000
TRAINER ChangeUserRoleService I 01/01/1900 31/12/3000
TRAINER CloseBranchUserAccountService I 01/01/1900 31/12/3000
TRAINER CreateBranchUser I 01/01/1900 31/12/3000
TRAINER CutOffDespatchReportService I 01/01/1900 31/12/3000
TRAINER CutOffReportService I 01/01/1900 31/12/3000
TRAINER DownloadDeliveryService I 01/01/1900 31/12/3000
TRAINER GenericOnlineService I 01/01/1900 31/12/3000
TRAINER GetBranchTradingPeriodService I 01/01/1900 31/12/3000
TRAINER GetOutstandingDeclarations I 01/01/1900 31/12/3000
TRAINER GetValidationCharacter I 01/01/1900 31/12/3000
TRAINER IsVRMValid I 01/01/1900 31/42/3000
TRAINER LabelEventService I 01/01/1900 31/12/3000
TRAINER LockBranchService I 01/01/1900 31/12/3000
TRAINER LockStockUnitService I 01/01/1900 31/12/3000
TRAINER PackagelnventoryService I 01/01/1900 31/12/3000
TRAINER PollingService I 01/01/1900 31/12/3000
TRAINER ReconcileBarCodesService I 01/01/1900 31/12/3000
TRAINER RecordStockDeclarations I 01/01/1900 31/12/3000
TRAINER ReportingService I 01/01/1900 31/12/3000
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 191 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design -
FUJITSU COMMERCIAL-IN-CONFIDENCE
Branch Role Branch Service Name Start Date End Date
TRAINER ResetTrainingData I 01/01/1900 31/12/3000
TRAINER RolloverBranchService I 01/01/1900 31/12/3000
TRAINER SecureExistingReversalService I 01/01/1900 31/12/3000
TRAINER SetPasswordOnline I 01/01/1900 31/12/3000
TRAINER SetPasswordOtherUser I 01/01/1900 31/12/3000
TRAINER StockUnitManagement I 01/01/1900 31/12/3000
TRAINER StockUnitRolloverBPService I 01/01/1900 31/12/3000
TRAINER, StockUnitRolloverTPService I 01/01/1900 31/12/3000
TRAINER UnlockBranchService I 01/01/1900 31/12/3000
TRAINER UnlockStockUnitService I 01/01/1900 31/12/3000
TRAINER UpdateChecksumService I 01/01/1900 31/12/3000
TRAINER UpdateCutOffReportService I 01/01/1900 31/12/3000
TRAINER UpdatePSBarcodesStateService I 01/01/1900 31/12/3000
TRAINER ValidateChecksumService I 01/01/1900 31/12/3000
TRAINER banking I 01/01/1900 31/12/3000
TRAINER recoveryService I 01/01/1900 31/12/3000
Table 28 - BRDB_BRANCH_SERVICES Meta Data
©Copyright Fujitsu Services Ltd 2009 ‘COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 192 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
22 Appendix E -— Suggested Oracle Initialisation
Parameters
This section provides the minimum recommended values for certain initialisation parameters for the
Branch Database and the Branch Standby Database.
22.1 Branch Database Parameters
22.1.1 Core Parameters
DB_NAME BRDB Name of the Branch Database
DB_BLOCK_SIZE 8KB DB_BLOCK_SIZE specifies (in kilo bytes) the size of Oracle database
blocks.
The value of this parameter must be a multiple of the physical block size
at the device level (512 bytes).
Table 29 -Core BRDB Initialisation Parameters
22.1.2 Listener Configuration Parameters
Val
LOCAL_LISTENER “LISTENER_hostn I Name of the Listener that the Branch Database instance registers itself
ame” with.
Table 30 —Net Services specific Initialisation Parameters
22.1.3. Tuning related Parameters
22.1.3.1. Instance Tuning
The performance of an Oracle RAC cluster is heavily dependent on the values of database tuning
parameters. The following parameters are amongst the most important from a tuning perspective and
their recommended minimum values are listed below:
ARCHIVE_LAG_TARGET 900 Ensures that the Branch Standby Database lags no more than 15
minutes behind the Branch Database.
COMPATIBLE 10.2.0.4.0 This parameter specifies the release with which Oracle must maintain
compatibility.
CONTROL_FILE_RECORD_KE I 21 Needed for RMAN repository records
EP_TIME
DB_BLOCK_SIZE 8KB DB_BLOCK_SIZE specifies (in bytes) the size of Oracle database
blocks. The value of this parameter must be a multiple of the physical
block size at the device level (512 bytes?).
DB_FILE_MULTIBLOCK_READ I 16 High value ensures that more number of blocks are read in a single 1/0
_COUNT operation during a sequential read thus improving full-table-scan
performance. The high setting is especially useful for Counter
Reporting, stock queries and rollovers.
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 193 of 197
FUJ00235023
FUJ00235023
oO Branch Database High Level Design r ~
FUJITSU COMMERCIAL-IN-CONFIDENCE didi
DB_WRITER_PROCESSES
1 db-writer process
FAST_START_PARALLEL_RO I HIGH Parameter determines the maximum number of processes that can exist
LLBACK for performing parallel rollback.
The HIGH setting will allow faster instance recovery from failures.
OPEN_CURSORS 1024 Set to a high value to allow the BAL to maintain higher number of
cursors open
OPEN_LINKS 16 Required for database links.
PGA_AGGREGATE_TARGET I 5GB 5GB allows for an average of just over 1 MB per connection (at
maximum connections) and 2MB at average number of connections.
PROCESSES 2048 Set to a high value to allow for high values of other derived parameters.
SGA_TARGET 20GB A large SGA size will ensure that more data remains in the cache thus
improving performance of token authentication and counter reporting,
amongst other things.
SKIP_UNUSABLE_INDEXES TRUE This will allow processes performing DML operations to continue
unchanged if any index partitions or sub-partitions need to be disabled
at a later stage.
TIMED_STATISTICS TRUE The Athene Metron performance monitoring software requires this
parameter to be set
Table 31 - Instance Tuning specific BRDB Initialisation Parameters
22.1.3.2 Database Tuning
FAST_START_MTTR_TARGET I 60 Based on this parameter value, Oracle works out the
db_block_max_dirty_target, which tells DBWR not to have more than
certain amount of dirty blocks in the buffers.
DB_BLOCK SIZE 8KB DB_BLOCK SIZE specifies (in bytes) the size of Oracle database
blocks. The value of this parameter must be a multiple of the physical
block size at the device level (512 bytes).
A block size of 8K is a nice balance between the 4K value
recommended by Oracle for store & forward systems and 16K value for
DSS-type systems.
UNDO_MANAGEMENT AUTO This is mandatory when using ASM
Would not choose to use Rollback Segments anyway.
UNDO_RETENTION 900 Set to a (relatively) low value, as there are very few long running
queries in the Branch Database. Low undo retention will help free up
space in the UNDO tablespaces more quickly.
Table 32 — Database Tuning specific BRDB Initialisation Parameters
22.1.4 Parameters for Standby Implementation
DB_UNIQUE_NAME BRDB Unique name for primary database
DG_BROKER_START TRUE Allows the Data Guard Broker to start functioning
DB_BROKER_CONFIG FILE’ I Actual values to I The first copy of the Data Guard Broker Configuration file resides within
be provided by I ASM
Development.
DB_BROKER_CONFIG FILE’ I Actual values to I Second copy of the Data Guard Broker Configuration file resides
be provided by outside ASM on the OCFS managed file system.
©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref: DES/APP/HLD/0020
Version: V1.0
Date: 47-Nov-2009
Page No: 194 of 197
FUJITSU
FUJ00235023
FUJ00235023
Branch Database High Level Design -
COMMERCIAL-IN-CONFIDENCE
“Development.
DB_FILE_NAME_CONVERT The value can be left as NULL as the Diskgroup names will be identical
since the storage for BRDB and STBY will be managed by different
ASM instances.
JOB_QUEUE PROCESSES I 64 Used for oracle job maintenance windows.
FAL_SERVER SBRDB Specifies the network service name that the standby database should
Use to connect to the FAL server.
FAL_CLIENT BROB Specifies the network service name that the FAL server should use to
connect to the standby database.
LOG_ARCHIVE_CONFIG "DG_CONFIG=(B I Enables the transmission of redo logs to the standby database
RDB,SBRDB)
LOG_ARCHIVE_DEST_1 Actual values to I This is used to specify the destination of the archived redo-logs to assist
be provided by _I in BRDB recovery. Use ASM disk group BRDB_FLASH for location
Development.
Use parameters MANDATORY, VALID_FOR=(ALL_LOGFILES,
ALL_ROLES).
This parameter has nothing to do with replication to standby.
LOG_ARCHIVE_DEST_2
Actual values to
be provided by
Development.
SERVICE should point to the single node standby instance (STBY1).
Use parameters OPTIONAL, VALID_FOR=(ONLINE_LOGFILE,
PRIMARY_ROLE)
Use LGWR ASYNC NOAFFIRM
LOG_ARCHIVE_FORMAT
‘prdb_%T_%S_%
Rare’
%S corresponds to the sequence number (zero-filled) and %R.
corresponds to the reset-logs ID. The %T, which is Real Application
Clusters specific, corresponds to the thread number (zero-filled),
SSES
LOG_ARCHIVE_MAX_PROCE I 4
‘Specify more than 4 to allow for high archive workload at peak
transaction times.
LOG_FILE_NAME_CONVERT
The value can be left as NULL as the Diskgroup names will be identical
since the storage for BRDB and STBY will be managed by different
ASM instances.
STANDBY_FILE_MANAGEMEN I AUTO
Es
Ensures that when datafiles are added to or dropped from the primary
database, corresponding changes are made automatically to the
standby database.
Table 33 - Standby Database specific BRDB Initialisation Parameters
22.1.5 Parameters for Streams Replication
Va
GLOBAL_NAMES.
TRUE
Needs to be set to this value for every database participating in Streams
replication.
Table 34 — Streams Replication specific BRDB Initialisation Parameters
22.2 Branch Standby Database Parameters
Set the following initialization parameters for the Branch Standby Database (in addition to the ones
already present):
COMPATIBLE
10.2.0.4.0
This parameter specifies the release with which Oracle must maintain
compatibility.
Copyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE, Ref: DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 195 of 197
FUJITSU
FUJ00235023
FUJ00235023
Branch Database High Level Design -
COMMERCIAL-IN-CONFIDENCE
DB_BLOCK_SIZE
8KB
DB_BLOCK_SIZE specifies (in kilo bytes) the size of Oracle database
blocks.
Set to same value as primary.
DB_BROKER_CONFIG_FILE1
‘Actual values to
be provided by
Development.
The first copy of the Data Guard Broker Configuration file resides within
ASM
DB_BROKER_CONFIG_FILE1
Actual values to
Second copy of the Data Guard Broker Configuration file resides
be provided by —_I outside ASM on the OCFS managed file system
Development.
DB_FILE_NAME_CONVERT The value can be left as NULL as the Diskgroup names will be identical
since the storage for BRDB and STBY will be managed by different
ASM instances.
DB_NAME BRDB Same name to be used across databases replicated using DataGuard
DB_UNIQUE_NAME SBRDB Unique name for standby database
DG_BROKER_START TRUE Allows the Data Guard Broker to start functioning
FAL_SERVER BRDB, Specifies the network service name that the standby database should
Use to connect to the FAL server.
FAL_CLIENT ‘(DESCRIPTION=( I Specifies the network service name that the FAL server should use to
ADDRESS_LIST=
(ADDRESS=(PRO
PORT=IBD)) I
CONNECT_DAT
A=(SERVICE_NA
ME=SBRDB_XPT)
(INSTANCE NAM
E=SBRDB1)(SER
VER=dedicated)))'
connect to the standby database.
INSTANCE_NAME (1)
SBRDB
The instance names of the standby nodes are unique while in standby
mode. Once the standby takes on primary responsibilities, its instance
names need to change to BRDB‘...4 and the instance names of the old
primary (new standby) should change to STBY1...4.
LOG_ARCHIVE_CONFIG
‘DG_CONFIG=(SB
RDB,BRDB)
LOG_ARCHIVE_DEST_1 Actual values to I This is used to specify the destination of the archived redo-logs to assist
be provided by in recovering the standby database. Use ASM disk group
Development. BRDB_FLASH for location.
Use parameters MANDATORY, VALID_FOR=(ALL_LOGFILES,
ALL_ROLES).
This parameter has nothing to do with data guard replication from the
Branch Database
LOG_ARCHIVE_DEST_2
Parameter does not need to be specified. In the event of a corruption of
the Standby database along with the loss of the Archive log files, the
database will be recreated from Live.
LOG_ARCHIVE_FORMAT
‘brdb_%T_%S_%
R.arc
%S corresponds to the sequence number (zero-filled) and %R
corresponds to the reset-logs ID. The %T, which is Real Application
Clusters specific, corresponds to the thread number (zero-filled),
LOG_FILE_NAME_CONVERT
The value can be left as NULL as the Diskgroup names will be identical
since the storage for BRDB and STBY will be managed by different
ASM instances.
SGA_TARGET
20GB
A large SGA size will ensure that more data remains in the cache thus
improving performance of token authentication and counter reporting,
amongst other things.
STANDBY_FILE_MANAGEMEN
T
AUTO
Ensures that when data files are added to or dropped from the primary
database, corresponding changes are made automatically to the
SCopyright Fujitsu Services Ltd 2009
‘COMMERCIAL-IN-CONFIDENCE,
Ref.
Version
Date:
Page No:
DES/APP/HLD/0020
V1.0
17-Nov-2009
196 of 197
FUJ00235023
FUJ00235023
Branch Database High Level Design
oO
FUJITSU COMMERCIAL-IN-CONFIDENCE
standby database.
Table 35 -BRDB-Standby Initialisation Parameters
In addition, log and archived-redo log file name conversion must be set up to conform to the file naming
conventions.
22.3 Role Reversal Parameter Changes
Branch Database and Branch Database Standby role reversal is covered in the Branch Database
Support Guide, See Ref [R43].
‘©Copyright Fujitsu Services Ltd 2009 COMMERCIAL-IN-CONFIDENCE Ref. DES/APP/HLD/0020
Version: V1.0
Date: 17-Nov-2009
Page No: 197 of 197