Feed aggregator

Regarding the Current Role of PL/SQL in Modern Technology Stacks

Tom Kyte - 12 hours 53 min ago
Dear Team, I hope this message finds you well. I have been reflecting on the current landscape of PL/SQL and its role in contemporary technology stacks. I would greatly appreciate your insights on a few points that have been on my mind. <b> PLSQL for Business Logic ? </b> While it's widely acknowledged that "as long as there is Oracle, there will be PL/SQL," I am eager to explore forward-looking scenarios where PL/SQL remains a prominent choice for business logic. In today's context, it seems that business logic is predominantly implemented using modern object-oriented languages such as Java or .NET, leveraging features like Streams and Lambda functions. Could you provide examples or use cases where PL/SQL excels and is considered integral, especially in comparison to these object-oriented approaches? <b> PLSQL for Data Engineering ? </b> The ETL landscape has witnessed a significant shift towards technologies like Spark for seamless integration with data warehouses and data lakes. In this evolving scenario, I am curious to understand how PL/SQL continues to play a vital role in ETL processes. Are there specific use cases or examples where PL/SQL is still the preferred choice in modern data engineering stacks? I understand the historical significance of PL/SQL in minimizing network calls and maintaining code proximity to databases, as highlighted in research papers advocating for a thick database approach. However, I am keen to bridge the gap between theoretical advantages and practical implementations. Are enterprise projects aligning with this approach, or is the trend shifting towards business logic predominantly residing in Java/.NET environments? In essence, <b>could you kindly furnish examples and use cases illustrating</b> where PL/SQL stands out as a core, integral component in modern data engineering or application development stacks? <b>I am particularly interested in understanding if PL/SQL is now primarily considered a supplementary or exception-use language, driven by compliance requirements rather than intrinsic value in data movement scenarios.</b> I appreciate your time and insights into this matter, and I look forward to hearing from you soon.
Categories: DBA Blogs

Logical Offline Migration to ExaCC with Oracle Zero Downtime Migration (ZDM)

Yann Neuhaus - Tue, 2024-02-20 17:47

A while ago I had been testing and blogging about ZDM, see my previous articles. And I finally had the chance to implement it at one of our customer to migrate on-premises database to Exadata Cloud @Customer. In this article I would like to share with you my experience migrating an on-premises database to ExaCC using ZDM Logical Offline Migration with a backup location. We intended to use this method, as mandatory one for small Oracle SE2 databases, and preferred one for huge Oracle SE2 databases.

Read more: Logical Offline Migration to ExaCC with Oracle Zero Downtime Migration (ZDM) Naming convention

Of course I have anonymised all outputs to remove customer infrastructure names. So let’s take following convention.

ExaCC Cluster 01 node 01 : ExaCC-cl01n1
ExaCC Cluster 01 node 02 : ExaCC-cl01n2
On premises Source Host : vmonpr
Target db_unique_name on the ExaCC : ONPR_RZ2
Database Name to migrate : ONPR
ZDM Host : zdmhost
ZDM user : zdmuser
Domain : domain.com
ExaCC PDB to migrate to : ONPRZ_APP_001T

We will then migrate on-premise Single-Tenant database, named ONPR, to a PDB on the ExaCC. The PDB will be named ONPRZ_APP_001T.

We will migrate 3 schemas : USER1, USER2 and USER3

Ports

It is important to mention that following ports are needed:

SourceDestinationPortZDM HostOn-premise Host22ZDM HostOn-premise HostOracle NetZDM HostExaCC VM (both nodes)22ZDM HostExaCC (scan + VIP)Oracle NetOn-premise HostNFS Server111
2049ExaCCNFS Server111
2049

If Oracle Net ports are for example not opened between ZDM Host and ExaCC, the migration evaluation will immediately stopped at first steps named ZDM_VALIDATE_TGT, and following errors will be found in the log file:

PRGZ-3181 : Internal error: ValidateTargetDbLogicalZdm-5-PRGD-1059 : query to retrieve NLS database parameters failed
PRGD-1002 : SELECT statement "SELECT * FROM GLOBAL_NAME" execution as user "system" failed for database with Java Database Connectivity (JDBC) URL "jdbc:oracle:thin:@(description=(address=(protocol=tcp)(port=1521)(host=ExaCC-cl01-scan.domain.com))(connect_data=(service_name=ONPRZ_APP_001T_PRI.domain.com)))"
IO Error: The Network Adapter could not establish the connection (CONNECTION_ID=9/tZ9Bt5Q5q5VfqU7JC/xA==)
Requirements

There is a few requirements that are needed

streams_pool_size instance parameter on the source database

To have an initial pool allocated and optimal Data Pump performance, source DB instance parameter needs to be set to minimal 256-300 MB for Logical Offline Migration.


Passwordless Login

Passwordless Login needs to be configured between ZDM Host, the Source Host and Target Host. See my previous blog : https://www.dbi-services.com/blog/oracle-zdm-migration-java-security-invalidkeyexception-invalid-key-format/

If Passwordless Login is not configured with one node, you will see such error in the log file during migration evaluation:

PRCZ-2006 : Unable to establish SSH connection to node "ExaCC-cl01n2" to execute command "<command_to_be_executed>"
No more authentication methods available.

Database Character Set

ExaCC target CDB should be in the same character set as on-premise source db. If the final CDB where you would like to host your new PDB has got a character set of AL32UTF8 for example (so this CDB can host various PDB character set) and your source DB is not in AL32UTF8 you will need to go through a temporary CDB on the ExaCC before relocating the PDB to the final one.

To check the character set, run following statement on the on-premise source DB:

SQL> select parameter, value from v$nls_parameters where parameter='NLS_CHARACTERSET';

If your ExaCC target CDB character set (here as example AL32UTF8) does not match the on-premise source DB character set (here as example WE8ISO8859P1), you will get following ZDM error during the evaluation of the migration:

PRGZ-3549 : Source NLS character set WE8ISO8859P1 is different from target NLS character set AL32UTF8.

Create PDB on the ExaCC

Final PDB will have to be created in one of the ExaCC container database according to the character set of the source database.


Create NFS directory

NFS directory and Oracle directories need to be setup to store Oracle dump file created automatically by ZDM. We will create the file system directory on the NFS Mount point and a new Oracle Directory named MIG_SOURCE_DEST in both databases (source and target). NFS directory should be accessible and shared between both environments.

If you do not have any shared NFS between source and target, you will get following kind of errors when evaluating the migration:

zdmhost: 2024-02-06T14:14:17.001Z : Executing phase ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT
zdmhost: 2024-02-06T14:14:19.583Z : validating Oracle Data Pump dump directory /u02/app/oracle/product/19.0.0.0/dbhome_2/rdbms/log/10B7A59DF2E82A9AE063021FA10ABD38 ...
zdmhost: 2024-02-06T14:14:19.587Z : listing directory path /u02/app/oracle/product/19.0.0.0/dbhome_2/rdbms/log/10B7A59DF2E82A9AE063021FA10ABD38 on node ExaCC-cl01n1.domain.com ...
PRGZ-1211 : failed to validate specified database directory object path "/u02/app/oracle/product/19.0.0.0/dbhome_2/rdbms/log/10B7A59DF2E82A9AE063021FA10ABD38"
PRGZ-1420 : specified database import directory object path "/u02/app/oracle/product/19.0.0.0/dbhome_2/rdbms/log/10B7A59DF2E82A9AE063021FA10ABD38" is not shared between source and target database server

After having created the directory on the shared NFS, directory which will be shared on both the source and the target, you will need to create (or use an existing one) an oracle directory. I decided to create a new one, named MIG_SOURCE_DEST. The following will have to be run on both the source and the target databases.

SQL> create directory MIG_SOURCE_DEST as '/mnt/nfs_share/ONPR/';

Directory created.

SQL> select directory_name, directory_path from dba_directories where upper(directory_name) like '%MIG%';

DIRECTORY_NAME                 DIRECTORY_PATH
------------------------------ ------------------------------------------------------------
MIG_SOURCE_DEST                /mnt/nfs_share/ONPR/

You will also need to set correct permissions to the folder knowing that ExaCC OS user might not have the same id than the Source Host OS user.


Source user password version

It is mandatory that the password for all user schemas been migrated is in at least 12c versions. For old password version like 10G or 11G, password for user needs to be change to avoid additional troubleshooting and actions with ZDM migration.

To check user password version on the source, run following SQL statement:

SQL> select username, account_status, lock_date, password_versions from dba_users where ORACLE_MAINTAINED='N';

Prepare ZDM response file

We will use ZDM response file template named zdm_logical_template.rsp and adapt it.

[zdmuser@zdmhost migration]$ cp /u01/app/oracle/product/zdm/rhp/zdm/template/zdm_logical_template.rsp ./zdm_ONPR_logical_offline.rsp

The main parameters to take care of are :

ParameterExplanation DATA_TRANSFER_MEDIUMSpecifies how data will be transferred from the source database system to the target database system.
To be NFS TARGETDATABASE_ADMINUSERNAMEUser to be used on the target for the migration.
To be SYSTEM SOURCEDATABASE_ADMINUSERNAMEUser to be used on the source for the migration.
To be SYSTEM SOURCEDATABASE_CONNECTIONDETAILS_HOSTSource listener host SOURCEDATABASE_CONNECTIONDETAILS_PORTSource listener port. SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAMESource database service name TARGETDATABASE_CONNECTIONDETAILS_HOSTTarget listener host (on ExaCC scan listener) TARGETDATABASE_CONNECTIONDETAILS_PORTTarget listener port.
To be 1521 TARGETDATABASE_CONNECTIONDETAILS_SERVICENAMETarget database service name TARGETDATABASE_DBTYPETarget environment
To be EXADATA DATAPUMPSETTINGS_SCHEMABATCH-1Comma separated list of Database schemas to be migrated DATAPUMPSETTINGS_SCHEMABATCHCOUNTExclusive with schemaBatch option. If specified, user schemas are identified DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREEMaximum number of worker processes that can be used for a Data Pump Import job
For SE2 needs to be configure to 1 DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREEMaximum number of worker processes that can be used for a Data Pump Export job
For SE2 needs to be configure to 1 DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELISTSpecifies a comma separated list of object types to exclude DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAMEOracle DBA directory that was created on the source for the export DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATHNFS directory for dump that is used for export DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAMEOracle DBA directory that was created on the source for the import DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATHNFS directory for dump that is used for import TABLESPACEDETAILS_AUTOCREATEIf set to TRUE, ZDM will automatically create the tablespaces
To be TRUE

Updated ZDM response file compared to ZDM template for the migration we are going to run:

[zdmuser@zdmhost migration]$ diff zdm_ONPR_logical_offline.rsp /u01/app/oracle/product/zdm/rhp/zdm/template/zdm_logical_template.rsp
30c30
< DATA_TRANSFER_MEDIUM=NFS
---
> DATA_TRANSFER_MEDIUM=OSS
47c47
< TARGETDATABASE_ADMINUSERNAME=system
---
> TARGETDATABASE_ADMINUSERNAME=
63c63
< SOURCEDATABASE_ADMINUSERNAME=system
---
> SOURCEDATABASE_ADMINUSERNAME=
80c80
< SOURCEDATABASE_CONNECTIONDETAILS_HOST=vmonpr
---
> SOURCEDATABASE_CONNECTIONDETAILS_HOST=
90c90
< SOURCEDATABASE_CONNECTIONDETAILS_PORT=13000
---
> SOURCEDATABASE_CONNECTIONDETAILS_PORT=
102c102
< SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME=ONPR.domain.com
---
> SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME=
153c153
< TARGETDATABASE_CONNECTIONDETAILS_HOST=ExaCC-cl01-scan.domain.com
---
> TARGETDATABASE_CONNECTIONDETAILS_HOST=
163c163
< TARGETDATABASE_CONNECTIONDETAILS_PORT=1521
---
> TARGETDATABASE_CONNECTIONDETAILS_PORT=
175c175
< TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME=ONPRZ_APP_001T_PRI.domain.com
---
> TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME=
307c307
< TARGETDATABASE_DBTYPE=EXADATA
---
> TARGETDATABASE_DBTYPE=
726c726
< DATAPUMPSETTINGS_SCHEMABATCH-1=USER1,USER2,USER3
---
> DATAPUMPSETTINGS_SCHEMABATCH-1=
947c947
< DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE=1
---
> DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE=
957c957
< DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE=1
---
> DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE=
969c969
< DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELIST=STATISTICS
---
> DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXCLUDETYPELIST=
1137c1137
< DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME=MIG_SOURCE_DEST
---
> DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME=
1146c1146
< DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH=/mnt/nfs_share/ONPR
---
> DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH=
1166c1166
< DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME=MIG_SOURCE_DEST
---
> DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME=
1175c1175
< DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH=/mnt/nfs_nfs_share/ONPR
---
> DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH=
2146c2146
< TABLESPACEDETAILS_AUTOCREATE=TRUE
---
> TABLESPACEDETAILS_AUTOCREATE=

ZDM Build Version

I’m using ZDM build 21.4.

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli -build
version: 21.0.0.0.0
full version: 21.4.0.0.0
patch version: 21.4.1.0.0
label date: 221207.25
ZDM kit build date: Jul 31 2023 14:24:25 UTC
CPAT build version: 23.7.0

The migration will be done using ZDM CLI (zdmcli), which run migration through jobs. We can abort, query, modify, suspend or resume a running job.

Evaluate the migration

We will first run zdmcli with the -eval option to evaluate the migration and test if all is ok.

We need to provide some arguments :

ArgumentValue -sourcesidDatabase Name of the source database in case the source database is a single instance deployed on a non Grid Infrastructure environment -rspZDM response file -sourcenodeSource host -srcauth with 3 sub-arguments:
-srcarg1
-srcarg2
-srcarg3 Name of the source authentication plug-in with 3 sub-arguments:
1st argument: user. Should be oracle
2nd argument: ZDM private RSA Key
3rd argument: sudo location -targetnodeTarget host -tgtauth with 3 sub-arguments:
-tgtarg1
-tgtarg2
-tgtarg3 Name of the target authentication plug-in with 3 sub-arguments:
1st argument: user. Should be opc
2nd argument: ZDM private RSA Key
3rd argument: sudo location
[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_logical_offline.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo -eval
zdmhost.domain.com: Audit ID: 194
Enter source database administrative user "system" password:
Enter target database administrative user "system" password:
Operation "zdmcli migrate database" scheduled with the job ID "27".
[zdmuser@zdmhost migration]$

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli query job -jobid 27
zdmhost.domain.com: Audit ID: 197
Job ID: 27
User: zdmuser
Client: zdmhost
Job Type: "EVAL"
Scheduled job command: "zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_logical_offline.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo -eval"
Scheduled job execution start time: 2024-02-06T16:03:49+01. Equivalent local time: 2024-02-06 16:03:49
Current status: SUCCEEDED
Result file path: "/u01/app/oracle/chkbase/scheduled/job-27-2024-02-06-16:04:01.log"
Metrics file path: "/u01/app/oracle/chkbase/scheduled/job-27-2024-02-06-16:04:01.json"
Excluded objects file path: "/u01/app/oracle/chkbase/scheduled/job-27-filtered-objects-2024-02-06T16:04:13.522.json"
Job execution start time: 2024-02-06 16:04:01
Job execution end time: 2024-02-06 16:05:55
Job execution elapsed time: 1 minutes 54 seconds
ZDM_VALIDATE_TGT ...................... COMPLETED
ZDM_VALIDATE_SRC ...................... COMPLETED
ZDM_SETUP_SRC ......................... COMPLETED
ZDM_PRE_MIGRATION_ADVISOR ............. COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC .... COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT .... COMPLETED
ZDM_PREPARE_DATAPUMP_SRC .............. COMPLETED
ZDM_DATAPUMP_ESTIMATE_SRC ............. COMPLETED
ZDM_CLEANUP_SRC ....................... COMPLETED

We can see that the Job Type is EVAL, and that the Current Status is SUCCEEDED with all prechecks steps having a COMPLETED status.

We can also review the log file which will provide us more information. We will see all the checks that the tool is doing. We can also review the output of the advisor which is already warning us about old password for users. Reviewing all the advisor outputs might help. We can also see that ZDM will ignore as non critical a few ORA errors. This make senses because the migration should still happen even if the user is already created with empty objects for example.

[zdmuser@zdmhost ~]$ cat /u01/app/oracle/chkbase/scheduled/job-27-2024-02-06-16:04:01.log
zdmhost: 2024-02-06T15:04:01.505Z : Starting zero downtime migrate operation ...
zdmhost: 2024-02-06T15:04:01.511Z : Executing phase ZDM_VALIDATE_TGT
zdmhost: 2024-02-06T15:04:04.952Z : Fetching details of on premises Exadata Database "ONPRZ_APP_001T_PRI.domain.com"
zdmhost: 2024-02-06T15:04:04.953Z : Type of database : "Exadata at Customer"
zdmhost: 2024-02-06T15:04:05.014Z : Verifying configuration and status of target database "ONPRZ_APP_001T_PRI.domain.com"
zdmhost: 2024-02-06T15:04:09.067Z : Global database name: ONPRZ_APP_001T.DOMAIN.COM
zdmhost: 2024-02-06T15:04:09.067Z : Target PDB name : ONPRZ_APP_001T
zdmhost: 2024-02-06T15:04:09.068Z : Database major version : 19
zdmhost: 2024-02-06T15:04:09.069Z : obtaining database ONPRZ_APP_001T.DOMAIN.COM tablespace configuration details...
zdmhost: 2024-02-06T15:04:09.585Z : Execution of phase ZDM_VALIDATE_TGT completed
zdmhost: 2024-02-06T15:04:09.670Z : Executing phase ZDM_VALIDATE_SRC
zdmhost: 2024-02-06T15:04:09.736Z : Verifying configuration and status of source database "ONPR.domain.com"
zdmhost: 2024-02-06T15:04:09.737Z : source database host vmonpr service ONPR.domain.com
zdmhost: 2024-02-06T15:04:13.464Z : Global database name: ONPR.DOMAIN.COM
zdmhost: 2024-02-06T15:04:13.465Z : Database major version : 19
zdmhost: 2024-02-06T15:04:13.466Z : Validating database time zone compatibility...
zdmhost: 2024-02-06T15:04:13.521Z : Database objects which will be migrated : [USER2, USER3]
zdmhost: 2024-02-06T15:04:13.530Z : Execution of phase ZDM_VALIDATE_SRC completed
zdmhost: 2024-02-06T15:04:13.554Z : Executing phase ZDM_SETUP_SRC
zdmhost: 2024-02-06T15:05:04.925Z : Execution of phase ZDM_SETUP_SRC completed
zdmhost: 2024-02-06T15:05:04.944Z : Executing phase ZDM_PRE_MIGRATION_ADVISOR
zdmhost: 2024-02-06T15:05:05.371Z : Running CPAT (Cloud Premigration Advisor Tool) on the source node vmonpr ...
zdmhost: 2024-02-06T15:05:07.894Z : Premigration advisor output:
Cloud Premigration Advisor Tool Version 23.7.0
CPAT-4007: Warning: the build date for this version of the Cloud Premigration Advisor Tool is over 216 days.  Please run "premigration.sh --updatecheck" to see if a more recent version of this tool is available.
Please download the latest available version of the CPAT application.

Cloud Premigration Advisor Tool completed with overall result: Review Required
Cloud Premigration Advisor Tool generated report location: /u00/app/oracle/zdm/zdm_ONPR_27/out/premigration_advisor_report.json
Cloud Premigration Advisor Tool generated report location: /u00/app/oracle/zdm/zdm_ONPR_27/out/premigration_advisor_report.txt

 CPAT exit code: 2
 RESULT: Review Required

Schemas Analyzed (2): USER3,USER2
A total of 17 checks were performed
There were 0 checks with Failed results
There were 0 checks with Action Required results
There were 2 checks with Review Required results: has_noexport_object_grants (8 relevant objects), has_users_with_10g_password_version (1 relevant objects)
There were 0 checks with Review Suggested results has_noexport_object_grants
         RESULT: Review Required
         DESCRIPTION: Not all object grants are exported by Data Pump.
         ACTION: Recreate any required grants on the target instance.  See Oracle Support Document ID 1911151.1 for more information. Note that any SELECT grants on system objects will need to be replaced with READ grants; SELECT is no longer allowed on system objects.
has_users_with_10g_password_version
         RESULT: Review Required
         DESCRIPTION: Case-sensitive passwords are required on ADB.
         ACTION: To avoid Data Pump migration warnings change the passwords for the listed users before migration. Alternatively, modify these users passwords after migration to avoid login failures. See Oracle Support Document ID 2289453.1 for more information.

zdmhost: 2024-02-06T15:05:07.894Z : Execution of phase ZDM_PRE_MIGRATION_ADVISOR completed
zdmhost: 2024-02-06T15:05:07.948Z : Executing phase ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC
zdmhost: 2024-02-06T15:05:08.545Z : validating Oracle Data Pump dump directory /mnt/nfs_share/ONPR/ ...
zdmhost: 2024-02-06T15:05:08.545Z : validating Data Pump dump directory path /mnt/nfs_share/ONPR/ on node vmonpr.domain.com ...
zdmhost: 2024-02-06T15:05:08.975Z : validating if target database user can read files shared on medium NFS
zdmhost: 2024-02-06T15:05:08.976Z : setting Data Pump dump file permission at source node...
zdmhost: 2024-02-06T15:05:08.977Z : changing group of Data Pump dump files in directory path /mnt/nfs_share/ONPR/ on node vmonpr.domain.com ...
zdmhost: 2024-02-06T15:05:09.958Z : Execution of phase ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC completed
zdmhost: 2024-02-06T15:05:10.005Z : Executing phase ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT
zdmhost: 2024-02-06T15:05:13.307Z : validating Oracle Data Pump dump directory /mnt/nfs_nfs_share/ONPR ...
zdmhost: 2024-02-06T15:05:13.308Z : listing directory path /mnt/nfs_nfs_share/ONPR on node ExaCC-cl01n1.domain.com ...
zdmhost: 2024-02-06T15:05:14.008Z : Execution of phase ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT completed
zdmhost: 2024-02-06T15:05:14.029Z : Executing phase ZDM_PREPARE_DATAPUMP_SRC
zdmhost: 2024-02-06T15:05:14.033Z : Execution of phase ZDM_PREPARE_DATAPUMP_SRC completed
zdmhost: 2024-02-06T15:05:14.058Z : Executing phase ZDM_DATAPUMP_ESTIMATE_SRC
zdmhost: 2024-02-06T15:05:14.059Z : starting Data Pump Dump estimate for database "ONPR.DOMAIN.COM"
zdmhost: 2024-02-06T15:05:14.060Z : running Oracle Data Pump job "ZDM_27_DP_ESTIMATE_6279" for database "ONPR.DOMAIN.COM"
zdmhost: 2024-02-06T15:05:14.071Z : applying Data Pump dump compression ALL algorithm MEDIUM
zdmhost: 2024-02-06T15:05:14.135Z : applying Data Pump dump encryption ALL algorithm AES128
zdmhost: 2024-02-06T15:05:14.135Z : Oracle Data Pump Export parallelism set to 1 ...
zdmhost: 2024-02-06T15:05:14.286Z : Oracle Data Pump errors to be ignored are ORA-31684,ORA-39111,ORA-39082...
zdmhost: 2024-02-06T15:05:23.515Z : Oracle Data Pump log located at /mnt/nfs_share/ONPR//ZDM_27_DP_ESTIMATE_6279.log in the Database Server node
zdmhost: 2024-02-06T15:05:53.643Z : Total estimation using BLOCKS method: 3.112 GB
zdmhost: 2024-02-06T15:05:53.644Z : Execution of phase ZDM_DATAPUMP_ESTIMATE_SRC completed
zdmhost: 2024-02-06T15:05:53.721Z : Executing phase ZDM_CLEANUP_SRC
zdmhost: 2024-02-06T15:05:54.261Z : Cleaning up ZDM on the source node vmonpr ...
zdmhost: 2024-02-06T15:05:55.506Z : Execution of phase ZDM_CLEANUP_SRC completed

Migrate Source database to ExaCC

Once the evaluation is all good, we can move forward with running the migration. It is exactly the same zdmcli command without the option -eval.

Let’s have a try and run it. We will have to provide both source and target system password:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_logical_offline.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo
zdmhost.domain.com: Audit ID: 205
Enter source database administrative user "system" password:
Enter target database administrative user "system" password:
Operation "zdmcli migrate database" scheduled with the job ID "29".

We will query the job:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli query job -jobid 29
zdmhost.domain.com: Audit ID: 211
Job ID: 29
User: zdmuser
Client: zdmhost
Job Type: "MIGRATE"
Scheduled job command: "zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_logical_offline.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo"
Scheduled job execution start time: 2024-02-07T08:21:38+01. Equivalent local time: 2024-02-07 08:21:38
Current status: FAILED
Result file path: "/u01/app/oracle/chkbase/scheduled/job-29-2024-02-07-08:22:03.log"
Metrics file path: "/u01/app/oracle/chkbase/scheduled/job-29-2024-02-07-08:22:03.json"
Excluded objects file path: "/u01/app/oracle/chkbase/scheduled/job-29-filtered-objects-2024-02-07T08:22:16.074.json"
Job execution start time: 2024-02-07 08:22:03
Job execution end time: 2024-02-07 08:30:29
Job execution elapsed time: 8 minutes 25 seconds
ZDM_VALIDATE_TGT ...................... COMPLETED
ZDM_VALIDATE_SRC ...................... COMPLETED
ZDM_SETUP_SRC ......................... COMPLETED
ZDM_PRE_MIGRATION_ADVISOR ............. COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC .... COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT .... COMPLETED
ZDM_PREPARE_DATAPUMP_SRC .............. COMPLETED
ZDM_DATAPUMP_ESTIMATE_SRC ............. COMPLETED
ZDM_PREPARE_DATAPUMP_TGT .............. COMPLETED
ZDM_PARALLEL_EXPORT_IMPORT ............ FAILED
ZDM_POST_DATAPUMP_SRC ................. PENDING
ZDM_POST_DATAPUMP_TGT ................. PENDING
ZDM_POST_ACTIONS ...................... PENDING
ZDM_CLEANUP_SRC ....................... PENDING

As we can see the jobs failed during import of the data.

Checking ZDM logs file I could see following errors:

ORA-39384: Warning: User USER2 has been locked and the password expired.
ORA-39384: Warning: User USER1 has been locked and the password expired.

Checking the user on the source, I could see that USER1 and USER2 is having only password in old 10G version, which definitively will make problem :

SQL> select username, account_status, lock_date, password_versions from dba_users where ORACLE_MAINTAINED='N';

USERNAME                       ACCOUNT_STATUS                   LOCK_DATE            PASSWORD_VERSIONS
------------------------------ -------------------------------- -------------------- -----------------
USER1                          OPEN                                                  10G
USER2                          OPEN                                                  10G
USER3                          OPEN                                                  10G 11G 12C

3 rows selected.

Checking on the target PDB on the ExaCC, I could see that, as these 2 users were having 10G password, ZDM, after importing the data, locked the related users:

SQL> select username, account_status, lock_date from dba_users where ORACLE_MAINTAINED='N';

USERNAME                       ACCOUNT_STATUS                   LOCK_DATE
------------------------------ -------------------------------- --------------------
USER1                          EXPIRED & LOCKED                 07-FEB-2024 08:26:10
ADMIN                          LOCKED                           06-FEB-2024 14:36:18
USER2                          EXPIRED & LOCKED                 07-FEB-2024 08:26:10
USER3                          OPEN

4 rows selected.

On the ExaCC target PDB, I unlocked the user and changed the password.

SQL> alter user USER2 account unlock;

User altered.

SQL> alter user user1 account unlock;

User altered.

SQL> alter user USER2 identified by ************;

User altered.

SQL> alter user user1 identified by ************;

User altered.

SQL> select username, account_status, lock_date from dba_users where ORACLE_MAINTAINED='N';

USERNAME                       ACCOUNT_STATUS                   LOCK_DATE
------------------------------ -------------------------------- --------------------
USER1                          OPEN
ADMIN                          LOCKED                           06-FEB-2024 14:36:18
USER2                          OPEN
USER3                          OPEN

6 rows selected.

And I resumed the zdmcli jobs so he would start again where it was failing:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli resume job -jobid 29
zdmhost.domain.com: Audit ID: 213

The job was still failing at the same step, and in the log file I could find several errors like :

BATCH1 : Non-ignorable errors found in Oracle Data Pump job ZDM_29_DP_IMPORT_5005_BATCH1 log are
ORA-39151: Table "USER3"."OPB_MAP_OPTIONS" exists. All dependent metadata and data will be skipped due to table_exists_action of skip
ORA-39151: Table "USER3"."OPB_USER_GROUPS" exists. All dependent metadata and data will be skipped due to table_exists_action of skip

In fact, as ZDM previously failed on the import step, ZDM tried to import the data again. But table was still there.

So I had to cleanup the Target PDB on the ExaCC for USER3 and USER2. USER1 had no objects.

As I did not want to change the on-premise source database, changing user password, I checked how the users were created on the ExaCC, I dropped them to create them again before resuming the jobs.

SQL> set long 99999999
SQL> select dbms_metadata.get_ddl('USER','USER2') from dual;

DBMS_METADATA.GET_DDL('USER','USER2')
--------------------------------------------------------------------------------

   CREATE USER "USER2" IDENTIFIED BY VALUES 'S:C5EF**********3F79'
      DEFAULT TABLESPACE "TSP******"
      TEMPORARY TABLESPACE "TEMP"

SQL> select dbms_metadata.get_ddl('USER','USER3') from dual;

DBMS_METADATA.GET_DDL('USER','USER3')
--------------------------------------------------------------------------------

   CREATE USER "USER3" IDENTIFIED BY VALUES 'S:EDD8**********FD44'
      DEFAULT TABLESPACE "TSP******"
      TEMPORARY TABLESPACE "TEMP"

SQL> drop user USER2 cascade;

User dropped.

SQL> drop user USER3 cascade;

User dropped.

SQL> CREATE USER "USER3" IDENTIFIED BY VALUES 'S:EDD86**********8FD44'
  2  DEFAULT TABLESPACE "TSP******"
  3  TEMPORARY TABLESPACE "TEMP";

User created.

SQL> CREATE USER "USER2" IDENTIFIED BY VALUES 'S:C5EF**********3F79'
  2  DEFAULT TABLESPACE "TSP******"
  3  TEMPORARY TABLESPACE "TEMP";

User created.

And I resumed the job once again:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli resume job -jobid 29
zdmhost.domain.com: Audit ID: 219

And now the migration has been completed successfully. The job type is MIGRATE now and Current Status is SUCCEEDED:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli query job -jobid 29
zdmhost.domain.com: Audit ID: 223
Job ID: 29
User: zdmuser
Client: zdmhost
Job Type: "MIGRATE"
Scheduled job command: "zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_logical_offline.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo"
Scheduled job execution start time: 2024-02-07T08:21:38+01. Equivalent local time: 2024-02-07 08:21:38
Current status: SUCCEEDED
Result file path: "/u01/app/oracle/chkbase/scheduled/job-29-2024-02-07-08:22:03.log"
Metrics file path: "/u01/app/oracle/chkbase/scheduled/job-29-2024-02-07-08:22:03.json"
Excluded objects file path: "/u01/app/oracle/chkbase/scheduled/job-29-filtered-objects-2024-02-07T08:22:16.074.json"
Job execution start time: 2024-02-07 08:22:03
Job execution end time: 2024-02-07 09:01:21
Job execution elapsed time: 14 minutes 43 seconds
ZDM_VALIDATE_TGT ...................... COMPLETED
ZDM_VALIDATE_SRC ...................... COMPLETED
ZDM_SETUP_SRC ......................... COMPLETED
ZDM_PRE_MIGRATION_ADVISOR ............. COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC .... COMPLETED
ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT .... COMPLETED
ZDM_PREPARE_DATAPUMP_SRC .............. COMPLETED
ZDM_DATAPUMP_ESTIMATE_SRC ............. COMPLETED
ZDM_PREPARE_DATAPUMP_TGT .............. COMPLETED
ZDM_PARALLEL_EXPORT_IMPORT ............ COMPLETED
ZDM_POST_DATAPUMP_SRC ................. COMPLETED
ZDM_POST_DATAPUMP_TGT ................. COMPLETED
ZDM_POST_ACTIONS ...................... COMPLETED
ZDM_CLEANUP_SRC ....................... COMPLETED

ZDM log file:

[zdmuser@zdmhost ~]$ tail -37 /u01/app/oracle/chkbase/scheduled/job-29-2024-02-07-08:22:03.log
####################################################################
zdmhost: 2024-02-07T07:56:33.580Z : Resuming zero downtime migrate operation ...
zdmhost: 2024-02-07T07:56:33.587Z : Starting zero downtime migrate operation ...
zdmhost: 2024-02-07T07:56:37.205Z : Fetching details of on premises Exadata Database "ONPRZ_APP_001T_PRI.domain.com"
zdmhost: 2024-02-07T07:56:37.205Z : Type of database : "Exadata at Customer"
zdmhost: 2024-02-07T07:56:37.283Z : Skipping phase ZDM_VALIDATE_SRC on resume
zdmhost: 2024-02-07T07:56:37.365Z : Skipping phase ZDM_SETUP_SRC on resume
zdmhost: 2024-02-07T07:56:37.377Z : Skipping phase ZDM_PRE_MIGRATION_ADVISOR on resume
zdmhost: 2024-02-07T07:56:37.391Z : Skipping phase ZDM_VALIDATE_DATAPUMP_SETTINGS_SRC on resume
zdmhost: 2024-02-07T07:56:37.406Z : Skipping phase ZDM_VALIDATE_DATAPUMP_SETTINGS_TGT on resume
zdmhost: 2024-02-07T07:56:37.422Z : Skipping phase ZDM_PREPARE_DATAPUMP_SRC on resume
zdmhost: 2024-02-07T07:56:37.437Z : Skipping phase ZDM_DATAPUMP_ESTIMATE_SRC on resume
zdmhost: 2024-02-07T07:56:37.455Z : Skipping phase ZDM_PREPARE_DATAPUMP_TGT on resume
zdmhost: 2024-02-07T07:56:37.471Z : Executing phase ZDM_PARALLEL_EXPORT_IMPORT
zdmhost: 2024-02-07T07:56:37.482Z : Skipping phase ZDM_DATAPUMP_EXPORT_SRC_BATCH1 on resume
zdmhost: 2024-02-07T07:56:37.485Z : Skipping phase ZDM_TRANSFER_DUMPS_SRC_BATCH1 on resume
zdmhost: 2024-02-07T07:56:37.487Z : Executing phase ZDM_DATAPUMP_IMPORT_TGT_BATCH1
zdmhost: 2024-02-07T07:56:38.368Z : listing directory path /mnt/nfs_nfs_share/ONPR on node ExaCC-cl01n1.domain.com ...
zdmhost: 2024-02-07T07:56:39.474Z : Oracle Data Pump Import parallelism set to 1 ...
zdmhost: 2024-02-07T07:56:39.481Z : Oracle Data Pump errors to be ignored are ORA-31684,ORA-39111,ORA-39082...
zdmhost: 2024-02-07T07:56:39.481Z : starting Data Pump Import for database "ONPRZ_APP_001T.DOMAIN.COM"
zdmhost: 2024-02-07T07:56:39.482Z : running Oracle Data Pump job "ZDM_29_DP_IMPORT_5005_BATCH1" for database "ONPRZ_APP_001T.DOMAIN.COM"
zdmhost: 2024-02-07T08:00:46.569Z : Oracle Data Pump job "ZDM_29_DP_IMPORT_5005_BATCH1" for database "ONPRZ_APP_001T.DOMAIN.COM" completed.
zdmhost: 2024-02-07T08:00:46.569Z : Oracle Data Pump log located at /mnt/nfs_nfs_share/ONPR/ZDM_29_DP_IMPORT_5005_BATCH1.log in the Database Server node
zdmhost: 2024-02-07T08:01:17.239Z : Execution of phase ZDM_DATAPUMP_IMPORT_TGT_BATCH1 completed
zdmhost: 2024-02-07T08:01:17.248Z : Execution of phase ZDM_PARALLEL_EXPORT_IMPORT completed
zdmhost: 2024-02-07T08:01:17.268Z : Executing phase ZDM_POST_DATAPUMP_SRC
zdmhost: 2024-02-07T08:01:17.272Z : listing directory path /mnt/nfs_share/ONPR/ on node vmonpr.domain.com ...
zdmhost: 2024-02-07T08:01:17.811Z : deleting Data Pump dump in directory path /mnt/nfs_share/ONPR/ on node vmonpr.domain.com ...
zdmhost: 2024-02-07T08:01:19.052Z : Execution of phase ZDM_POST_DATAPUMP_SRC completed
zdmhost: 2024-02-07T08:01:19.070Z : Executing phase ZDM_POST_DATAPUMP_TGT
zdmhost: 2024-02-07T08:01:19.665Z : Execution of phase ZDM_POST_DATAPUMP_TGT completed
zdmhost: 2024-02-07T08:01:19.689Z : Executing phase ZDM_POST_ACTIONS
zdmhost: 2024-02-07T08:01:19.693Z : Execution of phase ZDM_POST_ACTIONS completed
zdmhost: 2024-02-07T08:01:19.716Z : Executing phase ZDM_CLEANUP_SRC
zdmhost: 2024-02-07T08:01:20.213Z : Cleaning up ZDM on the source node vmonpr ...
zdmhost: 2024-02-07T08:01:21.458Z : Execution of phase ZDM_CLEANUP_SRC completed
[zdmuser@zdmhost ~]$

If we check the ZDM import log saved on the NFS shared folder, here named ZDM_32_DP_IMPORT_1847_BATCH1.log, we would see that the import has been done successfully with 3 errors. The 3 errors are displayed in the same log file and are:

09-FEB-24 10:00:22.534: W-1 Processing object type SCHEMA_EXPORT/USER
09-FEB-24 10:00:22.943: ORA-31684: Object type USER:"USER1" already exists
09-FEB-24 10:00:22.943: ORA-31684: Object type USER:"USER2" already exists
09-FEB-24 10:00:22.943: ORA-31684: Object type USER:"USER3" already exists

These errors are here because we created the user on the ExaCC target DB previously to resuming zdmcli job, thus before performing the import again. These errors are fortunately part of the list that ZDM would ignore, which make senses.

Checks

We can then of course do some tests as comparing the number of objects for the migrated users on the source and the target, checking pdb violation, checking invalid objects, ensuring that tablespace are encrypted on the ExaCC target DB, and so on.

To compare number of objects:

SQL> select owner, count(*) from dba_objects where owner in ('USER1','USER2','USER3') group by owner order by 1;

OWNER             COUNT(*)
--------------- ----------
USER3                758
USER2                760

To check that tablespace are encrypted:

SQL> select a.con_id, a.tablespace_name, nvl(b.ENCRYPTIONALG,'NOT ENCRYPTED') from  cdb_tablespaces a, (select x.con_id, y.ENCRYPTIONALG, x.name from V$TABLESPACE x,  V$ENCRYPTED_TABLESPACES y where x.ts#=y.ts# and x.con_id=y.con_id) b where a.con_id=b.con_id(+) and a.tablespace_name=b.name(+) order by 1,2;

To check pdb violations:

SQL> select status, message from pdb_plug_in_violations;

To check invalid objects:

SQL> select count(*) from dba_invalid_objects;

And we could, of course, if needed, relocate the PDB to another ExaCC CDB.

Conclusion

That’s it. We could easily migrate a single-tenant on-premise database to ExaCC PDB using ZDM Logical Offline. The tools really have advantages. We do not need to deal with any oracle command, like running datapump on ourselves.

In the next blog I will show you we migrated on-premises database to ExaCC on our customer system using ZDM Physical Online Migration.

L’article Logical Offline Migration to ExaCC with Oracle Zero Downtime Migration (ZDM) est apparu en premier sur dbi Blog.

Query taking very long.

Tom Kyte - Tue, 2024-02-20 10:46
Hi Tom, I'm facing an issue somewhat strange and to which a have no clear answer. The database version that I'm using is 12.1.0.1.0 on Windows 64 (both Standard and EE). With 11G (I believe) Oracle started using the Unified Audit Trail. The default "rules" for my version (12c) inserts a new record in the audit table every time a user connects to the DB. Because these databases are not mine, the size of the tablespace (SYSAUX), was not under surveillance and has grown to a considerable size without anyone noticing it. At the moment the tablespace and table are around 16GB and 14GB. We have tried to remove the information from the table and that process is ongoing. My question is: In the DBs where this table and tablespace have grown to such sizes, any (or many) query run against a object in that tablespace take a huge amount of time. Of course, I know that if a object is very large, then that means it's going to take a long time to read, but here we are talking about a really large amount of time. When I'm executing a query against that tablespace the disk subsystem (SSD disks) starts to read about 130 MBs a second. In a symplistic way, one could say that it should read the necessary 16GB in a bit less than 200 seconds, but the system takes more than 10 minutes (I never allowed it to actually finish because these are PROD systems). What I would like to know is if there is anything specific about objects inside the SYSAUX tablespace (namely the unified audit trail objects and the scheduler job objects) that could explain such a delay in execution while having such a huge disk access (reads). Thank you very much, hugo
Categories: DBA Blogs

Keep your data sorted with AI

Yann Neuhaus - Tue, 2024-02-20 09:08

As mentioned in my previous posts about Enterprise Content Management (like this one). A key point to have your Content efficiently stored is the use of Metadata. It helps to sort and retrieve easily your company data.

But to be honest, this part is often boring for technical people like me. Imagine it for people for whom IT is just a tool to get the job done.

On the one hand, we need to be precise to have a fine organization, but on the other hand, the more metadata we insert, the less likely we are to have filled them correctly.

Based on my experience, if there are a lot of properties required before uploading or creating a document, it leads irremediably to a partial adoption of the solution. Or even worst to wrong information associated to the document, which can cause other issues and prevent the system to serve the business as designed.

All the challenge is to find the right balance. But no worries, M-Files is there, to help you!

Let’s introduce the M-Files Intelligent Metadata Layer module.

IML includes 2 main aspects.

The First one is a repository-neutral approach to unify your Enterprise Content irrespective of the sources (as soon as a connector exists or you develop it ), as seen below:

M-Files Intelligent Metadata LayerM-Files IML (Source M-Files)

The second, the one we are interested of today, is Intelligent Services. These are artificial intelligence components that provide metadata suggestions by analyzing content with natural language processing techniques and text analytics.

Again this Intelligent Services is sub-divided into several services and we will focus on two:

M-Files Matcher

This module analyzes the documents and search for a matching value.

For example this module can catch the name of a supplier present in a document and suggest you to put it as a property “supplier” for the document.

Basic M-Files MatcherBasic M-Files Matcher

But It can also be more smart, like you have an e-mail address in the document, this e-mail address is the one used to contact the supplier, then M-Files can make the link and offer you to relate it to the document.

Advanced M-Files MatcherAdvanced M-Files Matcher M-Files Text Analytics

This module is a bit different, with some configuration made by your favorite M-Files administrator (us), it can suggest some property values detected in the document.

Of course, in the example below the capacities are not exhaustive

M-Files Text AnalyticsM-Files Text Analytics

Firstly based on the document title, we can select the type of document, in this case SOP or Procedure suggest the class “SOP Working copy”

Then it detect:

  • the title
  • the ID of the document
  • the short description
  • The department concerned by the document

As mentioned before, it is only suggestions. If you are not agree with a value, feel free to put your own.

This is what I configured for this example, but as soon as you can write a Regular expression to catch the data then you can automate it, Awesome!

Find more information about M-Files AI click here.

L’article Keep your data sorted with AI est apparu en premier sur dbi Blog.

What PS/Query is that?

David Kurtz - Tue, 2024-02-20 06:05

Sometimes, performance analysis will turn up a problem SQL query that is probably a PS/Query. However, I need to know which PS/Query it is should I wish to alter it or talk to the user who wrote it. 

Is it a PS/Query?

It is quite easy to spot SQL queries that are generated from queries defined in the PS/Query tool. These are typical characteristics:

  • Single character row source aliases (eg. A, B, D) 
  • The same row source with a suffix 1 (eg. D1) for query security records.
  • Effective date/sequence subqueries are always correlated back to the same table.
  • Order by column position number rather than column names or aliases.
Sometimes, you may find SQL that looks like a PS/Query coming from other parts of PeopleSoft because a developer has copied the text of a PS/Query, usually into an Application Engine step.
SELECT A.EMPLID, A.ATTENDANCE, A.COURSE, B.DESCR, D.NAME, A.SESSION_NBR,
TO_CHAR(A.STATUS_DT,'YYYY-MM-DD'),B.COURSE
FROM PS_TRAINING A, PS_COURSE_TBL B, PS_PERSONAL_DTA_VW D, PS_PERS_SRCH_QRY D1
WHERE D.EMPLID = D1.EMPLID
AND D1.ROWSECCLASS = 'HCDPALL'
AND ( A.COURSE = :1
AND A.ATTENDANCE IN ('S','W')
AND A.COURSE = B.COURSE
AND A.EMPLID = D.EMPLID )

The text of a PS/Query is not stored in the database.  Instead, as with other objects in PeopleSoft, it is held as various rows in PeopleTools tables.  The PSQRY% tables are used to generate the SQL on demand.  We can query these tables to identify the query.  

PSQRYRECORD holds a row for every record referenced in the query (not including effective date/sequence subqueries).  My usual tactic is to write a SQL query on PSQRYRECORD, like the one below, that looks for PS/Queries that reference these tables with these table aliases (see PeopleSoft for the Oracle DBA, Chapter 11).  
REM findqry.sql
REM (c)Go-Faster Consultancy 2012

SELECT a.oprid, a.qryname
FROM   psqryrecord a
,      psqryrecord b
,      psqryrecord d
WHERE  a.oprid = b.oprid
AND    a.qryname = b.qryname
AND    a.oprid = d.oprid
AND    a.qryname = d.qryname
AND    a.corrname = 'A'
AND    a.recname = 'TRAINING'
AND    b.corrname = 'B'
AND    b.recname = 'COURSE_TBL'
AND    d.corrname = 'D'
AND    d.recname = 'PERSONAL_DTA_VW'
/
The example PS/Query above is TRN003__COURSE_WAITING_LIST from the HCM demo database.  However, my query on PSQRYRECORD found another PS/Queries with the same 3 records using the same row source aliases.  It is worth looking at queries on the same tables as they often suffer from the same problems, and you might want to make the same fix.  
Another source of results for this query (though not this time) can be when users copy a public PS/Query to a private one so they can alter it in isolation.
OPRID                          QRYNAME
------------------------------ ------------------------------
                               TRN002__SESSION_ROSTER
                               TRN003__COURSE_WAITING_LIST

Writing the query on PSQRYRECORD to find queries, which always is slightly different each time, is quite boring.  So I have written a script that will dynamically generate the SQL to identify a PS/Query.

Start with a SQL_ID
A SQL tuning activity will usually identify the SQL_ID and plan hash value of a statement.  If you are lucky, AWR will have captured the text and execution plan.  If not, you may have to try looking for a different SQL_ID that produces the same execution plan.  From the statement text, it is easy to see whether it might be a PS/Query.  
In this example, I have cut the SQL statement and execution plan back to show just the tables and indexes referenced.
SQL_ID c3h6vf2w5fxgp
--------------------
SELECT …
FROM PSTREELEAF B, PSTREENODE C, PS_OPER_UNIT_TBL A, PS_PRODUCT_TBL G 
…
UNION SELECT …
FROM PSTREENODE D,PS_TREE_NODE_TBL E, PSTREELEAF F 
…

--------------------------------------------------------------------------------------------------------------------------
|   Id  | Operation                                   | Name             | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------------------------
|  *  7 |        INDEX STORAGE FAST FULL SCAN         | PSBPSTREELEAF    |   426K|    19M|       |  1178   (1)| 00:00:01 |
|    10 |          TABLE ACCESS BY INDEX ROWID BATCHED| PS_PRODUCT_TBL   |     1 |    41 |       |     3   (0)| 00:00:01 |
|  * 11 |           INDEX RANGE SCAN                  | PS_PRODUCT_TBL   |     1 |       |       |     2   (0)| 00:00:01 |
|  * 14 |              INDEX RANGE SCAN (MIN/MAX)     | PS_PRODUCT_TBL   |     1 |    21 |       |     2   (0)| 00:00:01 |
|  * 15 |       TABLE ACCESS STORAGE FULL             | PSTREENODE       |   135K|  5709K|       |   663   (1)| 00:00:01 |
|  * 17 |       INDEX STORAGE FAST FULL SCAN          | PS_OPER_UNIT_TBL |  1791 | 35820 |       |     4   (0)| 00:00:01 |
|  * 20 |       INDEX RANGE SCAN (MIN/MAX)            | PS_PSTREENODE    |     1 |    33 |       |     3   (0)| 00:00:01 |
|  * 23 |       INDEX RANGE SCAN (MIN/MAX)            | PSAPSTREELEAF    |     1 |    32 |       |     3   (0)| 00:00:01 |
|  * 26 |       INDEX RANGE SCAN (MIN/MAX)            | PS_OPER_UNIT_TBL |     1 |    20 |       |     2   (0)| 00:00:01 |
|    33 |          TABLE ACCESS INMEMORY FULL         | PS_TREE_NODE_TBL | 35897 |  1647K|       |     6   (0)| 00:00:01 |
|  * 35 |          TABLE ACCESS STORAGE FULL          | PSTREENODE       |   167K|  9670K|       |   663   (1)| 00:00:01 |
|- * 36 |       INDEX RANGE SCAN                      | PS_PSTREELEAF    |     1 |    39 |       |  1267   (1)| 00:00:01 |
|    37 |      INDEX STORAGE FAST FULL SCAN           | PS_PSTREELEAF    |   480K|    17M|       |  1267   (1)| 00:00:01 |
|  * 40 |       INDEX RANGE SCAN (MIN/MAX)            | PS_PSTREENODE    |     1 |    33 |       |     3   (0)| 00:00:01 |
|  * 43 |       INDEX RANGE SCAN (MIN/MAX)            | PS_TREE_NODE_TBL |     1 |    28 |       |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

…
   7 - SEL$1 / B@SEL$1
  10 - SEL$1 / G@SEL$1
  11 - SEL$1 / G@SEL$1
…
  15 - SEL$1 / C@SEL$1
  17 - SEL$1 / A@SEL$1
…
  33 - SEL$6 / E@SEL$6
  35 - SEL$6 / D@SEL$6
  36 - SEL$6 / F@SEL$6
  37 - SEL$6 / F@SEL$6
…

I use this query on DBA_HIST_SQL_PLAN to extract the tables that have single-character row source aliases that correspond to PeopleSoft records, and put them into PLAN_TABLE. I use this table because it is delivered by Oracle as a global temporary table, so it is always there and I can make use of it even if I only have read-only access.

INSERT INTO plan_table (object_name, object_alias) 
with p as ( --plan lines with single letter aliases
SELECT DISTINCT object_owner, object_type, object_name, regexp_substr(object_alias,'[[:alpha:]]',2,1) object_alias
from dba_hist_sql_plan p
, ps.psdbowner d
where p.sql_id = '&&sql_id' --put SQL ID here--
and p.object_name IS NOT NULL
and p.object_owner = d.ownerid
and regexp_like(object_alias,'"[[:alpha:]]"') --single character aliases
), r as ( --PeopleSoft table records and the table name
select r.recname, DECODE(r.sqltablename,' ','PS_'||r.recname,r.sqltablename) sqltablename
from psrecdefn r
where r.rectype = 0 --PeopleSoft table records
)
select r.recname, object_alias --referenced table
from p, r
where p.object_type like 'TABLE%'
and p.object_name = r.sqltablename
union --a query plan may reference an index and not the table
select r.recname, object_alias --table for referenced index
from p, r
, all_indexes i
where p.object_type like 'INDEX%'
and i.index_name = p.object_name
and i.owner = p.object_owner
and i.table_name = r.sqltablename
order by 2,1
/
I now have a list of records and row source aliases aliases
RECNAME         O
--------------- -
OPER_UNIT_TBL   A
PSTREELEAF      B
PSTREENODE      C
PSTREENODE      D
TREE_NODE_TBL   E
PSTREELEAF      F
PRODUCT_TBL     G

Next, I can run this anonymous PL/SQL block to dynamically build the SQL query on PSQRYRECORD (one reference for every table) and execute it to find the matching PS/Queries

DECLARE 
  l_sep1 VARCHAR2(20);
  l_sep2 VARCHAR2(20);
  l_counter INTEGER := 0;
  l_sql CLOB := 'SELECT r1.oprid, r1.qryname';
  l_where CLOB;
  
  TYPE t_query IS RECORD (oprid VARCHAR2(30), qryname VARCHAR2(30));
  TYPE a_query IS TABLE OF t_query INDEX BY PLS_INTEGER;
  l_query a_query;
BEGIN
  FOR i IN(
    SELECT *
    FROM plan_table
    ORDER BY object_alias
  ) LOOP
    l_counter := l_counter + 1;
    dbms_output.put_line(i.object_alias||':'||i.object_name);
    IF l_counter = 1 THEN
      l_sep1 := ' FROM ';
      l_sep2 := ' WHERE ';
    ELSE
      l_sep1 := ' ,';
      l_sep2 := ' AND ';
      l_where := l_where||' AND r1.oprid = r'||l_counter||'.oprid AND r1.qryname = r'||l_counter||'.qryname';
    END IF;
    l_sql := l_sql||l_sep1||'psqryrecord r'||l_counter;
    l_where := l_where||l_sep2||'r'||l_counter||'.corrname = '''||i.object_alias||''' AND r'||l_counter||'.recname = '''||i.object_name||'''';
  END LOOP;
  l_sql := l_sql||l_where||' ORDER BY 1,2';
  dbms_output.put_line(l_sql);

  EXECUTE IMMEDIATE l_sql BULK COLLECT INTO l_query;

  FOR indx IN 1 .. l_query.COUNT
  LOOP
    DBMS_OUTPUT.put_line (indx||':'||l_query(indx).oprid||'.'||l_query(indx).qryname);
  END LOOP;
END;
/

The seven records found in my execution plan become a query of PSQRYRECORD 7 times, one for each record, joined on operator ID and query name.

SELECT r1.oprid, r1.qryname 
FROM psqryrecord r1 ,psqryrecord r2 ,psqryrecord r3 ,psqryrecord r4 ,psqryrecord r5 ,psqryrecord r6 ,psqryrecord r7 
WHERE r1.corrname = 'A' AND r1.recname = 'OPER_UNIT_TBL'
AND r1.oprid = r2.oprid AND r1.qryname = r2.qryname AND r2.corrname = 'B' AND r2.recname = 'PSTREELEAF' 
AND r1.oprid = r3.oprid AND r1.qryname = r3.qryname AND r3.corrname = 'C' AND r3.recname = 'PSTREENODE' 
AND r1.oprid = r4.oprid AND r1.qryname = r4.qryname AND r4.corrname = 'D' AND r4.recname = 'PSTREENODE' 
AND r1.oprid = r5.oprid AND r1.qryname = r5.qryname AND r5.corrname = 'E' AND r5.recname = 'TREE_NODE_TBL' 
AND r1.oprid = r6.oprid AND r1.qryname = r6.qryname AND r6.corrname = 'F' AND r6.recname = 'PSTREELEAF' 
AND r1.oprid = r7.oprid AND r1.qryname = r7.qryname AND r7.corrname = 'G' AND r7.recname = 'PRODUCT_TBL' 
ORDER BY 1,2
The query finds several queries. I can look at the public PS/Queries in the Query Manager tool.  I can also see which users' private queries exist.
NB. You can only open public queries (where OPRID is a single space) or your own private queries.  In the Query Manager, you cannot see a private query owned by another user.
…
3: .PS_TREE_PRODUCT
4: .QUERY_PRODUCT_TREE
5: .RM_TREE_PRODUCT
6:XXXXXX.PS_TREE_PRODUCT_XX
…
The new findqry.sql script is available on Github.

Automation : Increasing pressure on an existing constraint

Tim Hall - Tue, 2024-02-20 03:58

Yesterday I tweeted that I was reminded of this post. I was reminded of it because of something that is happening to me at work, so I thought I would talk about it here. Production lines If you’ve read anything about DevOps you will know it came from manufacturing. If you didn’t know that, check … Continue reading "Automation : Increasing pressure on an existing constraint"

The post Automation : Increasing pressure on an existing constraint first appeared on The ORACLE-BASE Blog.Automation : Increasing pressure on an existing constraint was first posted on February 20, 2024 at 10:58 am.
©2012 "The ORACLE-BASE Blog". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement.

Extracting Invoice Structured Output with Haystack and Ollama Local LLM

Andrejus Baranovski - Tue, 2024-02-20 02:49
I implemented Sparrow agent with Haystack structured output functionality to extract invoice data. This runs locally through Ollama, using LLM to retrieve key/value pairs data. 

 

Kubernetes Networking by Using Cilium – Intermediate Level – Part-1

Yann Neuhaus - Tue, 2024-02-20 01:36

If you are new or uneasy with networking in Kubernetes, you may benefit from my previous blog for beginner level. In this blog post I will show you in a Kubernetes cluster what a building and its networking components look like. As a reminder, below is the picture I drew in my previous blog to illustrate the networking in a Kubernetes cluster with Cilium:

If you want to understand this networking in Kubernetes in more details, read on, this blog post is for you! I’ll consider you know the basics about Kubernetes and how to interact with it, otherwise you may find our training course on it very interesting (in English or in French)!

Diving into the IP Addresses configuration

Let’s start by checking our environment and update our picture with real information from our Kubernetes cluster:

$ kubectl get no -owide
NAME                      STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                         KERNEL-VERSION      CONTAINER-RUNTIME
mycluster-control-plane   Ready    control-plane   113d   v1.27.3   172.18.0.3    <none>        Debian GNU/Linux 11 (bullseye)   5.15.0-94-generic   containerd://1.7.1
mycluster-worker          Ready    <none>          113d   v1.27.3   172.18.0.2    <none>        Debian GNU/Linux 11 (bullseye)   5.15.0-94-generic   containerd://1.7.1
mycluster-worker2         Ready    <none>          113d   v1.27.3   172.18.0.4    <none>        Debian GNU/Linux 11 (bullseye)   5.15.0-94-generic   containerd://1.7.1

$ kubectl get po -n networking101 -owide
NAME                        READY   STATUS    RESTARTS      AGE     IP            NODE                NOMINATED NODE   READINESS GATES
busybox-c8bbbbb84-fmhwc     1/1     Running   1 (24m ago)   3d23h   10.10.1.164   mycluster-worker2   <none>           <none>
busybox-c8bbbbb84-t6ggh     1/1     Running   1 (24m ago)   3d23h   10.10.2.117   mycluster-worker    <none>           <none>
netshoot-7d996d7884-fwt8z   1/1     Running   0             79s     10.10.2.121   mycluster-worker    <none>           <none>
netshoot-7d996d7884-gcxrm   1/1     Running   0             80s     10.10.1.155   mycluster-worker2   <none>           <none>

You can now see for real that the IP subnets of the pods are different than the one of the nodes. Also the IP subnet of pods on each node is different from each other. If you are not sure why, you are perfectly right because it is not so clear at this stage. So let’s clarify it by checking our Cilium configuration.

I’ve told you in my previous blog that there is one Cilium Agent per building. This Agent is a pod itself and he takes care about networking in the node. This is what they look like in our cluster:

$ kubectl get po -n kube-system -owide|grep cilium
cilium-9zh9s                                      1/1     Running   5 (65m ago)   113d   172.18.0.3    mycluster-control-plane   <none>           <none>
cilium-czffc                                      1/1     Running   5 (65m ago)   113d   172.18.0.4    mycluster-worker2         <none>           <none>
cilium-dprvh                                      1/1     Running   5 (65m ago)   113d   172.18.0.2    mycluster-worker          <none>           <none>
cilium-operator-6b865946df-24ljf                  1/1     Running   5 (65m ago)   113d   172.18.0.2    mycluster-worker          <none>           <none>

There is two things to notice here:

  • The Cilium Agent is a Daemonset so that is how you make sure to always have one on each node of our cluster. As it is a pod, it also gets an IP Address… but wait a minute… this is the same IP Address as the node! Exactly! This is a special case for pods IP Address assignation, usually for system pods that need direct access to the node (host) network. If you look at the pods in the kube-system namespace, you’ll see most of them uses the node IP Address.
  • The Cilium Operator pod is responsible for IP address management in the cluster and so it gives to each Cilium Agent its range to use.

Now you want to see which IP range is used by each node right? Let’s just check that Cilium Agent on each node as we have found their name above:

$ kubectl exec -it -n kube-system cilium-dprvh -- cilium debuginfo | grep IPAM
Defaulted container "cilium-agent" out of: cilium-agent, config (init), mount-cgroup (init), apply-sysctl-overwrites (init), mount-bpf-fs (init), clean-cilium-state (init), install-cni-binaries (init)
IPAM:                   IPv4: 5/254 allocated from 10.10.2.0/24,

$ kubectl exec -it -n kube-system cilium-czffc -- cilium debuginfo | grep IPAM
Defaulted container "cilium-agent" out of: cilium-agent, config (init), mount-cgroup (init), apply-sysctl-overwrites (init), mount-bpf-fs (init), clean-cilium-state (init), install-cni-binaries (init)
IPAM:                   IPv4: 5/254 allocated from 10.10.1.0/24,

You can now see the different IP subnet on each node. In my previous blog I told you that an IP Address belong to a group and it uses the subnet mask. This subnet mask is here /24 which means for the first node that any address starting with 10.10.2 belongs to the same group. For the second node it is 10.10.1 and so they are both in a separate group or IP subnet.

What now about checking the interfaces that are the doors of our drawing?

Diving into the interfaces configuration

Let’s explore our buildings and see what we could find out! We are going to start with our four pods:

$ kubectl get po -n networking101 -owide
NAME                        READY   STATUS    RESTARTS       AGE    IP            NODE                NOMINATED NODE   READINESS GATES
busybox-c8bbbbb84-fmhwc     1/1     Running   1 (125m ago)   4d1h   10.10.1.164   mycluster-worker2   <none>           <none>
busybox-c8bbbbb84-t6ggh     1/1     Running   1 (125m ago)   4d1h   10.10.2.117   mycluster-worker    <none>           <none>
netshoot-7d996d7884-fwt8z   1/1     Running   0              103m   10.10.2.121   mycluster-worker    <none>           <none>
netshoot-7d996d7884-gcxrm   1/1     Running   0              103m   10.10.1.155   mycluster-worker2   <none>           <none>

$ kubectl exec -it -n networking101 busybox-c8bbbbb84-t6ggh -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
8: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
    link/ether 9e:80:70:0d:d9:37 brd ff:ff:ff:ff:ff:ff
    inet 10.10.2.117/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::9c80:70ff:fe0d:d937/64 scope link
       valid_lft forever preferred_lft forever

$ kubectl exec -it -n networking101 netshoot-7d996d7884-fwt8z -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ea:c4:71:d6:4f:a0 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.10.2.121/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::e8c4:71ff:fed6:4fa0/64 scope link
       valid_lft forever preferred_lft forever

$ kubectl exec -it -n networking101 netshoot-7d996d7884-gcxrm -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
12: eth0@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether be:57:3d:54:40:f1 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 10.10.1.155/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::bc57:3dff:fe54:40f1/64 scope link
       valid_lft forever preferred_lft forever

$ kubectl exec -it -n networking101 busybox-c8bbbbb84-fmhwc -- ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
    link/ether 2a:7f:05:a0:69:db brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.164/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::287f:5ff:fea0:69db/64 scope link
       valid_lft forever preferred_lft forever

You can see that each container has only one network interface in addition to its local loopback. The format is for example 8: eth0@if9 which means the interface in the container has the number 9 and is linked to its pair interface number 8 of the node it is hosted on. These are the 2 doors connected by a corridor in my drawing.

Then check the nodes network interfaces:

$ sudo docker exec -it mycluster-worker ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5e:84:64:22:90:7f brd ff:ff:ff:ff:ff:ff
3: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ca:7e:e1:cc:4e:74 brd ff:ff:ff:ff:ff:ff
    inet 10.10.2.205/32 scope global cilium_host
       valid_lft forever preferred_lft forever
4: cilium_vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether f6:bf:81:9b:e2:c5 brd ff:ff:ff:ff:ff:ff
5: eth0@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::2/64 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:2/64 scope link
       valid_lft forever preferred_lft forever
7: lxc_health@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 8a:de:c1:2c:f5:83 brd ff:ff:ff:ff:ff:ff link-netnsid 1
9: lxc4a891387ff1a@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d6:21:74:eb:67:6b brd ff:ff:ff:ff:ff:ff link-netns cni-67a5da05-a221-ade5-08dc-64808339ad05
11: lxc5b7b34955e61@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f2:80:da:a5:17:74 brd ff:ff:ff:ff:ff:ff link-netns cni-0b438679-e5d3-d429-85c0-b6e3c8914250
13: lxc73d2e1d7cf4f@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f6:87:b6:c3:a6:45 brd ff:ff:ff:ff:ff:ff link-netns cni-f608f13c-1869-6134-3d6b-a0f76fd6d483

$ sudo docker exec -it mycluster-worker2 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether f2:91:2b:31:1f:47 brd ff:ff:ff:ff:ff:ff
3: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether be:7f:e0:2b:d6:b1 brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.55/32 scope global cilium_host
       valid_lft forever preferred_lft forever
4: cilium_vxlan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether e6:c8:8d:5d:1e:2d brd ff:ff:ff:ff:ff:ff
6: lxc_health@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d2:cf:ec:4c:51:b6 brd ff:ff:ff:ff:ff:ff link-netnsid 1
8: lxcdc5fb9751595@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether fe:b4:3a:e0:67:a3 brd ff:ff:ff:ff:ff:ff link-netns cni-c0d4bea2-92fd-03fb-ba61-3656864d8bd7
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:42:ac:12:00:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.18.0.4/16 brd 172.18.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fc00:f853:ccd:e793::4/64 scope global nodad
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe12:4/64 scope link
       valid_lft forever preferred_lft forever
11: lxc174c023046ff@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ae:7a:b9:6b:b3:c1 brd ff:ff:ff:ff:ff:ff link-netns cni-4172177b-df75-61a8-884c-f9d556165df2
13: lxce84a702bb02c@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 92:65:df:09:dd:28 brd ff:ff:ff:ff:ff:ff link-netns cni-d259ef79-a81c-eba6-1255-6e46b8d1c779

On each node there are several interfaces to notice. I’ll take the first node for example:

  • eth0@if6: As our Kubernetes cluster is created with Kind, a node is actually a container (and this interface open a corridor to its pair interface on my laptop). If it feels like the movie Inception, well, it is a perfectly correct comparison! This interface is the main door of the building.
  • lxc4a891387ff1a@if8: This is the pair interface number 8 that is linked to the left container above.
  • lxc73d2e1d7cf4f@if12: This is the pair interface number 12 that is linked to the right container above.
  • cilium_host@cilium_net: This is the circle interface in my drawing that allows the routing to/from other nodes in our cluster.
  • cilium_vxlan: This is the rectangle in my drawing and is the tunnel interface that will transport you to/from the other nodes in our cluster.

Let’s now get the complete picture by updating our drawing with these information:

Wrap up

With this foundation knowledge, you now have all the key elements to understand the communication between pods on the same node or on different nodes. This is what we will look at in my next blog post. Stay tuned!

L’article Kubernetes Networking by Using Cilium – Intermediate Level – Part-1 est apparu en premier sur dbi Blog.

APEX feature request, support needed!

Flavio Casetta - Tue, 2024-02-20 01:10
Categories: DBA Blogs

How to Secure all of Your Oracle Databases - Part 1

Pete Finnigan - Mon, 2024-02-19 16:26
How do you know how secure your Oracle databases are? How secure should your Oracle databases be? These are interesting questions that we will cover in this three part post. This first part is going to cover the high level....[Read More]

Posted by Pete On 19/02/24 At 01:43 PM

Categories: Security Blogs

AI not I

Greg Pavlik - Mon, 2024-02-19 12:50

The notion that what we call AI is somehow approaching a form on consciousness remains an absurdity: fantastical thinking by people who really ought to spend a minimal amount of time at least reading up on philosophy of mind. Generative AI fits perfectly into John Searle's Chinese Room (the main variation is probability replaces rules, which reflects the one major innovation of NLP over decades).

I don't mean to suggest the technology is not extremely useful - it is, and will become more so. But: reality check.

Oracle ZDM Migration – java.security.InvalidKeyException: invalid key format

Yann Neuhaus - Sun, 2024-02-18 11:04

ZDM tool migration requires SSH Passwordless Login without passphrase between ZDM Host, the source and the target. Configuring appropriate keys might still result in a java security exception on this one. In this blog I will tell you how to deal with such a problem. I faced this problem implementing ZDM to migrate On-Premise Database to new ExaCC at one of our customer.

Read more: Oracle ZDM Migration – java.security.InvalidKeyException: invalid key format Setting up SSH Passwordless Login

First of all we need to create the private and public key on the ZDM Host.

From the ZDM host, with zdmuser, go in the ~/.ssh folder and run ssh-keygen.

[zdmuser@zdmhost .ssh]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/zdmuser/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zdmuser/.ssh/id_rsa.
Your public key has been saved in /home/zdmuser/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:8uTp************************ziw zdmuser@zdmhost
The key's randomart image is:
+---[RSA 3072]----+
|   oo+==.        |
...
...
...
|    o.+..        |
+----[SHA256]-----+

This will create 2 keys, one private (id_rsa) and one public (id_rsa_pub).

Get the content of the public key.

[zdmuser@zdmhost .ssh]$ cat id_rsa.pub
ssh-rsa AAAA************************vaU= zdmuser@zdmhost

And add the content of the public RSA key to the authorized_keys file from both ExaCC Cluster VMs (target ExaCC-cl01n1 and ExaCC-cl01n2) opc user and the on-premises VM (source vmonpr) oracle user.

[opc@ExaCC-cl01n1 .ssh]$ echo "ssh-rsa AAAA************************vaU= zdmuser@zdmhost" >> authorized_keys

[opc@ExaCC-cl01n2 .ssh]$ echo "ssh-rsa AAAA************************vaU= zdmuser@zdmhost" >> authorized_keys

oracle@vmonpr:/home/oracle/.ssh/ [ONPR] echo "ssh-rsa AAAA************************vaU= zdmuser@zdmhost" >> authorized_keys

We will then test SSH connection to the 3 VMs and ensure no password are requested. Example:

[zdmuser@zdmhost migration]$ ssh opc@ExaCC-cl01n1
Last login: Fri Feb  2 16:58:04 2024 from 10.160.52.122
[opc@ExaCC-cl01n1 ~]$

Check ZDM migration

Checking ZDM migration with zdmcli and -eval option might get failed:

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_physical_online.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo -tdekeystorepasswd -tgttdekeystorepasswd -eval
zdmhost.domain.com: Audit ID: 50
Enter source database ONPR SYS password:
zdmhost: 2024-02-02T16:30:19.487Z : Processing response file ...
Operation "zdmcli migrate database" scheduled with the job ID "11".

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli query job -jobid 11
zdmhost.domain.com: Audit ID: 52
Job ID: 11
User: zdmuser
Client: zdmhost
Job Type: "EVAL"
Scheduled job command: "zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_physical_online.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo -tdekeystorepasswd -tgttdekeystorepasswd -eval"
Scheduled job execution start time: 2024-02-02T17:30:19+01. Equivalent local time: 2024-02-02 17:30:19
Current status: FAILED
Result file path: "/u01/app/oracle/chkbase/scheduled/job-11-2024-02-02-17:30:48.log"
Metrics file path: "/u01/app/oracle/chkbase/scheduled/job-11-2024-02-02-17:30:48.json"
Job execution start time: 2024-02-02 17:30:48
Job execution end time: 2024-02-02 17:30:48
Job execution elapsed time: 0 seconds

Result file "/u01/app/oracle/chkbase/scheduled/job-11-2024-02-02-17:30:48.log" contents:
zdmhost: 2024-02-02T16:30:48.591Z : Processing response file ...
zdmhost: 2024-02-02T16:30:48.595Z : Processing response file ...
PRCZ-4002 : failed to execute command "/bin/cp" using the privileged execution plugin "zdmauth" on nodes "ExaCC-cl01n1"
java.security.InvalidKeyException: invalid key format

Error of failed execution is :

java.security.InvalidKeyException: invalid key format
Solution

The problem is due to the fact that ZDM only supports RSA key and the generated key was an OPENSSH key.

Checking current key, we can see that the key is an openssh key:

[zdmuser@zdmhost .ssh]$ head -n1 id_rsa
-----BEGIN OPENSSH PRIVATE KEY-----

[zdmuser@zdmhost .ssh]$ tail -n 1 id_rsa
-----END OPENSSH PRIVATE KEY-----

We need to convert the private key to PEM format.

[zdmuser@zdmhost .ssh]$ ssh-keygen -p -m PEM -f ~/.ssh/id_rsa
Key has comment 'zdmuser@zdmhost'
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved with the new passphrase.

The new key looks now like.

[zdmuser@zdmhost .ssh]$ head -n1 id_rsa
-----BEGIN RSA PRIVATE KEY-----

[zdmuser@zdmhost .ssh]$ tail -n 1 id_rsa
-----END RSA PRIVATE KEY-----

And, now, zdmcli eval command is succeeding.

[zdmuser@zdmhost migration]$ /u01/app/oracle/product/zdm/bin/zdmcli query job -jobid 39
zdmhost.domain.com: Audit ID: 434
Job ID: 39
User: zdmuser
Client: zdmhost
Job Type: "EVAL"
Scheduled job command: "zdmcli migrate database -sourcesid ONPR -rsp /home/zdmuser/migration/zdm_ONPR_physical_online.rsp -sourcenode vmonpr -srcauth zdmauth -srcarg1 user:oracle -srcarg2 identity_file:/home/zdmuser/.ssh/id_rsa -srcarg3 sudo_location:/usr/bin/sudo -targetnode ExaCC-cl01n1 -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/zdmuser/.ssh/id_rsa -tgtarg3 sudo_location:/usr/bin/sudo -tdekeystorepasswd -tgttdekeystorepasswd -eval"
Scheduled job execution start time: 2024-02-14T14:18:19+01. Equivalent local time: 2024-02-14 14:18:19
Current status: SUCCEEDED
Result file path: "/u01/app/oracle/chkbase/scheduled/job-39-2024-02-14-14:18:29.log"
Metrics file path: "/u01/app/oracle/chkbase/scheduled/job-39-2024-02-14-14:18:29.json"
Job execution start time: 2024-02-14 14:18:29
Job execution end time: 2024-02-14 14:21:18
Job execution elapsed time: 2 minutes 48 seconds
ZDM_GET_SRC_INFO ........... PRECHECK_PASSED
ZDM_GET_TGT_INFO ........... PRECHECK_PASSED
ZDM_PRECHECKS_SRC .......... PRECHECK_PASSED
ZDM_PRECHECKS_TGT .......... PRECHECK_PASSED
ZDM_SETUP_SRC .............. PRECHECK_PASSED
ZDM_SETUP_TGT .............. PRECHECK_PASSED
ZDM_PREUSERACTIONS ......... PRECHECK_PASSED
ZDM_PREUSERACTIONS_TGT ..... PRECHECK_PASSED
ZDM_VALIDATE_SRC ........... PRECHECK_PASSED
ZDM_VALIDATE_TGT ........... PRECHECK_PASSED
ZDM_POSTUSERACTIONS ........ PRECHECK_PASSED
ZDM_POSTUSERACTIONS_TGT .... PRECHECK_PASSED
ZDM_CLEANUP_SRC ............ PRECHECK_PASSED
ZDM_CLEANUP_TGT ............ PRECHECK_PASSED

L’article Oracle ZDM Migration – java.security.InvalidKeyException: invalid key format est apparu en premier sur dbi Blog.

Alfresco – A never ending transformation

Yann Neuhaus - Fri, 2024-02-16 10:08

Beginning of the week, as I was working for our ServiceDesk (SLA support for our customers), I saw a few dozen mails generated by our monitoring over the weekend on a Production Alfresco 7.x Cluster doing the yo-yo in terms of RAM and Disk Space. Nothing was down, just some strange behavior where 20GB of free space would be gone and then re-appear after a few minutes and same thing for the RAM/SWAP.

The first thing I checked was the disk space mentioned on the alert. We received alerts from all members of the cluster one by one, almost in a perfect round-robin manner. On the second node, I saw the issue occurring in real-time, so I looked into what exactly was generating all the noise:

alfresco@alf-p2:~# date; df -h /tmp
Mon Feb 12 07:27:41 UTC 2024
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2        19G    7G   12G  35% /tmp
alfresco@alf-p2:~#
alfresco@alf-p2:~# date; df -h /tmp
Mon Feb 12 07:28:20 UTC 2024
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2        19G    9G    9G  49% /tmp
alfresco@alf-p2:~#
alfresco@alf-p2:~# du -sm /tmp/
9427    /tmp/
alfresco@alf-p2:~#
alfresco@alf-p2:~# du -sm /tmp/
9484    /tmp/
alfresco@alf-p2:~#
alfresco@alf-p2:~# du -sm /tmp/
9541    /tmp/
alfresco@alf-p2:~#

In less than a minute, around 2/3Gb of temporary files were generated, which doesn’t seem very healthy:

alfresco@alf-p2:~# cd /tmp
alfresco@alf-p2:/tmp#
alfresco@alf-p2:/tmp# ls -ltr
total 480
...
-rw-r-----   1 alfresco  alfresco    115 Feb 11 21:26 scheduler.json
drwxr-x---   2 alfresco  alfresco   4096 Feb 12 07:28 Alfresco/
drwxrwxrwt 117 root      root      12288 Feb 12 07:28 ./
alfresco@alf-p2:/tmp#
alfresco@alf-p2:/tmp# cd Alfresco/
alfresco@alf-p2:/tmp/Alfresco# ls -l
total 10553428
drwxr-x---   2 alfresco alfresco        4096 Feb 12 07:29 ./
drwxrwxrwt 117 root     root           12288 Feb 12 07:29 ../
-rw-r-----   1 alfresco alfresco     1897650 Feb 12 07:23 source_11877384286747332767_tmp.pdf
-rw-r-----   1 alfresco alfresco 10804789248 Feb 12 07:29 target_18121744399232974935_tmp.txt
alfresco@alf-p2:/tmp/Alfresco#
alfresco@alf-p2:/tmp/Alfresco#
alfresco@alf-p2:/tmp/Alfresco# ls -l
total 10686460
drwxr-x---   2 alfresco alfresco        4096 Feb 12 07:29 ./
drwxrwxrwt 117 root     root           12288 Feb 12 07:29 ../
-rw-r-----   1 alfresco alfresco     1897650 Feb 12 07:23 source_11877384286747332767_tmp.pdf
-rw-r-----   1 alfresco alfresco 10941014016 Feb 12 07:29 target_18121744399232974935_tmp.txt
alfresco@alf-p2:/tmp/Alfresco#

At that point in time, it looked like Alfresco was doing something that was causing the issue for the Disk Space, at least. Here, we can see a PDF file that is a “source” and a TXT file that appears to be under generation, as a “target”. So of course, my first thought here is that this is probably the Alfresco Transformation Service that is causing this issue, trying to transform a PDF into TXT, most probably for indexing of the content of this file.

While looking at the RAM/SWAP usage on this server, it was also showing the same thing, with the Java process of the ATS using 100% CPU (fortunately, the host has multiple CPUs) and going overboard with its RAM, forcing the host to SWAP.

Therefore, I looked at the ATS logs and saw 2 types of errors. First was a few IOException on PDFBox “Error: End-Of-File: expected line” but there wasn’t a lot of those… Then there was another error, much more present, that was the consequence of the FileSystem being full:

alfresco@alf-p2:~# cat $ATS_HOME/logs/transform-core-aio.log
...
2024-02-12 07:18:37.380 ERROR 23713 --- [o-8090-exec-141] o.a.transformer.TransformController      : Error writing: Seite 1

org.alfresco.transform.exceptions.TransformException: Error writing: Seite 1
        at org.alfresco.transformer.executors.Transformer.transform(Transformer.java:83) ~[alfresco-transformer-base-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.AIOController.transformImpl(AIOController.java:118) ~[classes!/:2.5.3]
        at org.alfresco.transformer.AbstractTransformerController.transform(AbstractTransformerController.java:173) ~[alfresco-transformer-base-2.5.3.jar!/:2.5.3]
        at jdk.internal.reflect.GeneratedMethodAccessor75.invoke(Unknown Source) ~[na:na]
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
        at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]
        ...
Caused by: java.lang.IllegalStateException: Error writing: Seite 1
        at org.alfresco.transformer.executors.Tika.transform(Tika.java:697) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.executors.Tika.transform(Tika.java:673) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.executors.Tika.transform(Tika.java:617) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.executors.TikaJavaExecutor.call(TikaJavaExecutor.java:141) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.executors.TikaJavaExecutor.transform(TikaJavaExecutor.java:131) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        at org.alfresco.transformer.executors.Transformer.transform(Transformer.java:70) ~[alfresco-transformer-base-2.5.3.jar!/:2.5.3]
        ... 55 common frames omitted
Caused by: org.xml.sax.SAXException: Error writing: Seite 1
        at org.apache.tika.sax.ToTextContentHandler.characters(ToTextContentHandler.java:110) ~[tika-core-1.26.jar!/:1.26]
        at org.apache.tika.sax.ContentHandlerDecorator.characters(ContentHandlerDecorator.java:146) ~[tika-core-1.26.jar!/:1.26]
        at org.apache.tika.sax.WriteOutContentHandler.characters(WriteOutContentHandler.java:136) ~[tika-core-1.26.jar!/:1.26]
        at org.apache.tika.sax.ContentHandlerDecorator.characters(ContentHandlerDecorator.java:146) ~[tika-core-1.26.jar!/:1.26]
        ...
        at org.alfresco.transformer.executors.Tika.transform(Tika.java:693) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
        ... 60 common frames omitted
        Suppressed: java.io.IOException: No space left on device
                at java.base/java.io.FileOutputStream.writeBytes(Native Method) ~[na:na]
                at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354) ~[na:na]
                at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) ~[na:na]
                at java.base/sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:337) ~[na:na]
                at java.base/sun.nio.cs.StreamEncoder.close(StreamEncoder.java:161) ~[na:na]
                at java.base/java.io.OutputStreamWriter.close(OutputStreamWriter.java:255) ~[na:na]
                at java.base/java.io.BufferedWriter.close(BufferedWriter.java:269) ~[na:na]
                at org.alfresco.transformer.executors.Tika.transform(Tika.java:684) ~[alfresco-transform-tika-2.5.3.jar!/:2.5.3]
                ... 60 common frames omitted
Caused by: java.io.IOException: No space left on device
        at java.base/java.io.FileOutputStream.writeBytes(Native Method) ~[na:na]
        at java.base/java.io.FileOutputStream.write(FileOutputStream.java:354) ~[na:na]
        at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:233) ~[na:na]
        at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:303) ~[na:na]
...
alfresco@alf-p2:~#

As you can see above, at 07:18, the FileSystem /tmp was 100% full and when I checked 5 minutes later, at 07:23, a new transformation was already producing a 10Gb text file and still growing. So, it was clear that this happens repeatedly, most probably for the same document. According to the monitoring, the issue started just before the weekend. Looking at the first occurrences of the FileSystem full from the ATS logs gave the following:

alfresco@alf-p2:~# grep '2024.*Error writing' $ATS_HOME/logs/transform-core-aio.log
2024-02-09 19:20:51.628 ERROR 23713 --- [o-8090-exec-166] o.a.transformer.TransformController      : Error writing:
2024-02-09 19:41:29.954 ERROR 23713 --- [o-8090-exec-156] o.a.transformer.TransformController      : Error writing: Seite 1
2024-02-09 20:02:11.764 ERROR 23713 --- [o-8090-exec-160] o.a.transformer.TransformController      : Error writing: Seite 1
2024-02-09 20:23:08.828 ERROR 23713 --- [o-8090-exec-163] o.a.transformer.TransformController      : Error writing:
2024-02-09 20:44:05.313 ERROR 23713 --- [o-8090-exec-141] o.a.transformer.TransformController      : Error writing: Seite 1
2024-02-09 21:04:52.642 ERROR 23713 --- [o-8090-exec-162] o.a.transformer.TransformController      : Error writing: Seite 1
...
2024-02-12 07:18:37.380 ERROR 23713 --- [o-8090-exec-152] o.a.transformer.TransformController      : Error writing: Seite 1
alfresco@alf-p2:~#

With the above, it pretty much confirms that it’s the same document that is always failing, since it’s blocking on “Seite 1“, which means “Page 1” in English.

To be able to find which document is causing the issue in Alfresco, there isn’t a lot of details available, since the ATS isn’t really giving you much about what it is doing. All I had was a temporary name (which obviously doesn’t trace back to anything in the Repository) and a size. Therefore, I checked for documents on the Alfresco Data (“alf_data“) with a size equal to the document “/tmp/Alfresco/source_11877384286747332767_tmp.pdf” (i.e. 1897650 bytes), created in the last few days. I expected it to be created on the 9-Feb, a little before 19:20 and I indeed found one:

alfresco@alf-p2:~# find /alf_data/contentstore/2024/2/ -type f -ls | grep 1897650
 34508512  1856 -rw-r----- 1 alfresco alfresco 1897650 Feb 9 19:02 /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
alfresco@alf-p2:~#
alfresco@alf-p2:~# md5sum /tmp/Alfresco/source_11877384286747332767_tmp.pdf /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
45ed40bd5f84b7c68e246885f2b6a55f  /tmp/Alfresco/source_11877384286747332767_tmp.pdf
45ed40bd5f84b7c68e246885f2b6a55f  /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
alfresco@alf-p2:~#
alfresco@alf-p2:~# diff /tmp/Alfresco/source_11877384286747332767_tmp.pdf /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
alfresco@alf-p2:~#

Therefore, this is the same content file. There is of course the possibility that a duplicate node was using the same content before February (as I searched only inside /2024/2, that means February), but since the issue appeared only over the weekend, it’s pretty safe to assume it’s this document/node.

alfresco@alf-p2:~# stat /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
  File: /alf_data/contentstore/2024/2/9/19/02/174f569e-93a3-4829-8ad5-bd3d6e78447b.bin
  Size: 1897650         Blocks: 3712       IO Block: 262144 regular file
Device: 34h/52d Inode: 34508512    Links: 1
Access: (0640/-rw-r-----)  Uid: (  113/alfresco)   Gid: (  116/alfresco)
Access: 2024-02-09 19:02:12.153002964 +0000
Modify: 2024-02-09 19:02:12.157983495 +0000
Change: 2024-02-09 19:02:12.157983635 +0000
 Birth: -
alfresco@alf-p2:~#

From that point, I had the “content_url” of a Node. Therefore, I could have used the Database (see useful database queries) to find the NodeRef of this Alfresco Node but at this customer, I don’t have an easy access to the DB, so I went through Share instead.

I know the node was created (or modified) at 19:02:12 (+/- 1s) on the 9-Feb, and even if the content isn’t indexed, its metadata should still be available searchable. Therefore, I just performed a search on Alfresco Share, to find documents created (or modified) at that exact time, i.e. cm:created:’2024-02-09T19:02:12′.

That gave me 4 results, out of which only 1 had a size around 2MB. To validate if this was indeed the document causing the issue, I simply used the JavaScript Console to dump this file and it gave me the exact same “content_url“. I could also validate on Share that this specific file wasn’t content-indexed yet (despite being in the repository for 2.5 days).

As a temporary workaround, to stop the OS from going crazy, I set this document as metadata-indexed only (no content), using the “Index Control” aspect. If you don’t know how this works, it’s pretty simple for a node:

  • Click on “Manage Aspect”
  • From the list of “Available to Add”, find “Index Control (cm:indexControl)”
  • Click on “+” to add it to the list of “Currently Selected”
  • Click on “Apply changes”
  • Click on “Edit Properties”
  • Uncheck the “Is Content Indexed” option

After doing that, you should be able to see something like that on the node’s properties:

Alfresco Index Control

In case a transformation for this document is already in progress, you will need to wait for the FileSystem to be full for the ATS (java) to remove its temporary file and realize that this document doesn’t need to be transformed anymore. You can probably also restart the process, if you prefer.

That’s only a workaround of course, not a real solution. Therefore, even if I knew that the issue was most probably around “Seite 1“, I replicated the issue on TEST by uploading this same file into the TEST environment and then looked inside the TXT content, to validate that assumption:

alfresco@alf-t1:/tmp/Alfresco# ls -l
total 23960
drwxr-x---  2 alfresco alfresco      4096 Feb 12 09:10 ./
drwxrwxrwt 25 root     root         36864 Feb 12 09:10 ../
-rw-r-----  1 alfresco alfresco   1897650 Feb 12 09:10 source_2995534351432950419_tmp.pdf
-rw-r-----  1 alfresco alfresco  22593536 Feb 12 09:10 target_7429882841367188802_tmp.txt
alfresco@alf-t1:/tmp/Alfresco#
alfresco@alf-t1:/tmp/Alfresco# wc -l target_7429882841367188802_tmp.txt
2509490 target_7429882841367188802_tmp.txt
alfresco@alf-t1:/tmp/Alfresco#
alfresco@alf-t1:/tmp/Alfresco# grep -v "^[[:space:]]*Seite 1$" target_7429882841367188802_tmp.txt | wc -l
1913
alfresco@alf-t1:/tmp/Alfresco#
alfresco@alf-t1:/tmp/Alfresco# sleep 30
alfresco@alf-t1:/tmp/Alfresco#
alfresco@alf-t1:/tmp/Alfresco# wc -l target_7429882841367188802_tmp.txt
83418233 target_7429882841367188802_tmp.txt
alfresco@alf-t1:/tmp/Alfresco#
alfresco@alf-t1:/tmp/Alfresco# grep -v "^[[:space:]]*Seite 1$" target_7429882841367188802_tmp.txt | wc -l
1913
alfresco@alf-t1:/tmp/Alfresco#

As shown above, there are 1913 lines of some texts and then the rest of the millions of lines are exactly “ Seite 1“. This text is actually coming from the page 34 of the PDF (it’s a merge of multiple PDFs it seems). By removing the page 34 from the document, it can be indexed properly. In the end, the “quick” solution for this customer is to fix the PDF (e.g. transform the page 34 into an image, then back into a PDF and OCRize it so it is indexed and searchable).

L’article Alfresco – A never ending transformation est apparu en premier sur dbi Blog.

An AWS journey in Geneva

Yann Neuhaus - Fri, 2024-02-16 09:18

This week I could go to the AWS re:Invent re:Cap in Geneva. This event, organized by AWS, gives a resume of the biggest announcements made in the famous re:Invent in Las Vegas.

The topics addressed during this event covered various cloud technologies where AWS is investing resources to develop. We had a recap of the news regarding Generative AI, Data and Analytics, App Modernization and Developer Experience or event Management and Governance.

Generative AI

In the generative AI part, we were mainly introduced to Amazon Q, a chat bot made in AWS. As of the features we saw that Q can integrate with more than 40 data sources. It also uses multiple sources for user management like AWS SSO or Entra ID. The main purpose is to answer user queries based on their rights to access documents, so the answers are filtered so users only what they are allowed to.

Database and Analytics

For the Database and Analytics topic we had an introduction to zero ETL. This topic shows AWS ambitions to reduce the need of pipelines. They want to create trust relationships between databases and redshift to get rid of the pipelines.

Another point presented in this topic was translator to generate SQL query based on the human language. This feature is used by Redshift and will enable people to create SQL queries based on natural phrases. It also uses Amazon Q as a base.

Applications and DevExp

During this session, we mainly learned about CodeCatalyst, which is a unified software development service. It allows us to do a full project management in one tool, with issues as Gitlab/Github. A big point here was the role of Amazon Q. We can directly assign issues to this IA tool and it will do the job to resolve it. Then we just have to commit the code, merge it and that’s it.

We also got an introduction to CodeWhisper, a tool that helps developer to create their code. This service is now compatible with IaC languages, like Terraform and it can be integrated directly into some IDEs like Visual Studio.

Management and Governance

Last but not least, we had an introduction to the newest features in terms of management and governance. In terms of security, we learned that AWS inspector can now be used with CI/CD plugins or that GuardDuty can now look at runtime events in containers.

We also had a talk about the frugal architect way int eh cloud, which are pillars created by Dr Vogel to help people have more sustainable and more performant cloud services by optimizing the costs. We were also introduce to the newest monitoring features for example a new Application panel that shows us all the costs for a specific application deployed in AWS.

Most of the features we saw were only on preview or available in some specific regions (mostly US regions). No doubt that all those features will soon be available globally.

L’article An AWS journey in Geneva est apparu en premier sur dbi Blog.

Business As Usual (BAU) vs Project Work

Tim Hall - Fri, 2024-02-16 07:10

I’ve had this conversation so many times over the years, and I’m sure I’ve written about elements of it several times, but I’m not sure I’ve written about it specifically before, so here goes… In every organisation there are conflicting demands from project work and business as usual (BAU) tasks. In case you’ve not heard … Continue reading "Business As Usual (BAU) vs Project Work"

The post Business As Usual (BAU) vs Project Work first appeared on The ORACLE-BASE Blog.Business As Usual (BAU) vs Project Work was first posted on February 16, 2024 at 2:10 pm.
©2012 "The ORACLE-BASE Blog". Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement.

Attach database error (SMB Fileshare)

Yann Neuhaus - Fri, 2024-02-16 05:48

Starting with SQL Server 2012, SQL Server supports databases using the Server Message Block (SMB) file server as a storage option. For performance and reliability reasons, SMB 3.0 or later is preferred to use.
For architectures like Always On Failover Cluster Instance (FCI), it can be a relevant alternative to cluster disks. To avoid a single point of failure (SPOF) scenario, the file shares should be high available.

Issue description

In a production context, we set up a FCI infrastructure, in Multi-AZ, on AWS using Amazon FSx as file share target – also in multi-AZ deployment to avoid SPOF scenario.
Everything run smoothly until a Detach / Attach approach was used at some point. SQL Server triggered the following error message 5120 at the Attach phase:

Msg 5120, Level 16, State 101, Line 12
Unable to open the physical file "\fsx-server\SharePath\Database.mdf". Operating system error 5: "5(Access is denied.)".
Msg 1802, Level 16, State 7, Line 12
CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

Even if SQL Server service account has Full Control on the files, it cannot attach back after the detach process.
In some documentation, you can find the recommendation to enable Trace Flag 1802, which will disable ACLs change and impersonated access verification during attach & detach operations. But another error (5123) appears anyway:

Msg 5123, Level 16, State 20, Line 11
CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file '\fsx-server\SharePath\Database.mdf'.
Detach Process

To understand the root-cause of this error, let’s dig into the Microsoft documentation regarding detaching process.
When detaching the database files, here are the following permissions applying on the files:

  • Without impersonation: the SQL Server service account and members of local Windows Administrator group (i.e. FSx related) are granted FULL control on the database files
  • With impersonation: only the account performing the operation is granted FULL control on the database files

Initially without Trace Flag 1802, we were in the first situation “without impersonation” after detaching the database:

  • ACLs inheritance is disabled on database files
  • SQL Server service account has FULL Control on the database files
  • Local Windows Administrator group of the File Server has FULL control on database files
Attach Process

Now, let’s now dig into the Attach process still from the Microsoft documentation.
When attaching database files to create the database in SQL Server, here are the following permissions which are applying to the files:

  • Without impersonation: only the SQL Server service account is added with FULL Control permissions
  • With impersonation: the SQL Server service account and members of the local Windows Administrator group are granted FULL Control permissions

The specificity of Attach process, compared to the creation of a database from scratch, it tries to apply NTFS changes on existing files. We will see this slightly difference is not insignificant.

SMB Security Requirements

Here are the requirements in the context the database files are located on an SMB file share for the SQL Server Service (domain) account:

  • FULL Control share permissions
  • FULL Control NTFS permissions on the SMB share folders
  • SeSecurityPriviledge (Local Security Policy on the File Server) is required to change get/set ACLs. This is true even if the account has FULL Control NTFS permissions on the database file
Issue root-cause

Attach process changes the current permissions of database files before creating the database in SQL Server. To do that, it requires to get/set ACLs on the files: so SeSecurityPriviledge is required at the File Server side in order to avoid error 5120 & 5123.
If you are managing the File server, this is a change you can implement and fix this issue. But in a context where SMB share is a Managed service, we were not able to fix it.

Limitations on Attach process is not blocking because it exists other approaches – such as Backup & Restore – but it can be disturbing when you are facing this issue without understanding the root-cause.
Similar to PaaS environments, Attach & Detach is not supported as soon as you have a managed service on the Operating System hosting the database files.

L’article Attach database error (SMB Fileshare) est apparu en premier sur dbi Blog.

High db block gets for inserting into reference partitioned table

Tom Kyte - Thu, 2024-02-15 01:46
Hello Tom, Could you please advise why I'm getting so huge difference in db block gets and redo for insert between range and reference partitioned table? Db block gets are like 100x more for reference partitioned table and insert is 2-3 times slower. <code> DB01> create table t1 (id number(19) primary key, ts date) 2 partition by range (ts) interval (numtodsinterval(1, 'DAY')) (partition P0001 values less than (to_date('2024-01-01' ,'YYYY-MM-DD'))); Table created. DB01> DB01> insert into t1 (id, ts) values (1, sysdate); 1 row created. DB01> DB01> DB01> -- range interval DB01> create table t2 (id number(19), t1_id number(19) not null, constraint t2_fk foreign key (t1_id) references t1 (id)) 2 partition by range (t1_id) interval (1) (partition values less than (1)); Table created. DB01> set autotrace trace exp stat DB01> insert into t2 (id, t1_id) select level, 1 from dual connect by level <= 2000000; 2000000 rows created. Execution Plan ---------------------------------------------------------- Plan hash value: 1236776825 ------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | INSERT STATEMENT | | 1 | 2 (0)| 00:00:01 | | 1 | LOAD TABLE CONVENTIONAL | T2 | | | | |* 2 | CONNECT BY WITHOUT FILTERING| | | | | | 3 | FAST DUAL | | 1 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(LEVEL<=2000000) Statistics ---------------------------------------------------------- 105 recursive calls 51252 db block gets 7237 consistent gets 0 physical reads 147628492 redo size 123 bytes sent via SQL*Net to client 391 bytes received via SQL*Net from client 1 SQL*Net roundtrips to/from client 2 sorts (memory) 0 sorts (disk) 2000000 rows processed DB01> set autotrace off DB01> commit; Commit complete. DB01> DB01> DB01> -- reference DB01> create table t3 (id number(19), t1_id number(19) not null, constraint t3_fk foreign key (t1_id) references t1 (id)) 2 partition by reference (t3_fk); Table created. DB01> set autotrace trace exp stat DB01> insert into t3 (id, t1_id) select level, 1 from dual connect by level <= 2000000; 2000000 rows created. Execution Plan ---------------------------------------------------------- Plan hash value: 1236776825 ------------------------------------------------------------------------------ | Id | Operation | Name | Rows ...
Categories: DBA Blogs

Kubernetes Networking by Using Cilium – Beginner Level

Yann Neuhaus - Wed, 2024-02-14 03:37

There seems to be a strong interest these days about understanding better networking in Kubernetes. This blog post is my contribution on this topic. I’ll do my best to explain it in a visual way and translate the techie part to an understandable language so that anybody can actually enjoy it.

The best way to learn networking is by doing what is called “Follow the packet” or “The life of a packet”. Basically, you follow the packet from the sender to the receiver by stopping at each step of this journey. I did that a while ago with a communication from a Pod to another Pod by using Calico. This time I’ll use another Container Network Interface (CNI) called Cilium which is based on eBPF (understand fast and flexible routing) and comes with a lot of powerful features and tools. Let’s hit that packet road!

Traditional Networking without Kubernetes

We are going to start from the beginning. I’ll consider you know nothing about networking. Maybe you already know what an IP Address is? The IP Address is the numerical Address of a network interface in a computer. This is how your computer can connect for example to your Wi-Fi network and give you access to the Internet. If you are using a laptop, your Wi-Fi network interface has one IP Address. This network interface also has another address that is unique and burnt on it by the hardware provider. This address is called the Medium Access Control (MAC) Address.

The IP Address belongs to a group (the IP Subnet). To know to which group it belongs to, it uses something called the Subnet Mask. This mask when applied to the IP Address gives a result and this result is identical for every IP Address that belong to the same group. This is like your community.

Let’s use the drawing below to make analogies:

The house is a computer, a server or a virtual machine. It could be of different sizes according to its CPU and memory but let use the same one for simplicity sake. A house has a door that is your network interface. The serial number of that door is your MAC Address and the number on your house (which is usually nailed on the door) is your IP Address. It is only if you change your door that your serial number will change. However, your house number has been assigned to you by the architect of your community and could change if there is a reassignment or a change in the design.

The community 10th (using numbers from 10 to 19) in blue belong to the same group (same IP subnet) and the community 20th in green is another group. In each group there are five houses so there is space for the community to grow. In each community the door has a direct link to a fountain which represents a Switch. At the fountain, there is a sign for each path to indicate which door you can reach. Yes, the fountain doesn’t know the house number but only the serial number of the door. For humans it is not very practical so we use a map (called the ARP table) that gives the translation between the house number and the serial number of its door.

If you live in house 14 and want to visit house 15, you’ll use the path (there is only one and it is yours so no traffic jams!) to the fountain first and then look at the signs. You know from your map which serial number correspond to which house and so you use the path to house 15. In this star topology you always go to the fountain first and not directly to the house you want to visit because there is no direct path. A path inside your community represents a Layer 2 link. You can’t reach another community by using these paths.

Traveling between communities

What now if from your house 14, you want to pay a visit to house 24? This is another community which means the couple IP Address / Subnet mask for 14 doesn’t produce the same result as for 24. Indeed the 10th and the 20th communities are different. So you know the destination is another community and in that case you have to go first to your gatekeeper (but always through the fountain as we have seen). He is the default gateway of your community and he lives in house 11. The rule is to go to him for any destinations that is outside of your community.

Only he has a map (the Routing Table) to reach community 20th and know which road to take (This is called Layer 3 routing because you are traveling outside of your community). This map shows that to reach 24 in the 20th community you have to use another door. Wait a minute, if a door is a network interface, does it mean that the gatekeeper house has another door? Absolutely correct! The house 11 has another door with another number on it (101) and of course this door has another serial number (MAC Address).

By exiting this door you can now take the path to reach community 20th which has its own gatekeeper in house 21. The map (Routing Table) of this gatekeeper directs you to the proper door to reach your destination. This door gives you access to community 20th as your destination 24 belongs to it. The gatekeeper also give you the map (ARP table) so you can orientate yourself at the fountain. You can now walk on the path to the green fountain. From there, you just have to follow the sign and the path to house 24. When you want to get back home, you travel back using the same path in the opposite direction.

Networking in Kubernetes

Now you know the basics about networking, let’s see how it works in comparison in Kubernetes. Yes it is slightly more complicated but let’s go step by step and use the picture below to understand it better:

Instead of houses, we now have buildings. The networking between the buildings is still the same as the traditional one with a Switch/fountain in the middle. The entrance of the building has a door with the building number on it (its IP Address) that is part of a 1000th community. One building will represent one node of our Kubernetes cluster.

You know Kubernetes is a container orchestrator. A container is wrapped into a pod. For simplicity sake, let’s consider a pod has only one container and so both terms are here equivalent. This pod will be one appartement in our building and so is like a private part of it. The apartment could be of different size in the building as it could have 2, 3 or 4 bedrooms for example. This will be the CPU and memory capacities your container will need on the node. Some appartement are empty so the building still has some capacity. However in Kubernetes, pods are created and deleted as needed. So in our building that would mean sometimes a 2 bedrooms appartement is created and when not used anymore, it could be removed from the building. Then a 5 bedrooms appartement could be created next if the building has enough space for it. Imagine then that it is a LEGO building and inside it you can build and demolish apartments of various size according to your need! Isn’t it awesome?

In each building, the containers/pods have their own community (IP subnet). The function of a CNI in Kubernetes is basically to assign numbers (IP Addresses) to pods so they can communicate together. By default Cilium uses different community for each building. When an apartment is created, Cilium assigns a number to it. When an apartment is deleted an recreated, it will get another number so it is ephemeral. Here the blue community uses the 10th range and the green one uses the 20th. You can notice that the number ranges of the blue and green communities are different than the range of the buildings. Just for you to know, this design is called Overlay network, there are other ones possible but that is a common one. There is then a network of pods on top of the network of the nodes.

Traveling between apartments in the same building

Now, you live in the apartment 12, how are you going to pay a visit to apartment 14? Like we did with the traditional networking example, you are the packet we are going to follow! Of course you leave the apartment (container) through its door (its network interface). The difference with our previous example is that you are now not out of the house, you are just out of your apartment but still inside the building. You then follow a private corridor and reach another door (this is the LXC interface).

This door gives you access to a common space of the building where the routing and dispatching occurs. We call it the Cilium Lobby (the blue rectangle). This Lobby has been installed by the Cilium Agent of this building when Cilium was selected to provide communications in this Kubernetes cluster. There is one Cilium Agent per building and he is taking care of everything related to networking.

So you reach the fountain in that Lobby (it is a virtual Switch here) with all its signs. You have in your pocket the map (ARP table) to decipher them and find a match with number 14. It is the door on the top right. You then open that door, follow the corridor and reach apartment number 14. You would go back to apartment number 12 following the same path but in the opposite direction.

As the destination is in the same community, it is still Layer 2 routing and you can see the similarities with traditional networking.

Traveling between apartments in different buildings

Now from apartment 12 you want to pay a visit to the apartment number 22 which is in another building. The beginning of your travel is the same as previously, you exit your apartment, follow the corridor, reach the Cilium Lobby and the fountain. As with traditional networking, the destination number belongs to another community so you need the help of the gatekeeper in the Lobby. The difference is that this gatekeeper doesn’t live in an apartment, he is just waiting at a deck in the Lobby. The gatekeeper looks at his map (the Routing table) for direction to number 22 and shows you the door number 11 to use (the cilium_host).

When you open that door, you see another door behind it: It is the blue triangle and it is called the VXLAN interface. This door open to a nice transparent tunnel that goes through the main door of the building. You are protected from the rain and can enjoy the landscape while walking to the other building. You even spot the outdoor fountain! When you reach the green building you exit the tunnel, greet the cilium_host number 21 of this building, reach the Lobby and go to the gatekeeper desk. You gave him your destination (apartment 22) and he shows you the path to the fountain of this building. He also gave you the map (ARP Table) so you can translate the signs at the fountain. From the fountain you head now to the door on the top left, follow the corridor and reach your destination. As before, your way back will follow the same journey in the opposite direction.

This is Layer 3 routing as the destination community is different than yours. Although the routing is a bit more complex in Kubernetes, the principle stays the same as with traditional routing: Finding the right door to reach your destination number. Note that there are other modes of routing but this one is the a common one.

Wrap up

I hope this helped you understand the difference between the traditional networking and Kubernetes networking and also that the latter is clearer now for you. If that is all you needed, then I’m glad you’ve read this blog post, I hope you’ve enjoyed it. If you now want to learn more about Kubernetes Networking, stay tuned because I’ll write an intermediate level where you’ll see what a building really looks like on a real cluster!

L’article Kubernetes Networking by Using Cilium – Beginner Level est apparu en premier sur dbi Blog.

M-Files January Release 2024

Yann Neuhaus - Tue, 2024-02-13 12:15

A bunch of new features and a seamless user experience across all the M-Files products have been introduced with the M-Files January 2024 Release. In addition, it will bring a fresh look across all M-Files products and additional Business Benefits.
In this blog, I will give a summary of the new Features and Business Benefits including pictures of the new look and feel of the different M-Files products.
Furthermore, I will also share the instruction to follow, in order to keep the former colour scheme.

Business Benefits of the M-Files January Release 2024

Outlined below you will find a list of the most important Business Benefits.

  • Consistent User Experience: Streamlined and cohesive design across products for a consistent and intuitive user experience.
  • Enhanced Accessibility: Improved color contrast and accessibility features will cater to a broader audience, ensuring a positive experience for users with diverse needs.
  • Efficient Learning Curve: Quicker adaptation to the unified design, as common elements and patterns create a more efficient learning curve.
  • Increased User Satisfaction: A cohesive and accessible design contributes to higher user satisfaction.
Summary of the main new Features of the M-Files January Release 2024

Features below will give you a list of the major improvements.

  • M-Files Desktop Client and M-Files Web Client have the same visual identity.
  • In the M-Files comments feature you have the option to mention someone by using the @ plus the name. In addition, this will trigger a notification.
  • M-Files Desktop is supporting the copy of many links at once. You can now select many objects and create links to them at once in M-Files Desktop.
  • It is now possible to set the session timeout individually. This can be easily done under the Advanced Vault Settings section.
  • To streamline the process, improved sharing options were implemented.
    Description out of the M-Files Release Notes: “Sharing options in M-Files Desktop have been clarified, and rarely used features have been removed if M-Files Web is enabled. PDF options have been moved to a “Save as PDF” section of the context menu. These are user interface changes only and have no effect on the API.“.

Joonas Linkola (Senior Partner sales Engineer at M-Files) shared a nice summary of the release note on LinkedIn.

For further details, please take a look at the official M-Files Release Note.”

How it looks now… Reverting to the previous M-Files colour scheme

Open the M-Files Admin application and navigate to the Vault you would like to modify.
Click on Configuration => Client => Desktop => Appearance.
Particularly, the parameters below have to be adapted.

  • Enabled > Yes
  • Logo Image > M-Files Logo below
  • Top Area Color > #318ccc
  • Accent Color > #318ccc
  • Top Area Breadcrumb and Icon Color > #ffffff

Please feel free to look at the below video that shows the same, step by step.

L’article M-Files January Release 2024 est apparu en premier sur dbi Blog.

Cloud Native Storage: Overview

Yann Neuhaus - Tue, 2024-02-13 09:21

When thinking of containers, Cloud Native Storage topic shines like an evidence. You have to handle this topic with care as it will carry your workload and configuration. This blog will be the first of a series talking about CNS and usage.
I will try to cover as many aspects as possible and clear up the CNCF situation when you start looking at the landscape. The purpose of this series will not be to a direct comparison of the products one to one. Especially because of the number of products and time consuming testing. Plus you may find many on the internet who did it for different purposes and different products. It will be more a higher level method to choose wisely what will the best fit your needs and workload.

Before I go further, let me just raise a little warning about what you’ll read below. To understand terminology and the ins and outs concepts, you better be familiar with Kubernetes. For example, holding a CKA (Certified Kubernetes Administrator) may help you better appreciate this series of blogs.

Classic storage, I mean at the OS level, is what we call ephemeral storage from a container view. You may have LVM, nfs shares or any storage managed at the OS level. Many SRE engineers will stay at this level for data protection to secure and avoid the risk of loosing their precious data. For example, we may imagine a database administrator having his database installed in a VM and thinking to backup the dedicated file system where the data are stored.

Now let’s get back to cloud native storage, as the name depict it, it has been built specifically for cloud environments. Stricto sensu, cloud differs from on-premise for hosting, but here, we’re describing the general term for “cloud native”. It means a software approach to develop, build, create and manage modern applications and for that, they require scalable, flexible and resilient capabilities. These applications can leverage on public, private or hybrid cloud infrastructures.

What are these cloud native applications, they are (or should be) most of the time small and independent services allowing a very fast release cycle with more confidence. This can also be part of the efficient time-to-market definition. Again, small doesn’t mean it can’t handle very big loads, scalability and flexibility are part of the cloud native’s main purpose. In fact, it is more designed for efficiency and reliability to handle production environments by reducing cost in a general manner when load is varying.

You may also find big monolithic workloads in containers and I can say that, since I work with containers, I saw a lot of productive environments running applications that are not microservices. It is sometimes not possible due to vendor products or it can be a vendor first move before moving from monolithic to microservices.

Now, let’s talk about the CNCF landscape regarding Cloud Native Storage, it is a sub-topic in the Runtime category.
You can find it by following the link.

If you are not familiar with this view, let me give you some hints

  • Some product have a grey background, it’s because their code is proprietary
  • Some product have a white background, it’s because their code is open-source
  • Projects are graduated regarding vote from the community, it indicate the maturity level of a product
  • Graduation can be the following
    • Sandbox: Innovators
    • Incubating: Early adopters
    • Graduated: Majority
    • Archived: Grey logo, Project no longer supported
  • Some are in this picture only because they support the community as members
    • Platinum
    • Gold
    • Silver
    • Academic
    • Nonprofit
    • End User supporter

I can imagine now what can be your next question is: Which product should I use for my needs.
Well, this will be the topic of my next blog series regarding Cloud Native Storage.

In the mean time, I encourage you to follow my colleague’s blog on not being afraid to install a database in Openshift here.

L’article Cloud Native Storage: Overview est apparu en premier sur dbi Blog.

Pages

Subscribe to Oracle FAQ aggregator