I have an SSIS sequence container that extracts data from individual source database tables into a Stage layer. However, I need to know when a given calculation crashes in order for the given error to be written to the configuration table, which is provided by the yellow highlighted task in which the procedure is called. The problem is that if a given container falls due to an error, it does not flow through failure precendence constraint into the given task (LogPackageFailed). I tried setting FaiPackageOnFailure together with FailParentOnFailure to TRUE in the properties, but it didn't help. The proposed solution in the following links does not work either: - http://techblog.elish.net/2010/12/ssis-foreach-loop-container-continue-on.html - https://simonworth.wordpress.com/2009/11/11/ssis-event-handler-variables-propagate/ , which was addressed in a previous similar query.

Normally I don't ask questions but I'm about at my wits end and foresee myself struggling with this for a while. To the question reviewers, I have not found any questions referring to either the Mongo versions I'm having trouble with nor my error specific to the arbiter node. **TLDR:** The arbiter is failing on an upgrade from v6 to v7 because of an invalid featureCompabilityVersion I've read that it should not care about or use. Am I missing something obvious relating to the configuration/upgrade of the arbiter node? **Long version:** I'm using Docker Compose to manage a replica set of Mongo databases consisting of 1 primary, 1 secondary, and 1 arbiter. They all use the docker.io/bitnami/mongodb image and have volumes to persist whatever data they have to write. My task is to upgrade their images from v5 to v7 using the [Mongo instructions](https://www.mongodb.com/docs/manual/release-notes/7.0-upgrade-replica-set/) . Upgrading from v5 to v6 was uneventful since v6 is backwards compatible and just required updating the image version. To upgrade to v7 I logged into the primary node's admin database and ran db.adminCommand( { setFeatureCompatibilityVersion: "6.0" } ) followed by db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1}) to confirm the change took. I updated the image versions in the compose file from v6 to v7 and restarted. The primary/secondary nodes are fine but the arbiter spews this error before shutting down, > UPGRADE PROBLEM: Found an invalid featureCompatibilityVersion document (ERROR: Location4926900: Invalid featureCompatibilityVersion document in admin.system.version: { _id: \"featureCompatibilityVersion\", version: \"5.0\" }. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility . :: caused by :: Invalid feature compatibility version value '5.0'; expected '6.0' or '6.3' or '7.0'. See https://docs.mongodb.com/master/release-notes/6.0-compatibility/#feature-compatibility.) . If the current featureCompatibilityVersion is below 6.0, see the documentation on upgrading at https://docs.mongodb.com/master/release-notes/6.0/#upgrade-procedures . Now I've read that the arbiter should contain no data and that the arbiter ignores the FCV in favor of the backwards compatibility reported by the binaries, which if true, should be v6, not v5 as the error states. I tried to authenticate to the arbiter to set the FCV there but I get command setFeatureCompatibilityVersion requires authentication. Am I missing something obvious relating to the configuration/upgrade of the arbiter node?

I am trying to create a pluggable database using a response file, but it is giving me the error below, indicating that one of the mandatory parameters is missing. Although I have checked it multiple times, I don't see that any missing mandatory parameter. Below is my response file which I am using. dbca -silent -createPluggableDatabase -responseFile /f01/app/oracle/dbca_pdb_creation.rsp [INS-04008] Invalid combination of arguments passed from the command line. One or more mandatory dependent arguments are not passed for the argument: -create pluggable database I am able to create the database when passing the required parameters directly in command line as below: dbca -silent -createPluggableDatabase -sourceDB testcdb -pdbName testpdb2 -createPDBFrom default -pdbAdminUserName PDBADMIN -pdbAdminPassword abcd1234 **Response file** ############################################################################## ## ## ## DBCA response file ## ## ------------------ ## ## Copyright(c) Oracle Corporation 1998,2019. All rights reserved. ## ## ## ## Specify values for the variables listed below to customize ## ## your installation. ## ## ## ## Each variable is associated with a comment. The comment ## ## can help to populate the variables with the appropriate ## ## values. ## ## ## ## IMPORTANT NOTE: This file contains plain text passwords and ## ## should be secured to have read permission only by oracle user ## ## or db administrator who owns this installation. ## ############################################################################## #------------------------------------------------------------------------------- # Do not change the following system-generated value. #------------------------------------------------------------------------------- #----------------------------------------------------------------------------- # GENERAL section is required for all types of database creations. #----------------------------------------------------------------------------- [GENERAL] #----------------------------------------------------------------------------- # Name : RESPONSEFILE_VERSION # Datatype : String # Description : Version of the database to create # Valid values : "12.1.0" # Default value : None # Mandatory : Yes #----------------------------------------------------------------------------- responseFileVersion=/oracle/assistants/rspfmt_dbca_response_schema_v19.0.0 #----------------------------------------------------------------------------- # Name : OPERATION_TYPE # Datatype : String # Description : Type of operation # Valid values : "createDatabase" \ "createTemplateFromDB" \ "createCloneTemplate" \ "deleteDatabase" \ "configureDatabase" \ "addInstance" (RAC-only) \ "deleteInstance" (RAC-only) \ "createPluggableDatabase" \ "unplugDatabase" \ "deletePluggableDatabase" \ "configurePluggableDatabase" # Default value : None # Mandatory : Yes #----------------------------------------------------------------------------- OPERATION_TYPE = "createPluggableDatabase" #-----------------------*** End of GENERAL section ***------------------------ #---------------------------------------------------------------------------------- # CREATEPLUGGABLEDATABASE section is used when OPERATION_TYPE is defined as "createPluggableDatabase". #---------------------------------------------------------------------------------- [CREATEPLUGGABLEDATABASE] #---------------------------------------------------------------------------------- # Name : SOURCEDB # Datatype : String # Description : The source database is the SID # This database must be local and on the same ORACLE_HOME. # Default value : none # Mandatory : YES #----------------------------------------------------------------------------- SOURCEDB = "testcdb" #---------------------------------------------------------------------------------- # Name : PDBNAME # Datatype : String # Description : The name of new pluggable database # This pdb name must not be same as sourcedb name. # Default value : none # Mandatory : YES #----------------------------------------------------------------------------- PDBNAME = "testpdb2" #---------------------------------------------------------------------------------- # Name : CREATEASCLONE # Datatype : Boolean # Description : specify true or false for PDB to be create as Clone. # : When "true" is passed a new PDB GUID is generated for the plugged in PDB # Default value : true # Mandatory : NO #----------------------------------------------------------------------------- CREATEASCLONE = "TRUE" #---------------------------------------------------------------------------------- # Name : CREATEPDBFROM # Datatype : String # Description : specify the source of pdb to be plugged # Valid values : DEFAULT | FILEARCHIVE | RMANBACKUP | USINGXML # Default value : DEFAULT # Mandatory : NO #----------------------------------------------------------------------------- CREATEPDBFROM = "DEFAULT" #---------------------------------------------------------------------------------- # Name : PDBADMINUSERNAME # Datatype : String # Description : PDB Administrator user name # Default value : None # Mandatory : Mandatory only when creating new DEFAULT PDB #----------------------------------------------------------------------------- PDBADMINUSERNAME = "PDBADMIN" #---------------------------------------------------------------------------------- # Name : PDBADMINPASSWORD # Datatype : String # Description : PDB Administrator user password # Default value : None # Mandatory : Mandatory only when creating new DEFAULT PDB #----------------------------------------------------------------------------- PDBADMINPASSWORD = "abcd1234" #-----------------------*** End of createPluggableDatabase section ***------------------------ Please help.

I have PostgreSQL 15 running in a Kubernetes Pod using the Zalando Spilo image, managed by Patroni. The container has a memory limit of 16 GB, and the database size is 40 GB (data dir on disk). When I reinitialize a replica with Patroni, it runs 'basebackup.sh', which in turn runs the 'pg_basebackup' command: /usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/data -X none --dbname='dbname=postgres user=standby host= port=5432' I noticed that the first 16 GB are copied quickly, but the process slows down significantly afterward (I observed that after copied size is approximately equal to container's memory limits). Increasing the container memory limit to 32 GB showed a similar pattern: the first 32 GB were copied quickly, then it slowed down. Running the command manually: /usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/dummy_dir -X none --dbname='dbname=postgres user=standby host= port=5432' reproduced the issue. Once the container's total memory (including page cache and including inactive files which a lion's part of container MEM) reaches the limit, 'pg_basebackup' slows down. Other disk write operations (e.g., generating and copying large files with 'dd') are not affected by the memory limit and remain fast. When 'pg_basebackup' is slow and the container memory limit is reached, I tried discarding the page cache with: "sync && echo 3 > /proc/sys/vm/drop_caches" and this made 'pg_basebackup' fast again. Is 'pg_basebackup' performance limited by the files page cache? Do you need any additional information from me? Any suggestions? Thanks for your help!

I'm running oracle19c container. This is the docker-compose file:

`
version: '3.7'
services:
  oracle:
    image: container-registry.oracle.com/database/enterprise:19.3.0.0
    container_name: oracle19c
    ports:
      - 1521:1521
    volumes:
      - oracle19c:/opt/oracle/oradata
      - /etc/localtime:/etc/localtime
    shm_size: '2gb'
networks:
  oracle19c:
    external: yes
volumes:
  oracle19c:
    external: yes

` Everything works fine before I turning on the archivelog.

`
sqlplus sys / as sysdba

SQL> shutdown immediate;
    Database closed.
    Database dismounted.
    ORACLE instance shut down.

SQL> startup mount;
    ORACLE instance started.

SQL> alter database archivelog;
    Database altered.

SQL> alter database open;
    Database altered.

` Then the Database is down and I cannot start it any more, this is the docker logs:

`
[root@ATM-6601509-10 oracle_19c]# docker logs oracle19c -f




ORACLE EDITION: ENTERPRISE

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:35:27 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 1 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:35:33 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 2 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:35:39 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 3 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:35:46 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 4 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:35:54 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 5 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:36:03 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 6 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:36:13 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 7 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:36:24 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 8 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:36:36 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 9 sec(s) before restarting Oracle processes

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:36:49 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> Disconnected
Waiting for 10 sec(s) before restarting Oracle processes







LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 28-MAY-2023 18:37:04

Copyright (c) 1991, 2019, Oracle.  All rights reserved.

Starting /opt/oracle/product/19c/dbhome_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 19.0.0.0.0 - Production
System parameter file is /opt/oracle/product/19c/dbhome_1/network/admin/listener.ora
Log messages written to /opt/oracle/diag/tnslsnr/ed39669f3ec6/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                28-MAY-2023 18:37:04
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /opt/oracle/product/19c/dbhome_1/network/admin/listener.ora
Listener Log File         /opt/oracle/diag/tnslsnr/ed39669f3ec6/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
The listener supports no services
The command completed successfully

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:04 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 1 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:09 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 2 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:15 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 3 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:22 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 4 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:31 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 5 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:40 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 6 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:37:50 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 7 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:38:01 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 8 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:38:13 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 9 sec(s) before restarting Oracle processes and opening the database

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 18:38:26 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> ORACLE instance shut down.
SQL> ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> SQL>    alter database mount
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter database open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter pluggable database all open
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL>    alter system register
*
ERROR at line 1:
ORA-01034: ORACLE not available
Process ID: 0
Session ID: 0 Serial number: 0


SQL> Disconnected
The Oracle base remains unchanged with value /opt/oracle
Waiting for 10 sec(s) before restarting Oracle processes and opening the database
The Oracle base remains unchanged with value /opt/oracle
#####################################
########### E R R O R ###############
DATABASE SETUP WAS NOT SUCCESSFUL!
Please check output for further info!
########### E R R O R ###############
#####################################
The following output is now a tail of the alert.log:
tail: cannot open '/opt/oracle/diag/rdbms/*/*/trace/alert*.log' for reading: No such file or directory
tail: no files remaining

` This seems that oracle19c is looking for the init file initORCLCDB.ora. Actually, inside the docker, there is no initORCLCDB.ora file.

`
[root@ATM-6601509-10 oracle_19c]# docker exec -it oracle19c bash
bash-4.2$ cd /opt/oracle/product/19c/dbhome_1/dbs/
bash-4.2$ ls -la
total 4
drwxr-xr-x 2 oracle dba        67 May 28 17:23 .
drwxr-xr-x 1 oracle dba        60 May 28 18:37 ..
-rw-r--r-- 1 oracle dba      3079 May 14  2015 init.ora
lrwxrwxrwx 1 oracle oinstall   49 May 28 17:23 orapwORCLCDB -> /opt/oracle/oradata/dbconfig/ORCLCDB/orapwORCLCDB
lrwxrwxrwx 1 oracle oinstall   54 May 28 17:23 spfileORCLCDB.ora -> /opt/oracle/oradata/dbconfig/ORCLCDB/spfileORCLCDB.ora

` I'm not sure why it's looking for that initORCLCDB.ora file. Because, by default there is no that initORCLCDB.ora file inside the docker (I created the new docker in other server and check it, no that file at all). I tried to startup database with severals options, but it's still failed:

`
[root@ATM-6601509-10 oracle_19c]# docker-compose up -d
WARNING: Some networks were defined but are not used by any service: oracle19c
Starting oracle19c ... done
[root@ATM-6601509-10 oracle_19c]# docker exec -it oracle19c bash
bash-4.2$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Sun May 28 20:16:13 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> shutdown;
ERROR:
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Additional information: 4376
Additional information: 1135834575
Process ID: 0
Session ID: 0 Serial number: 0


SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'
SQL> startup spfile=/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora;
SP2-0714: invalid combination of STARTUP options

` When I create pfile from existing sfile, it's still failed:

`

SQL> create pfile='/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora' from spfile='/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora';
create pfile='/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora' from spfile='/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora'
*
ERROR at line 1:
ORA-01565: error in identifying file
'/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora'
ORA-27046: file size is not a multiple of logical block size
Additional information: 1

` This is the content of spfileORCLCDB.ora:

`
C"▒▒f▒▒CCC"["ORCLCDB.__data_transfer_cache_size=0
ORCLCDB.__db_cache_size=889192448
ORCLCDB.__inmemory_ext_roarea=0
ORCLCDB.__inmemory_ext_rwarea=0
ORCLCDB.__java_pool_size=0
ORCLCDB.__large_pool_size=67108864
ORCLCDB.__oracle_base='/opt/oracle'#ORACLE_BASE set from environment
ORCLCDB.__pga_aggregate_target=536870912
ORCLCDB.__sga_target=1610612736
ORCLCDB.__shared_io_pool_size=83886080
ORCLCDB.__shared_pool_size=520093696
ORCLCDB.__streams_pool_size=33554432
ORCLCDB.__unified_pga_pool_size=0
*.CC"v9audit_file_dest='/opt/oracle/admin/ORCLCDB/adump'
*.audit_sys_operations=false
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='/opt/oracle/oradata/ORCLCDB/control01.ctl'
*.db_block_size=8192
*.db_flashback_retention_target=1440
*.db_name='ORCLCDB'
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLCDBXDB)'
*.enable_pluggable_database=true
*.CC":)local_listener=''
*.log_archive_format='%s_%t_%r.ARC'
*.log_archive_start=TRUE
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=512m
*.processes=640
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1536m
*.undo_tablespace='UNDOTBS1'
CC"FeCC"EeCC"DeC

` Please help me how to fix this, it already has data in mounted volume, I need to keep the data. Thank you all.

I would like to install SQL Server 2019 on Linux either a full Linux server (Ubuntu 18.04) or on a Docker container with Polybase. Installing MSSQL 2019 on a Linux Server or a container is relatively easy. It's the Polybase bit that I cannot figure out. Using the instructions at this Microsoft Docs site: https://learn.microsoft.com/en-us/sql/relational-databases/polybase/polybase-linux-setup?view=sql-server-ver15 There is a reference to install Polybase on Ubuntu, which should be applicable in both cases (server or container). When I attempted to install the Polybase packages on an Ubuntu server I got this result: sudo apt-get install mssql-server-polybase Installed without any issue sudo apt-get install mssql-server-polybase-hadoop `The following packages have unmet dependencies: mssql-server-polybase-hadoop : Depends: mssql-zulu-jre-11 but it is not installable E: Unable to correct problems, you have held broken packages.` I could not find a solution to installing the package mssql-zulu-jre-11 on a Linux Server. In a container, I logged in as a Root user and attempted the commands above: apt-get install mssql-server-polybase E: Unable to locate package mssql-server-polybase I did verify that within the container the Linux instance has the correct sources for apt to find this package. I am completely confused as to how to get Polybase running with SQL Server 2019 on Linux. Have any of your had success? Any help would be greatly appreciated!

using pg_upgrade when you have installed both the 'old' version and the 'new' version on a system is quite straightforward. I tried to find a way using pg_upgrade with docker containers. This is a little bit more complicated because you need the 'old datadir', the 'old bindir' and the 'new datadir'and the 'new bindir' of the 'old' and the 'new' postgres version you want to upgrade from and upgrade to. Because the 'old directories' are not present in the 'new' version docker container you have to mount them into the 'new' container. But since pg_upgrade seems to expect not only the 'old' bindir and datadir but also the 'old' libraries (postgres depends on) of the older version, you also have to mount them into the new versions' container. So I ended up running an 'old-version-container', copying the bindir, datadir and lib dir to the local docker host and mounting them in the 'new-version-container' when coming from postgres-12 this means copying the contents of /usr/lib/ to the local docker host and remounting them to the 'new-version-container' so I mounted the 'old-libdir' to /12-bindir/ and did ldd /12-bindir/postgres to find out which libs postgres depends on. After copying the 'old-libs' to /usr/lib in the 'new-version-container' all dependencies could be found and I was able to use pg_upgrade and actually upgrade a database from (i.e. postgres-12-alpine to postgres:15.10-bookworm) so.. it worked.. So.. the real question is: because it works.. should I do it like this or do I miss something and am I doing something stupid or silly? I am glad about every hint and opinion

These are my listener.ora and tnsnames.ora files

listener.ora



SID_LIST_LISTENER =
  (SID_LIST =
      (SID_DESC =
      (GLOBAL_DBNAME = dr_DGMGRL)
      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)
      (SID_NAME = dr)
      (UR=A)
    )
  )
LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
  )

ADR_BASE_LISTENER = /u01/app/oracle


tnsname.ora


DR =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = dr) (UR=A)
    )
  )


PDB1 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = pdb1)
    )
  )


PDB2 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = pdb2)
    )
  )

PDB3 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.XX.XX)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = pdb3)
    )
  )

when I start the listener, only getting this output:

lsnrctl status

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 23-JAN-2024 20:38:21

Copyright (c) 1991, 2019, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.XX.XX)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                23-JAN-2024 20:28:41
Uptime                    0 days 0 hr. 9 min. 39 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/19.0.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/hostname/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.XX.XX)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.XX.XX)(PORT=1521)))
Services Summary...
Service "dr_DGMGRL" has 1 instance(s).
  Instance "dr", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

I have oracle19c container, running by docker-compose:

`
version: '3.7'
services:
  oracle:
    image: container-registry.oracle.com/database/enterprise:19.3.0.0
    container_name: oracle19c
    ports:
      - 1521:1521
    volumes:
      - oracle19c:/opt/oracle/oradata
      - /etc/localtime:/etc/localtime
    shm_size: '2gb'
networks:
  oracle19c:
    external: yes
volumes:
  oracle19c:
    external: yes

` After some tuning, like turning on archive log, now I cannot start oracle.

`
SQL> startup;
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora'

` Then I tried to create pfile from sfile, it shows error:

`
SQL> create pfile='/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora' from spfile='/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora';
create pfile='/opt/oracle/product/19c/dbhome_1/dbs/initORCLCDB.ora' from spfile='/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora'
*
ERROR at line 1:
ORA-01565: error in identifying file
'/opt/oracle/product/19c/dbhome_1/dbs/spfileORCLCDB.ora'
ORA-27046: file size is not a multiple of logical block size
Additional information: 1

` This is the detail of spfile:

`
bash-4.2$ cd /opt/oracle/product/19c/dbhome_1/dbs/
bash-4.2$ ls
init.ora orapwORCLCDB  spfileORCLCDB.ora
bash-4.2$ cat spfileORCLCDB.ora
C"▒▒f▒▒CCC"["ORCLCDB.__data_transfer_cache_size=0
ORCLCDB.__db_cache_size=889192448
ORCLCDB.__inmemory_ext_roarea=0
ORCLCDB.__inmemory_ext_rwarea=0
ORCLCDB.__java_pool_size=0
ORCLCDB.__large_pool_size=67108864
ORCLCDB.__oracle_base='/opt/oracle'#ORACLE_BASE set from environment
ORCLCDB.__pga_aggregate_target=536870912
ORCLCDB.__sga_target=1610612736
ORCLCDB.__shared_io_pool_size=83886080
ORCLCDB.__shared_pool_size=520093696
ORCLCDB.__streams_pool_size=33554432
ORCLCDB.__unified_pga_pool_size=0
*.CC"v9audit_file_dest='/opt/oracle/admin/ORCLCDB/adump'
*.audit_sys_operations=false
*.audit_trail='none'
*.compatible='19.0.0'
*.control_files='/opt/oracle/oradata/ORCLCDB/control01.ctl'
*.db_block_size=8192
*.db_flashback_retention_target=1440
*.db_name='ORCLCDB'
*.diagnostic_dest='/opt/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=ORCLCDBXDB)'
*.enable_pluggable_database=true
*.CC":)local_listener=''
*.log_archive_format='%s_%t_%r.ARC'
*.log_archive_start=TRUE
*.nls_language='AMERICAN'
*.nls_territory='AMERICA'
*.open_cursors=300
*.pga_aggregate_target=512m
*.processes=640
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=1536m
*.undo_tablespace='UNDOTBS1'
CC"FeCC"EeCC"DeC

` Please help me how to fix this. I need to keep the data which is already mounted to volume. Thank you all.

I want to run SQL on my MAC M1, I used guidelines according to this website: https://phoenixnap.com/kb/install-sql-server-macos and I used this instruction: docker pull mcr.microsoft.com/mssql/server:2019-latest then: docker run -d --name example_sql_server -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=Strong.Pwd-123' -p 1433:1433 mcr.microsoft.com/mssql/server:2019-latest Now my Docker is showing a Container, but it is not active always. When I click on the run button it becomes active for about 5 seconds and then turn off. Finally, I couldn't have SQL in Azure or another platform because my Container isn't active. Please help me.....

I am fairly new to db administrations as well as containerization/kubernetes concepts. I see every here and then containerized/clustering solutions for i.e. running PostgreSQL (i.e. [here](https://www.enterprisedb.com/docs/kubernetes/cloud_native_postgresql/interactive_demo) . This conflicts with info I get during my training where it is said that _"**databases can not run into ephemeral enironments like containers to avoid data corruption**"_ on container-failure. The same logic should generally apply to Kubernetes clusters alike. Can anybody clarify how these two points of views play together?

I'm trying to restore a database backup that is on a server. This server is on a remote machine and runs in a docker container. The container OS is Ubuntu 20.04. I can access the database, make queries on the master, etc. But when restoring the database, the .bak file is not visible to Sql Server Management Studio. How do I solve this problem?

I have setup a MariaDB ColumnStore Database as described in the MariaDB ColumnStore Quick Start guide. The guide is missing some steps so these are the exact steps I took:

docker run -d -p 3306:3306 --name mcs_container mariadb/columnstore

docker exec -it mcs_container bash

yum install git wget

git clone https://github.com/mariadb-developers/mariadb-columnstore-quickstart.git 

./get_flight_data.sh

mariadb

		CREATE USER 'user1'@'%' IDENTIFIED BY '';

		GRANT ALL ON travel.* TO 'user1'@'%';

Exit mariadb client

./create_and_load.sh 127.0.0.1 3306 user1

I can query the DB from within the container. Now, I want to connect to the DB from my local Windows 11 machine through TCP. But every time I try to connect to it using a local MySQL client I get the following error:

C:\Program Files\MariaDB 10.9\bin>mariadb --host 172.17.0.2  --port 3306 --user app_user -p
Enter password: ********
ERROR 2002 (HY000): Can't connect to server on '172.17.0.2' (10060)

*Edit*: I am using Docker Containers IP Address

.17.0.2

in the above request since I am trying to connect to the server/DB that is inside the container. I found the IP address through the following command:

docker inspect -f "{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}" mcs_container

For further clarity, the diagram below illustrates the setup and problem, the connection (middle arrow) is what is failing at the moment. *Edit End* I did some trial and error through the research I found online but I have reached an impasse. I don't know what I am missing. Here are a few things I have tried: 1. Followed this video as well as section 2.3 of this article detailing how to connect to a containerized MariaDB/MySQL server. No luck. 2. I also looked into bind addresses as mentioned here . But as mentioned in this more recently answered question , bind addresses may not be the problem. And I don't exactly understand what I am messing with here. So I left it alone for now. 3. Last possibility I could think of is that it could be a firewall issue, as mentioned here . I use Kaspersky Internet Security - I tried disabling the firewall but again that made no difference. I am new to docker, sorry if I have overlooked something small and obvious. Any help will be really appreciated. Thank you.

I would like to install Mysql in my Ubuntu container. The reason is my app inside the container needs mysql command to run mysql -u root -p -h "mysql server IP address". But I received this error: update-alternatives: using /var/lib/mecab/dic/ipadic-utf8 to provide /var/lib/mecab/dic/debian (mecab-dictionary) in auto mode Setting up libhtml-parser-perl:amd64 (3.76-1build2) ... Setting up libhttp-message-perl (6.36-1) ... Setting up mysql-server-8.0 (8.0.30-0ubuntu0.22.04.1) ... invoke-rc.d: policy-rc.d denied execution of stop. update-alternatives: using /etc/mysql/mysql.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Renaming removed key_buffer and myisam-recover options (if present) ERROR: Unable to start MySQL server: mysqld: Can't read dir of '/etc/mysql/conf.d/' (OS errno 13 - Permission denied) mysqld: [ERROR] Stopped processing the 'includedir' directive in file /etc/mysql/my.cnf at line 20. mysqld: [ERROR] Fatal error in defaults handling. Program aborted! Please take a look at https://wiki.debian.org/Teams/MySQL/FAQ for tips on fixing common upgrade issues. Once the problem is resolved, run apt-get --fix-broken install to retry. dpkg: error processing package mysql-server-8.0 (--configure): installed mysql-server-8.0 package post-installation script subprocess returned error exit status 1 Setting up libcgi-pm-perl (4.54-1) ... Setting up libhtml-template-perl (2.97-1.1) ... dpkg: dependency problems prevent configuration of mysql-server: mysql-server depends on mysql-server-8.0; however: Package mysql-server-8.0 is not configured yet. dpkg: error processing package mysql-server (--configure): dependency problems - leaving unconfigured Setting up libcgi-fast-perl (1:2.15-1) ... Processing triggers for libc-bin (2.35-0ubuntu3.1) ... Errors were encountered while processing: mysql-server-8.0 mysql-server E: Sub-process /usr/bin/dpkg returned an error code (1) I tried to run chmod 777 -R /etc/mysql but it still doesn't work. How do I install mysql-server in the Ubuntu container? I am very new to MySQL, any help is appreciated!

I am looking at the prospect of upgrading from oracle 11G to 12C, and I am looking at the cdb vs non-cdb models, and I am having a hard time seeing the benefit of using CDB, without multitenant licensing. For the most part when I look for information regarding the two, I come up with a lot of forums and blogs saying its the way of the future, non-CDB might be desupported in some future version, its the next big thing for oracle, as reasons to make the switch. Those all sound like marketing driven reasons to move from non-CDB to CDB, but I am not seeing much information about real benefits of going to a new architecture. Most of the real benefits seem to come when multitenant cdb is an option, but for the time being I have to assume its not in my case. We have looked at the cost, and I don't see the option being purchased. My question then is from a DBA perspective: are there any real benefits from moving to a single tenant CDB vs staying with what seems to be a tried and true design of the non-cdb environment? Edit: man, two weeks and nothing. Does anyone have anything regarding this?

MariaDB Version: '10.5.13-9 --------------------------- I am facing multiple unsuccessful data migration(Copy) attempts from my old legacy data environment to my DBaaS Container Environment. Performing this data migration using mysqldump with pipe to restore in my Container which is running in rootless podman with pid 1. MariaDB states, this issue is sorted with version 10.5.13-9. They cannot reproduce this bug. Not able to find the reason behind why InnoDB keep logging [Note] InnoDB: Cannot close file because of 1 pending operations. Enabled the coredump to analyze the bug, my error logs writes: Writing a core file... Working directory at /var/lib/mysql but I cant find the core file. Not able to find the reason behind it. I even tried creating the container with podman using below parameters. But no luck. --ulimit core=-1 --privileged \ --security-opt seccomp=unconfined \ MariaDB [(none)]> show global status like "%pending%"; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | Innodb_data_pending_fsyncs | 0 | | Innodb_data_pending_reads | 0 | | Innodb_data_pending_writes | 0 | | Innodb_os_log_pending_fsyncs | 0 | | Innodb_os_log_pending_writes | 0 | +------------------------------+-------+ 5 rows in set (0.001 sec) MariaDB [(none)]> Error Log: ========== 2022-01-25 11:19:05 0 [Note] mysqld: ready for connections. Version: '10.5.13-9-MariaDB-enterprise-log' socket: '/var/run/mysqld/mysqld.sock' port: 53805 MariaDB Enterprise Server 2022-01-25 11:27:26 14 [Note] Start binlog_dump to slave_server(52396), pos(mysqld-bin.000001, 369), using_gtid(0), gtid('') 2022-01-25 11:38:06 15 [Note] InnoDB: Cannot close file ./pptdatabase/fallback_stf_stat_availability_sweeper_valuecritanytype#P#p736783.ibd because of 1 pending operations . . . . . 2022-01-25 14:11:30 15 [Note] InnoDB: Cannot close file ./pptdatabase/stf_stat_availability_externalcall_avl_hist#P#p738548.ibd because of 1 pending operations 220125 14:11:32 [ERROR] mysqld got signal 11 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is wrong and this may fail. Server version: 10.5.13-9-MariaDB-enterprise-log key_buffer_size=134217728 read_buffer_size=2097152 max_used_connections=13 max_threads=1502 thread_count=13 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 9397787 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x0 thread_stack 0x49000 addr2line: 'mysqld': No such file mysqld(my_print_stacktrace+0x2e)[0x563b87eb047e] Printing to addr2line failed mysqld(handle_fatal_signal+0x485)[0x563b8792b425] sigaction.c:0(__restore_rt)[0x7f943ec57b20] addr2line: 'mysqld': No such file mysqld(+0xdfc944)[0x563b87dc9944] mysqld(+0xdfd881)[0x563b87dca881] mysqld(+0x652bdd)[0x563b8761fbdd] mysqld(+0xe1086a)[0x563b87ddd86a] pthread_create.c:0(start_thread)[0x7f943ec4d14a] :0(__GI___clone)[0x7f943e061dc3] The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains information that should help you find out what is causing the crash. Writing a core file... Working directory at /var/lib/mysql Resource Limits: Another Attempt after increasing buffer pool, log file size & log buffer also re producing same. Inndob keep logging this note messages. default_storage_engine = InnoDB innodb_buffer_pool_size = 15G innodb_log_file_size = 10G innodb_log_buffer_size = 10G innodb_file_per_table = 1 innodb_open_files = 800 innodb_io_capacity = 15000 innodb_read_io_threads = 10 innodb_write_io_threads = 20 innodb_flush_method = O_DIRECT # can be fsync O_DSYNC O_DIRECT innodb_flush_log_at_trx_commit = 1 Error Log: ---------- Version: '10.5.13-9-MariaDB-enterprise-log' socket: '/var/run/mysqld/mysqld.sock' port: 53805 MariaDB Enterprise Server 2022-01-26 0:06:27 14 [Note] Start binlog_dump to slave_server(52396), pos(mysqld-bin.000001, 369), using_gtid(0), gtid('') 2022-01-26 0:17:58 16 [Note] InnoDB: Cannot close file . . ./pptdatabase/stf_stat_availability_officeoffice_bench_aws_mhist.ibd because of 1 pending operations

I wondered how to optimize the RAM usage of my PostgreSQL database deployed in Kubernetes. Particularly I'm interested in configuring the shared_buffers and effective_cache_size values. Typically the recommendation stated by various sources is to use: - If you have a system with 1GB or more of RAM, a reasonable starting value for shared_buffers is 1/4 of the memory in your system. If you have less RAM you'll have to account more carefully for how much RAM the OS is taking up; closer to 15% is more typical there. There are some workloads where even larger settings for shared_buffers are effective, but given the way PostgreSQL also relies on the operating system cache, it's unlikely you'll find using more than 40% of RAM to work better than a smaller amount. (PostgreSQL Website ) - The value should be set to 15% to 25% of the machine’s total RAM (EDB website ) - No more than 50% of the available RAM (EDB PostgreSQL tuning ) Since containers use by design much less background RAM what would be a good recommendation for setting the shared_buffers value? Right now the value is set to 25% (1GB of 4GB total container limit) and I notive that it get's filled up quite quickly.

The Microsoft documentation states the following about the supportability of SQL Server Containers running on container orchestrators: > Microsoft supports deploying and managing SQL Server containers by > using OpenShift and Kubernetes. > > Starting from SQL Server 2019, you can deploy the SQL Server Big Data > Cluster on Kubernetes. Review the supported Kubernetes platforms in > the SQL Server 2019 Big Data Clusters release notes under the > Supportability section. Does it mean that all kinds of supported SQL Server containers are supported on OpenShift and Kubernetes or is this statement talking only about SQL Server 2019 Big Data Clusters ones as supported?

Using this docker-compose.yml I have created a container:

version: "3.9"
services:
    database:
        image: mcr.microsoft.com/mssql/server
        user: root
        restart: always
        container_name: ContainerNameHere
        volumes:
            - /Organization/Databases:/var/opt/mssql/data
        environment:
            - ACCEPT_EULA=Y
            - SA_PASSWORD=password_here
            - MSSQL_PID=Express
        ports:
            - 1433:1433
        logging:
            driver: none
        networks:
            - NetworkNameHere
networks:
    NetworkNameHere:
        name: NetworkNameHere
        driver: bridge

And it has **ZERO** user databases in it. It's just a simple empty SQL Server docker container with no database and no data in it. But here's my top command's results: As you can see, it's totally destroying my VPS. This is so frustrating and the Microsoft team has not [answered me](https://github.com/microsoft/mssql-docker/issues/644#issuecomment-943567909) yet. Why SQL Server's docker container acts this way and what should I do to fix this? --- I have 10 GB of free space: df -h / > Filesystem Size Used Avail Use% Mounted on /dev/sda1 20G 8.9G 10G 47% / My SQL Server build version is 15.0.4153.1, which means it's SQL Server 2019 CU13. My host OS (that runs the docker demon) is Debian GNU/Linux 10 (buster).

We are trying to setup MySQL multi-master group replication (GR) on kubernetes Group replication configuring instances . GR is starting on one pod after all the configurations. However the second node goes to RECOVERING state when GR is started followed by ERROR state. There is no error in GCS_DEBUG_TRACE logs also. Let me know if there is anything missing and if more info is required to analyze. Thanks in advance. Workarounds tried: 1. https://dba.stackexchange.com/questions/268801/mysql-group-replication-multi-primary-setup 2. https://stackoverflow.com/questions/50794695/mysql-group-replication-stuck-on-recovering-forever Cluster Setup: 1. Created 3 PVCs for each pods in a namespace 2. Launched pods using mysql:8.0.23 docker image (https://hub.docker.com/_/mysql ) 3. Ran below queries to configure the pods

$ kubectl get all -n myb5
NAME         READY   STATUS    RESTARTS   AGE
pod/mysql1   1/1     Running   0          15h
pod/mysql2   1/1     Running   0          15h
pod/mysql3   1/1     Running   0          15h

NAME                TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/gr-domain   ClusterIP   None                     15h

$ kubectl get pvc -n myb5
NAME               STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-pv-claim-1   Bound    pvc-f7957eff-b75e-4dbc-990a-8d79e54b6f06   250Gi      RWO            robin          15h
mysql-pv-claim-2   Bound    pvc-1c5d4dfd-8495-4266-af0d-882ce8e8ccec   250Gi      RWO            robin          15h
mysql-pv-claim-3   Bound    pvc-49c0979b-49cb-413b-b695-479b32124343   250Gi      RWO            robin          15h

Configuration on all pods: SET PERSIST general_log = ON; SET PERSIST general_log_file= '/var/lib/mysql/mysql1.log'; SET PERSIST group_replication_communication_debug_options='GCS_DEBUG_ALL'; SET PERSIST enforce_gtid_consistency=ON; SET PERSIST gtid_mode = OFF_PERMISSIVE; SET PERSIST gtid_mode = ON_PERMISSIVE; SET PERSIST gtid_mode = ON; SET PERSIST binlog_format = ROW; SET PERSIST master_info_repository='TABLE'; SET PERSIST relay_log_info_repository='TABLE'; SET PERSIST transaction_write_set_extraction=XXHASH64; SET SQL_LOG_BIN = 0; CREATE USER rpl_user@'%' IDENTIFIED BY 'password'; GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%'; GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%'; FLUSH PRIVILEGES; CHANGE REPLICATION SOURCE TO SOURCE_USER='rpl_user', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery'; SET SQL_LOG_BIN = 1; INSTALL PLUGIN group_replication SONAME 'group_replication.so'; SET PERSIST group_replication_group_name='85cbd4a0-7338-46f1-b15e-28c1a26f465e'; SET PERSIST group_replication_start_on_boot=OFF; SET PERSIST group_replication_bootstrap_group=OFF; SET PERSIST group_replication_single_primary_mode=OFF; SET PERSIST group_replication_enforce_update_everywhere_checks=ON; SET PERSIST group_replication_member_expel_timeout=3600; SET PERSIST group_replication_group_seeds='mysql1.gr-domain.myb5.svc.cluster.local:33061,mysql2.gr-domain.myb5.svc.cluster.local:33061,mysql3.gr-domain.myb5.svc.cluster.local:33061'; SET PERSIST group_replication_ip_allowlist='mysql1.gr-domain.myb5.svc.cluster.local,mysql2.gr-domain.myb5.svc.cluster.local,mysql3.gr-domain.myb5.svc.cluster.local'; Conf on pod1: SET PERSIST server_id=1; SET PERSIST group_replication_local_address= 'mysql1.gr-domain.myb5.svc.cluster.local:33061'; SET PERSIST group_replication_bootstrap_group=ON; START GROUP_REPLICATION USER='rpl_user', PASSWORD='password'; SET PERSIST group_replication_bootstrap_group=OFF; SET PERSIST group_replication_recovery_get_public_key=ON; Conf on pod2: SET PERSIST server_id=2; SET PERSIST group_replication_local_address= 'mysql2.gr-domain.myb5.svc.cluster.local:33061'; START GROUP_REPLICATION USER='rpl_user', PASSWORD='password'; Conf on pod3: SET PERSIST server_id=3; SET PERSIST group_replication_local_address= 'mysql3.gr-domain.myb5.svc.cluster.local:33061'; START GROUP_REPLICATION USER='rpl_user', PASSWORD='password'; Group Replication Status when started: mysql> SELECT * FROM performance_schema.replication_group_members\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: 57b9f42a-8b4d-11eb-bd3e-0242ac110003 MEMBER_HOST: mysql1 MEMBER_PORT: 3306 MEMBER_STATE: ONLINE MEMBER_ROLE: PRIMARY MEMBER_VERSION: 8.0.23 *************************** 2. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: 57ec4b94-8b4d-11eb-8fdc-0242ac110004 MEMBER_HOST: mysql2 MEMBER_PORT: 3306 MEMBER_STATE: RECOVERING MEMBER_ROLE: PRIMARY MEMBER_VERSION: 8.0.23 *************************** 3. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: 57ec4b94-8b4d-11eb-8fdc-0242ac110005 MEMBER_HOST: mysql3 MEMBER_PORT: 3306 MEMBER_STATE: RECOVERING MEMBER_ROLE: PRIMARY MEMBER_VERSION: 8.0.23 Group Replication Error after few minutes: mysql> SELECT * FROM performance_schema.replication_group_members\G *************************** 1. row *************************** CHANNEL_NAME: group_replication_applier MEMBER_ID: 57ec4b94-8b4d-11eb-8fdc-0242ac110004 MEMBER_HOST: mysql2 MEMBER_PORT: 3306 MEMBER_STATE: ERROR MEMBER_ROLE: MEMBER_VERSION: 8.0.23