Managing Persisted Data in the Oracle Database

Enabling Persistence in ECE

You can set up ECE to persist its cache data in the Oracle database, creating a permanent backup of the cache in case a node fails, a partition is lost, or so on. ECE automatically recovers the cache data from the persistence database when it is needed.

When persistence is enabled, the ECE core components, such as Customer Updater, Pricing Updater, and configLoader, persist the following at start up:

The data published from BRM and PDC into ECE cache
The mediation specification data loaded into ECE cache
The data that is synchronized or received from BRM
Other data such as balance, top-up history, recurring bundle history, rated events, and Portal object IDs (POIDs)

During installation, upgrade, auto-recovery, and pod restart, ECE uses the Kubernetes REST API to:

Automatically update the charging-settings-namespace ConfigMap to enable reloading of cache data from the persistence database
Retrieve the metadata from ECE statefulsets and pods
Automatically apply management labels to ecs pods

To configure ECE cloud native for persistence:

Configure ECE to reload cache data, retrieve metadata, and apply management labels during installation, upgrade, auto-recovery, and pod restart. To do so, configure the ece-namespace service account to authenticate the API server.

For information about the rules defined in the role-based access control (RBAC) ece-namespace, see the ece-clusterrole-sa.yaml file in the ECE Helm chart.

Enable and configure persistence in ECE cloud native. To do so, set these keys in the override-values.yaml file for oc-cn-ece-helm-chart:

Note:

Ensure the persistence tablespace names are all uppercase.

secretEnv:
   PERSISTENCEDATABASEPASSWORD:
     - schema: 1
       PASSWORD: password
   PERSISTENCEDBAPASSWORD:
     - schema: 1
       PASSWORD: password     # SYSDBA user
   PERSISTENCEDATABASEKEYPASS:
     - schema: 1
       PASSWORD: password
charging:
   persistenceEnabled: "true"
   cachePersistenceConfigurations:
      cachePersistenceConfigurationList:
         - clusterName: "BRM"
           persistenceStoreType: "OracleDB"
           persistenceConnectionName: "oraclePersistence1"
           reloadThreadPoolSize: "10"
           configLoadFromPersistence: "true"
           pricingLoadFromPersistence: "true"
           customerLoadFromPersistence: "true"
           partitionLossRecoverFromPersistence: "true"
           writeBehindThreadPoolSize: "1"
   connectionConfigurations:
      OraclePersistenceConnectionConfigurations:
         - clusterName: "BRM"
           schemaNumber: "1"
           name: "oraclePersistence1"
           dbSysDBAUser: "sys"
           dbSysDBARole: "sysdba"
           userName: "ece"
           hostName: ""
           port: "1521"
           sid: ""
           service: ""
           tablespace: "ECETABLE"
           temptablespace: "ECETEMP"
           cdrstoretablespace: "ECECDRTABLESPACE"
           cdrstoreindexspace: "ECECDRINDEXSPACE"
           jdbcUrl: ""
           retryCount: "3"
           retryInterval: "1"
           maxStmtCacheSize: "100"
           connectionWaitTimeout: "300"
           timeoutConnectionCheckInterval: "300"
           inactiveConnectionTimeout: "300"
           databaseConnectionTimeout: "600"
           persistenceInitialPoolSize: "4"
           persistenceMinPoolSize: "4"
           persistenceMaxPoolSize: "12"
           reloadInitialPoolSize: "0"
           reloadMinPoolSize: "0"
           reloadMaxPoolSize: "20"
           dbSSLEnabled: "true"
           dbSSLType: "twoway"
           sslServerCertDN: "DC=local,DC=oracle,CN=pindb"
           trustStoreLocation: "/home/charging/ext/ece_ssl_db_wallet/schema1/cwallet.sso"
           trustStoreType: "SSO"
           walletLocation: "/home/charging/wallet/ecewallet/"
           cdrStorePartitionCount: "32"
           queryTimeout: "5"

When you deploy oc-cn-ece-helm-chart with this configuration, the Helm chart creates a schema user if one doesn't already exist, creates ECE tables, creates indexes, and runs stored procedures.

To see the ECE deployment logs, run this command:

kubectl logs -f EcePersistenceJobPod -n BrmNameSpace

where EcePersistenceJobPod is the name of the pod where ece-persistence-job is deployed, and BrmNameSpace is the name space in which to create BRM Kubernetes objects for the BRM Helm chart.

Re-Creating the ECE Schema After Deployment

If you want to re-create the ECE schema, any table, or any index after the ECE Helm chart is already deployed, do the following:

Delete the ECE Helm chart.
Delete the pre-existing ece-persistence-job from your system by running this command:
```
kubectl delete job ece-persistence-job -n BrmNameSpace
```
Install the Helm chart again by running the following command:
```
helm install ece -n BrmNameSpace oc-cn-ece-helm-chart [--no-hooks]
```
Note:

Include the --no-hooks argument only if everything needed for persistence is already in the persistence database.

Loading Only Partial Data into ECE Cache

You can optionally configure ECE to load only partial data from the persistence database into the ECE cache. In this case, the initial load of data into ECE cache includes data only up to a specified minimum amount (back-low-limit). If the data required for processing a usage request is not available in the ECE cache, ECE loads that data into the ECE cache from the persistence database and evicts some other data from the ECE cache. This ensures that the maximum limit (back-high-limit) is not exceeded. Later, when you restart the ECE system, ECE loads the most recently used data into the ECE cache.

For more information, see "Enabling Partial Loading of Data" in BRM System Administrator's Guide.

To load only partial data into ECE cache, set these parameters for the charging-cache-config-persistence.xml file in the oc-cn-ece-helm-chart/templates/charging-settings.yaml ConfigMap:

back-high-limit: The maximum amount of data that can be loaded into the ECE cache.
back-low-limit: The minimum amount of data that can be loaded or reloaded into the ECE cache from the persistence database.

Incremental Customer Loading in ECE Cache

By default, the customerupdater pod loads all customer data from the BRM database into ECE cache at start up, but you can configure the pod to load customer data incrementally.

To incrementally load customer data into ECE cache:

Configure the customerupdater pod to load only an initial set of customers into ECE cache and bring ECE to the UsageProcessing state by setting these keys in the override-values.yaml file for oc-cn-ece-helm-chart:
- job.customerloader.runjob: Set this to false.
- charging.incrementalCustomerLoad: Set this to true.
- migration.loader.initialCustomerLoadFilterQuery: Set this to a query such as "and ROWNUM <= 1" to load one customer.
Install the ECE Helm chart.
Load the remaining customers incrementally into ECE cache by setting these keys in the override-values.yaml file for oc-cn-ece-helm-chart:
- job.customerloader.runjob: Set this to true.
- job.customerloader.command: Set this to -incremental customer_updater_schema_name, where customer_updater_schema_name is the schema name specified for the customerupdater pod.
- charging.incrementalCustomerLoad: Set this to true.
- migration.loader.incrementalCustomerLoadFilterQuery: Set this to a query such as "and POID_ID0 NOT IN (select POID_ID0 from ACCOUNT_T where POID_ID0 <> 1 and ROWNUM <= 1)" to load remaining customers.
Perform a Helm upgrade by running this command:
```
helm upgrade EceReleaseName oc-cn-ece-helm-chart --values OverrideValuesFile -n BrmNameSpace
```
where EceReleaseName is the release name for oc-cn-ece-helm-chart and is used to track this installation instance, and OverrideValuesFile is the path to the YAML file that overrides the default configurations in the chart's values.yaml file.