Manage the TimesTen Databases

The Operator strives to keep your active standby pair of databases running once they are deployed. Kubernetes manages the lifecycle of the Pods. It recreates the Pods if they fail. It also recreates the Pods on available Kubernetes cluster nodes, if the nodes on which the Pods are running fail. The Operator monitors TimesTen running in the Pods, and initiates the appropriate operations to keep the pair of databases operational. These operations are done automatically by the Operator, and should require minimal human intervention.

These sections discuss the manual operations you can perform:

• Manually Invoke TimesTen Utilities

• Modify TimesTen Connection Attributes

• Revert to Manual Control

• Delete an Active Standby Pair of TimesTen Databases

Manually Invoke TimesTen Utilities

You can use the kubectl exec -it command to manually invoke TimesTen utilities on your TimesTen instances. This command invokes shells in the Pods and enables you to control the running of TimesTen in the Pods.

TimesTen runs in the tt container, as the timesten user.

Note:

The Operator is still querying the status of the Pod, and the status of TimesTen within the Pod. If you invoke a command that disrupts the functioning of either the Pod or TimesTen, the Operator may act to try to fix what you did.

This example shows how to use the kubectl exec -it command to invoke the shell within the sample-0 Pod that contains the TimesTen database. Then, you can run the ttIsql utility.

% kubectl exec -it sample-0 -c tt -- /bin/bash
% ttIsql sample
 
Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
Type ? or "help" for help, type "exit" to quit ttIsql.
 
 
 
connect "DSN=sample";
Connection successful:
DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=200;
DDLReplicationLevel=3;
(Default setting AutoCommit=1)

Modify TimesTen Connection Attributes

TimesTen uses connection attributes to define the attributes of a database. There are three types of connection attributes:

• Data store attributes: Define the characteristics of a database that can only be changed by destroying and recreating the database.

• First connection attributes: Define the characteristics of a database that can be changed by unloading and reloading the database into memory.

• General connection attributes: Control how applications access the database. These attributes persist for the duration of the connection.

For more information on TimesTen connection attributes, see List of Connection Attributes in the Oracle TimesTen In-Memory Database Reference and Connection Attributes for Data Manager DSNs or Server DSNs in the Oracle TimesTen In-Memory Database Operations Guide.

In a Kubernetes environment:

• You can only modify data store attributes by deleting the TimesTenClassic object and the PersistentVolumeClaims associated with the TimesTenClassic object. Doing so results in the deletion of the TimesTen databases. See Delete an Active Standby Pair of TimesTen Databases and Clean Up for information on the deletion process.

• You can modify first connection and general connection attributes without deleting the TimesTenClassic object (which deletes the databases) and the PersistentVolumeClaims associated with the TimesTenClassic object. Note that there are TimesTen restrictions when modifying some of the first connection attributes.

To modify first or general connection attributes:

• You must first edit the db.ini file. Complete the procedure in the Manually Edit the db.ini File section. This section must be completed first.

Then, take these steps:

• If you are modifying first connection attributes, follow the procedure in the Modify First Connection Attributes section.

• If you are modifying general connection attributes, follow the procedure in the Modify General Connection Attributes section.

Manually Edit the db.ini File

Complete this section if you are modifying first or general connection attributes or both. This section must be completed before proceeding to the Modify First Connection Attributes or the Modify General Connection Attributes sections.

To modify first or general connection attribute requires a change in the sys.odbc.ini file.

If you have already created your active standby pair of TimesTen databases by creating a TimesTenClassic object, and you now want to change one or more first or general connection attributes in your sys.odbc.ini file, you must change the db.ini file.

The details as to how you should modify your db.ini file depends on the facility originally used to contain the db.ini file. (Possible facilities include ConfigMaps, Secrets, or init containers. See Populate the /ttconfig Directory for details.)

In this example, the ConfigMap facility was originally used to contain the db.ini file and to populate the /ttconfig directory of the TimesTen containers. The example modifies the sample ConfigMap.

The steps are:

1. Use the kubectl describe command to review the contents of the db.ini file (represented in bold) located in the original sample ConfigMap.

   % kubectl describe configmap sample
   Name:         sample
   Namespace:    mynamespace
   Labels:       <none>
   Annotations:  <none>
    
   Data
   ====
   adminUser:
   ----
   sampleuser/samplepw
    
   db.ini:
   ----
   PermSize=200
   DatabaseCharacterSet=AL32UTF8
   ConnectionCharacterSet=AL32UTF8
   
   schema.sql:
   ----
   create sequence sampleuser.s;
   create table sampleuser.emp (id number not null primary key, name char (32));
    
   Events:  <none>
   

2. Use the kubectl edit command to modify the db.ini file in the original sample ConfigMap. Change the PermSize first connection attribute to 600 (represented in bold). Add the TempSize first connection attribute and set its value to 300 (represented in bold). Add the ConnectionCharacterSet connection attribute.

   % kubectl edit configmap sample
   # Please edit the object below. Lines beginning with a '#' will be ignored,
   # and an empty file will abort the edit. If an error occurs while saving this 
   # file will be reopened with the relevant failures.
   #
   apiVersion: v1
   data:
     adminUser: |
       sampleuser/samplepw
     db.ini: |
       PermSize=600
       TempSize=300
       DatabaseCharacterSet=AL32UTF8
       ConnectionCharacterSet=AL32UTF8
     schema.sql: |
       create sequence sampleuser.s;
       create table sampleuser.emp (id number not null primary key, name char (32));
   kind: ConfigMap
   metadata:
     creationTimestamp: "2023-04-30T19:23:59Z"
     name: sample
     namespace: mynamespace
     resourceVersion: "71907255"
     selfLink: /api/v1/namespaces/mynamespace/configmaps/sample 
    uid: 0171ff7f-f789-11ea-82ad-0a580aed0453
   ...
   configmap/sample edited
   

3. Use the kubectl describe command to verify the changes to the sample ConfigMap. (The changes are represented in bold.)

   % kubectl describe configmap sample
   Name:         sample
   Namespace:    mynamespace
   Labels:       <none>
   Annotations:  <none>
    
   Data
   ====
   schema.sql:
   ----
   create sequence sampleuser.s;
   create table sampleuser.emp (id number not null primary key, name char (32));
    
   adminUser:
   ----
   sampleuser/samplepw
    
   db.ini:
   ----
   PermSize=600
   TempSize=300
   DatabaseCharacterSet=AL32UTF8
   ConnectionCharacterSet=AL32UTF8
    
   Events:  <none>
   

You have successfully changed the sample ConfigMap. If you are modifying first connection attributes, proceed to the Modify First Connection Attributes section. If you are modifying only general connection attributes, proceed to the Modify General Connection Attributes section.

Modify First Connection Attributes

If you have not modified the db.ini file, proceed to the Manually Edit the db.ini File section. You must now delete the standby Pod and then delete the active Pod. When you delete a Pod that contains a container running TimesTen, the Operator creates a new Pod to replace the deleted Pod. This new Pod contains a new sys.odbc.ini file which is created from the contents of the db.ini file located in the /ttconfig directory.

Perform these steps to delete the standby Pod.

1. Use the kubectl get command to determine which Pod is the standby Pod for the sample TimesTenClassic object. The active Pod is the Pod represented in the ACTIVE column. The standby Pod is the other Pod (not represented in the ACTIVE column). Therefore, for the sample TimesTenClassic object, the active Pod is sample-0, (represented in bold) and the standby Pod is sample-1.

   % kubectl get ttc sample
   NAME     STATE    ACTIVE     AGE
   sample   Normal   sample-0   47h
   

2. Delete the standby Pod (sample-1, in this example). This results in the Operator creating a new standby Pod to replace the deleted Pod. When the new standby Pod is created, it will use the newly modified sample ConfigMap. (You modified this ConfigMap in the Manually Edit the db.ini File section.)

   % kubectl delete pod sample-1
   pod "sample-1" deleted
   

3. Use the kubectl get command to verify the standby Pod is up and running and the state is Normal.

   Note that the state is StandbyDown (represented in bold).

   % kubectl get ttc sample
   NAME     STATE         ACTIVE     AGE
   sample   StandbyDown   sample-0   47h
   

   Wait a few minutes, then run the command again. Note that the state has changed to Normal (represented in bold).

   % kubectl get ttc sample
   NAME     STATE    ACTIVE     AGE
   sample   Normal   sample-0   47h
   

4. Use the kubectl exec -it command to invoke the shell in the standby Pod (sample-1, in this example). Then, run the ttIsql utility to connect to the sample database. Note the new PermSize value of 600 and the new TempSize value of 300 in the connection output (represented in bold).

   % kubectl exec -it sample-1 -c tt -- /bin/bash
   % ttIsql sample 
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved. 
   Type ? or "help" for help, type "exit" to quit ttIsql. 
   connect "DSN=sample"; 
   Connection successful:  
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
   AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3;
   ForceDisconnectEnabled=1; 
   (Default setting AutoCommit=1)
   

5. Fail over from the active Pod to the standby Pod. See "Fail Over" for details of the fail over process. Before you begin this step, ensure you quiesce your applications and you use the ttRepAdmin -wait command to wait until replication is caught up, such that all transactions that were executed on the active database have been replicated to the standby database. Once the standby is caught up, fail over from the active database to the standby by deleting the active Pod. When you delete the active Pod, the Operator automatically detects the failure and promotes the standby database to be the active.

   Delete the active Pod (sample-0, in this example).

   % kubectl delete pod sample-0
   pod "sample-0" deleted
   

6. Wait a few minutes, then use the kubectl get command to verify the active Pod is now sample-1 for the sample TimesTenClassic object and the state is Normal (represented in bold).

   % kubectl get ttc sample
   NAME     STATE    ACTIVE     AGE
   sample   Normal   sample-1   47h
   

7. Use the kubectl exec -it command to invoke the shell in the active Pod (sample-1, in this example). Then, run the ttIsql utility to connect to the sample database. Note the new PermSize value of 600 and the new TempSize value of 300 in the connection output (represented in bold).

   % kubectl exec -it sample-1 -c tt -- /bin/bash
   Last login: Fri Apr 08 15:50:29 UTC 2023 on pts/0
   [timesten@sample-1 ~]$ ttIsql sample
    
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
   Type ? or "help" for help, type "exit" to quit ttIsql.
    
    
    
   connect "DSN=sample";
   Connection successful: 
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
   AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3;
   ForceDisconnectEnabled=1;
   (Default setting AutoCommit=1)
   

8. Use the kubectl exec -it command to invoke the shell in the standby Pod (sample-0, in this example). Then, run the ttIsql utility to connect to the sample database. Note the new PermSize value of 600 and the new TempSize value of 300 in the connection output (represented in bold).

   % kubectl exec -it sample-0 -c tt -- /bin/bash
   % ttIsql sample
    
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
   Type ? or "help" for help, type "exit" to quit ttIsql.
    
    
    
   connect "DSN=sample";
   Connection successful: 
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
   AutoCreate=0;PermSize=600;TempSize=300;DDLReplicationLevel=3;
   ForceDisconnectEnabled=1;
   (Default setting AutoCommit=1)

You have successfully modified the PermSize and the TempSize first connection attributes.

Modify General Connection Attributes

If you have not modified the db.ini file, proceed to the Manually Edit the db.ini File section. You can either directly modify the sys.odbc.ini file for the active TimesTen database and the sys.odbc.ini file for the standby TimesTen database or you can follow the steps in the Modify First Connection Attributes section. The first approach (modifying the sys.odbc.ini file directly) is less disruptive.

This section discusses the procedure for directly modifying the sys.odbc.ini files.

The sys.odbc.ini file is located in the TimesTen container of the Pod containing the active TimesTen database and in the TimesTen container of the Pod containing the standby TimesTen database. After you complete the modifications to the sys.odbc.ini files, subsequent applications can connect to the database using these general connection attributes.

This example illustrates how to edit the sys.odbc.ini files.

1. Use the kubectl exec -it command to invoke a shell in the active Pod. (In this example, sample-0 is the active Pod.)

   % kubectl exec -it sample-0 -c tt -- /bin/bash
   Last login: Fri Apr 08 22:43:26 UTC 2023 on pts/8

2. Verify the current directory (/tt/home/timesten).

   % pwd
   /tt/home/timesten

3. Navigate to the directory where the sys.odbc.ini file is located. The sys.odbc.ini file is located in the /tt/home/timesten/instances/instance1/conf directory. Therefore, navigate to the instances/instance1/conf directory.

   % cd instances/instance1/conf
   

4. Edit the sys.odbc.ini file, adding, modifying, or deleting the general connection attributes for your DSN. (sample, in this example.)

   Note:

   Ensure that you only make modifications to the TimesTen general connection attributes. Data store attributes and first connection attributes cannot be modified by directly editing the sys.odbc.ini file.

   This example modifies the sample DSN, adding the ConnectionCharacterSet general connection attribute and setting its value equal to AL32UTF8 (represented in bold).

   vi sys.odbc.ini
   
   [ODBC Data Sources]
   sample=TimesTen 22.1 Driver
   tt=TimesTen 22.1 Driver
    
   [sample]
   Datastore=/tt/home/timesten/datastore/sample
   PermSize=200
   DatabaseCharacterSet=AL32UTF8
   ConnectionCharacterSet=AL32UTF8
   DDLReplicationLevel=3
   AutoCreate=0
   ForceDisconnectEnabled=1
   ...
   

5. Use the ttIsql utility to connect to the sample database and verify the value of the ConnectionCharacterSet attribute is AL32UTF8 (represented in bold).

   % ttIsql sample
    
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
   Type ? or "help" for help, type "exit" to quit ttIsql.
    
    
    
   connect "DSN=sample";
   Connection successful: 
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
   AutoCreate=0;PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
   (Default setting AutoCommit=1)
   

You have successfully modified the sys.odbc.ini file located in the TimesTen container of the active Pod (in this example, sample-0). Use the same procedure to modify the sys.odbc.ini file located in the TimesTen container of the standby Pod (in this example, sample-1).

For example:

1. Use the kubectl exec -it command to invoke a shell in the standby Pod (sample-1, in this example).

   % kubectl exec -it sample-1 -c tt -- /bin/bash
   Last login: Fri Apr 08 23:08:08 UTC 2023 on pts/0

2. Verify the current directory (/tt/home/timesten).

   % pwd
   /tt/home/timesten

3. Navigate to the directory where the sys.odbc.ini file is located. The sys.odbc.ini file is located in the /tt/home/timesten/instances/instance1/conf directory. Therefore, navigate to the instances/instance1/conf directory.

   % cd instances/instance1/conf
   

4. Edit the sys.odbc.ini file, adding, modifying, or deleting the same general connection attributes that you modified for the active database. Therefore, this example modifies the sample DSN, adding the ConnectionCharacterSet general connection attribute and setting its value equal to AL32UTF8 (represented in bold).

   vi sys.odbc.ini
   
   [ODBC Data Sources]
   sample=TimesTen 22.1 Driver
   tt=TimesTen 22.1 Driver
    
   [sample]
   Datastore=/tt/home/timesten/datastore/sample
   PermSize=200
   DatabaseCharacterSet=AL32UTF8
   ConnectionCharacterSet=AL32UTF8
   DDLReplicationLevel=3
   AutoCreate=0
   ForceDisconnectEnabled=1
   ...
   

5. Use the ttIsql utility to connect to the sample database and verify the value of the ConnectionCharacterSet attribute is AL32UTF8 (represented in bold).

   % ttIsql sample
    
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
   Type ? or "help" for help, type "exit" to quit ttIsql.
    
    
    
   connect "DSN=sample";
   Connection successful:
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;
   AutoCreate=0;PermSize=200;DDLReplicationLevel=3;ForceDisconnectEnabled=1;
   (Default setting AutoCommit=1)
   

You have successfully modified the sys.odbc.ini file located in the TimesTen container of the active Pod (sample-0) and the sys.odbc.ini file located in the TimesTen container of the standby Pod (sample-1). The ConnectionCharacterSet general connection attribute has also been modified.

Revert to Manual Control

If you want to manually operate your active standby pair, you can delete the timesten-operator Deployment. The Operator stops, and does not restart. This affects all of the TimesTenClassic objects that are running in your Kubernetes cluster. If you do not want the Operator to stop managing all of the TimesTenClassic objects, you can suspend the management of individual TimesTenClassic objects. See "Suspend Management of a TimesTenClassic Object" for information.

The TimesTenClassic object, representing the active standby pair of TimesTen databases, remains in Kubernetes, as do the other Kubernetes objects associated with them. You can use the kubectl exec -it command to invoke shells in the Pods, and then you can control Timesten that is running in those Pods.

If one or both Pods in your active standby pair fails, Kubernetes creates new ones to replace them. This is due to the StatefulSet object that the Operator had previously created in Kubernetes. However, since the Operator is not running the new Pods, it cannot automatically start TimesTen. In this case, your active standby pair cannot be configured or started. You are responsible for the operation of TimesTen in the Pods.

If you want the Operator to take control again, you must redeploy the Operator. Once the Operator is redeployed, the Operator automatically identifies the TimesTenClassic objects in your Kubernetes cluster, and will attempt to manage them again.

This example shows you how to manually control TimesTen.

1. Verify the Operator and the TimesTen databases are running.

   % kubectl get pods
   NAME                                        READY   STATUS    RESTARTS   AGE
   sample-0                                    2/2     Running   0          18h
   sample-1                                    2/2     Running   0          18h
   timesten-operator-5d7dcc7948-pzj58          1/1     Running   0          18h
   

2. Navigate to the /deploy directory where the operator.yaml resides. (kube_files/deploy, in this example.)

   % cd kube_files/deploy
   

3. Use the kubectl delete command to delete the Operator. The Operator is stopped and no longer deployed.

   % kubectl delete -f operator.yaml
   deployment.apps "timesten-operator" deleted
   

4. Verify the Operator is no longer running, but the TimesTen databases are.

   % kubectl get pods
   NAME       READY   STATUS    RESTARTS   AGE
   sample-0   2/2     Running   0          19h
   sample-1   2/2     Running   0          19h
   

5. Use the kubectl exec -it command to invoke the shell in the Pod that runs TimesTen.

   % kubectl exec -it sample-0 -c tt -- /bin/bash
   Last login: Fri Apr  8 14:30:45 UTC 2023 on pts/0
   

6. Run the ttStatus utility.

   % ttStatus
   TimesTen status report as of Fri Apr  8 14:36:31 2023
    
   Daemon pid 183 port 6624 instance instance1
   TimesTen server pid 190 started on port 6625
   ------------------------------------------------------------------------
   ------------------------------------------------------------------------
   Data store /tt/home/timesten/datastore/sample
   Daemon pid 183 port 6624 instance instance1
   TimesTen server pid 190 started on port 6625
   There are 20 connections to the data store
   Shared Memory KEY 0x02200bbc ID 32769
   PL/SQL Memory Key 0x03200bbc ID 65538 Address 0x5000000000
   Type            PID     Context            Connection Name             ConnID
   Replication     263     0x00007f99fc0008c0 LOGFORCE:140299698493184      2029
   Replication     263     0x00007f9a040008c0 XLA_PARENT:140300350273280    2031
   Replication     263     0x00007f9a080008c0 REPLISTENER:140300347123456   2030
   Replication     263     0x00007f9a080acd60 RECEIVER:140299429472000      2028
   Replication     263     0x00007f9a0c0008c0 FAILOVER:140300353423104      2032
   Replication     263     0x00007f9a2c0009b0 TRANSMITTER(M):140299695343360 2034
   Replication     263     0x00007f9a300008c0 REPHOLD:140300356572928        2033
   Subdaemon       187     0x00000000023365b0 Manager                        2047
   Subdaemon       187     0x00000000023b57f0 Rollback                       2046
   Subdaemon       187     0x0000000002432cf0 Log Marker                     2041
   Subdaemon       187     0x000000000244fc00 Garbage Collector              2035
   Subdaemon       187     0x00007f90c80008c0 Aging                          2038
   Subdaemon       187     0x00007f90d00008c0 Deadlock Detector              2044
   Subdaemon       187     0x00007f90d001d7d0 HistGC                         2039
   Subdaemon       187     0x00007f90d40008c0 Checkpoint                     2042
   Subdaemon       187     0x00007f90d401d7d0 AsyncMV                        2036
   Subdaemon       187     0x00007f90d80008c0 Monitor                        2043
   Subdaemon       187     0x00007f90f808b360 IndexGC                        2037
   Subdaemon       187     0x00007f90fc0008c0 Flusher                        2045
   Subdaemon       187     0x00007f910004efd0 XactId Rollback                2040
   Open for user connections
   RAM residence policy: Always
   Replication policy  : Manual
   Replication agent is running.
   Cache Agent policy  : Manual
   PL/SQL enabled.
   ------------------------------------------------------------------------
   Accessible by group timesten
   End of report
   

7. Run the ttIsql utility to connect to the sample database and perform various operations.

   % ttIsql sample
    
   Copyright (c) 1996, 2023, Oracle and/or its affiliates. All rights reserved.
   Type ? or "help" for help, type "exit" to quit ttIsql.
    
    
    
   connect "DSN=sample";
   Connection successful: 
   DSN=sample;UID=timesten;DataStore=/tt/home/timesten/datastore/sample;
   DatabaseCharacterSet=AL32UTF8;ConnectionCharacterSet=AL32UTF8;PermSize=200;
   DDLReplicationLevel=3;
   (Default setting AutoCommit=1)
   Command> describe sampleuser.emp;
    
   Table SAMPLEUSER.EMP:
     Columns:
      *ID                              NUMBER NOT NULL
       NAME                            CHAR (32)
    
   1 table found.
   (primary key columns are indicated with *)
   
   Command> INSERT INTO sampleuser.emp VALUES (1,'This is a test.');
   1 row inserted.
   Command> SELECT * FROM sampleuser.emp;
   < 1, This is a test.                  >
   1 row found.

Delete an Active Standby Pair of TimesTen Databases

If you delete the TimesTenClassic object that represents the active standby pair of TimesTen databases, Kubernetes automatically deletes all the Kubernetes objects and the resources it is using. The StatefulSet, the Service, and the Pods, that are associated with the pair are all deleted from Kubernetes. However, the PersistentVolumeClaims (that contain the TimesTen databases) are not deleted. You must manually delete the PersistentVolumeClaims (PVCs) after you delete the TimesTenClassic object. After you manually delete the PVCs, the PersistentVolumes, holding the databases, are recycled by Kubernetes. (You may be able to control this using the Kubernetes volume retention policy, but this is not controlled by the Operator.)

As an example, use the kubectl delete command to delete the PVCs for the sample databases.

% kubectl delete pvc tt-persistent-sample-0
persistentvolumeclaim "tt-persistent-sample-0" deleted
% kubectl delete pvc tt-persistent-sample-1
persistentvolumeclaim "tt-persistent-sample-1" deleted