The easiest way to create a sample database is to login to the container: ~]$ docker exec -ti mydb2 bash -c "su - db2inst1" Once inside the container: [db2inst1@e88eefa89d92 ~]$ db2sampl Creating database "SAMPLE"... Connecting to database "SAMPLE"... Creating tables and data in schema "DB2INST1"... Creating tables with XML columns and XML data in schema "DB2INST1"... 'db2sampl' processing complete. [db2inst1@e88eefa89d92 ~]$ db2 list db directory System Database Directory Number of entries in the directory = 1 Database 1 entry: Database alias = SAMPLE Database name = SAMPLE Local database directory = /database/data Database release level = 15.00 Comment = Directory entry type = Indirect Catalog database partition number = 0 Alternate server hostname = Alternate server port number = If you don't want to use the sample database provided via db2sampl, you can create a database as part of the start of the container via -e DBNAME=MYSAMPLE: docker run -itd --name mydb2 --privileged=true -p 50000:50000 -e LICENSE=accept -e DB2INST1_PASSWORD=whatever ibmcom/db2 -e DBNAME=MYSAMPLE Now you can try to connect to that database from data studio, setup your tables and inserting data.

You cannot turn off logging permanently. What you can do to reduce logging: use the LOAD utility with the NONRECOVERABLE option to populate staging tables; use temporary tables, which are not logged, for staging.

You could enable what's called https://www.ibm.com/docs/en/db2/11.5?topic=databases-space-requirements-log-files by setting logsecond to -1, but the term is a bit misleading, and it will likely make your system less robust, not more. Since all hardware resources are finite, you're simply shifting your pain point to a different place -- you now risk filling your archive log location and then active log location, which will eventually cause an abend of the entire database instance, instead of simply terminating the runaway transaction. If this happens you may have hard time restarting the instance -- you cannot do that until you free up some space, but the space is occupied by the active log files that are needed for crash recovery, so you can't delete them, and if your primary and archive logs are on their own separate file systems, which is often the case, there's nothing else to delete from those file systems to free the space. Another downside of "infinite logging" is in potentially much slower crash recovery. With "infinite logging" the database manager begins archiving active log files once it runs out of the primary log space, which means that during recovery these log files must be retrieved from the archive location (which is typically slower than the active log location). In other words, the only good way to solve the problem is to find and fix the application that requires too much log space.

This is https://www.ibm.com/docs/en/db2/11.5?topic=statements-create-mask : The application of enabled column masks does not interfere with the operations of other clauses within the statement such as the WHERE, GROUP BY, HAVING, SELECT DISTINCT, and ORDER BY. The rows returned in the final result table remain the same, except that the values in the resulting rows might be masked by the column masks. If you want to prevent access to specific rows, you'll need to activate row access control and define the required row permissions.

The condition "the employee shouldn't have 'disEnrolled' status on or before the given input date" needs to be done using a NOT EXISTS condition. You can't really express that with a "simple" condition in the WHERE clause: I think the following does what you want: select e1.* from employee e1 where e1.employee_id in (32456, 32458) and e1.status = 'enrolled' and e1.date e1.id and e2.employee_id = e1.employee_id and e2.status = 'disEnrolled' and e2.date The first part of the WHERE condition selects those rows that fulfill the condition "employees who are enrolled on the given date or less then given date in the input" The NOT EXISTS condition then applies the constraint "the employee shouldn't have 'disEnrolled' status on or before the given input date" https://dbfiddle.uk/?rdbms=db2_11.1&fiddle=93bf7f8b9899bf6fa3411ab9849e2cfe

Use the https://www.ibm.com/docs/en/db2/11.5?topic=tools-db2greg : db2greg -dump

There is a relate link for the older Db2 9.7 version: https://www.ibm.com/docs/en/db2/9.7?topic=installation-creating-links-db2-files . This task is not required for normal DB2 database operation. Consider creating links for the DB2 database system files only if both of the following conditions are met: You have only one copy of DB2 database on the current computer. You are developing or running applications and want to avoid having to specify the full path to the product libraries and include files.

No, downgrading databases is not supported. Save the pre-upgrade backup and installation media if you want to go back. Obviously, you will lose all data modified since the upgrade.

I have solved the problem. It was firewall problem. My assumption on step 10 was wrong. I only checked the iptables rules: sudo iptables -nvL which having ALLOWED for all of the policies, so I assumed firewall is disabled (or has no effect). But there was another firewall firewalld service enabled and running: sudo systemctl status firewalld I have stopped and disabled it: sudo systemctl stop firewalld sudo systemctl disable firewalld sudo systemctl mask firewalld Or instead of above three commands I could add firewall exception to allow 50000 port of my Db2 service: firewall-cmd --add-port=50000/tcp Note: My steps 11 and 12 were wrong assumption. I have analyzed network packets in more detail. I see only TCP SYN packet was received from Db2 Windows client and there was no TCP SYN/ACK response from Db2 server machine back to client. There was no TCP connection established (because it was blocked by firewall), obviously there could not be any DRDA protocol established, because of dependency on TCP connection.

Postgres offers an extension to the UPDATE syntax that allows to specify a FROM clause. This is typically faster than a co-related subquery as derived table in the FROM clause is evaluated once, rather than over and over again. So the UPDATE statement is very likely to be faster if you use: update tablethree c set mynum = t.mysum from ( select a.custno, sum(b.numfield) as mysum from tableone a join tabletwo b on a.oneid = b.twoid group by a.custno ) t where c.custno = t.custno and ... other conditions ...

I've noticed the same thing and I guess that the licence for the community edition is applied always, just in case. In the deploy job, I just remove that one before adding the one that I'm entitled to: db2licm -r db2dec db2licm -a I don't think it matters (but I don't know for sure) that the community edition is there. AFAIK, there are no complaints from the compliance report: db2licm -g if you have both. It is however more convenient - for me - if there is one licence on each server (I collect that and other info from all servers on a regular basis and create a report out of it). A hard stop usually means that things will stop working if you violate the licence. If you for example use any functionality from the "IBM DB2 Performance Management Offering" you probably will notice. A soft stop usually means you will get noticed of the violation, but things will continue to work.

Disk speed is just one of the variables in the equation. You'll need to factor in the file system overhead, the degree of parallelism the backup utility can handle and its own processing cost, the extra work by the database encryption or compression, if used, and the concurrent activities on the database server. So, no, it will not be backed up in one hour. How long it will take in reality, only tests can tell. I know you didn't ask for this, but consider delta and/or tablespace-level backups.

Depends a little bit on the platform you intend to use. Oracle on AIX is a pain, since this is the most neglected (by Oracle) platform the database is running on. On Linux I would tend to use Oracle, especially if you do not have to care about licensing costs.

Like mustaccio says you probably should have a look at event monitors. That said, an alternative is to take a snapshot into a temp table, wait a while and then compare a new snapshot with the temp table. Below is an example for a sh script that you can adapt to your needs: #!/bin/sh OPTS=getopt d:t: "$@" eval set -- "$OPTS" tm=10 while true ; do case "$1" in -d) db="$2"; shift 2;; -t) tm="$2"; shift 2;; --) shift; break;; esac done db2 connect to $db if [ $? -ne 0 ]; then echo "Unable to connect to $db" exit 1 fi db2 +c "create view stmt_metrics (executable_id, num_executions, rows_read, rows_modified, stmt_text) as select executable_id, num_executions, rows_read, rows_modified, stmt_text from TABLE (MON_GET_PKG_CACHE_STMT('d', null, null, -1))" db2 +c "create global temporary table stmt_samples as ( select * from stmt_metrics) definition only on commit delete rows" db2 +c "create view stmts_delta (executable_id, num_executions, rows_read, rows_modified, stmt_text) as select t2.executable_id , t2.num_executions - t1.num_executions as num_executions , t2.rows_read - t1.rows_read as rows_read , t2.rows_modified - t1.rows_modified as rows_modified , t2.stmt_text from stmt_metrics as t2 , stmt_samples as t1 where t2.executable_id = t1.executable_id" db2 +c "insert into stmt_samples select * from stmt_metrics" sleep $tm db2 -x +c "select * from stmts_delta order by rows_modified desc fetch first 10 rows only" db2 rollback Here is an example of an activity event monitor: db2 connect to db2 "alter service class sysdefaultsubclass under sysdefaultuserclass collect activity data on all database partitions with details and values" db2 "create event monitor act_stmt for activities write to table manualstart" db2 "set event monitor act_stmt state = 1" You will get a number of tables created, I believe you will be mostly interested in ACTIVITYMETRICS_ACT_STMT. You can run your workload and then query that table (an example, there are a lot of other metrics that you might be interested in): db2 "select APPL_ID, sum(TOTAL_CPU_TIME) as SUM_TOTAL_CPU_TIME from ACTIVITYMETRICS_ACT_STMT where EVENT_TIMESTAMP > current_timestamp - 10 minutes group by APPL_ID" APPL_ID SUM_TOTAL_CPU_TIME *LOCAL.db2inst1.220316094506 2027 *LOCAL.db2inst1.220316094705 162 13x.23x.82.116.58680.220316094933 27 13x.23x.82.116.58788.220316095429 22 13x.23x.82.116.58790.220316095430 17367 13x.23x.82.116.58794.220316095447 429 6 record(s) selected. I replaced two digits with x. If you want to isolate the IP: db2 "select REGEXP_SUBSTR(APPL_ID, '^\d+\.\d+\.\d+\.\d+', 1, 1), sum(TOTAL_CPU_TIME) as SUM_TOTAL_CPU_TIME from ACTIVITYMETRICS_ACT_STMT where EVENT_TIMESTAMP > current_timestamp - 10 minutes group by REGEXP_SUBSTR(APPL_ID, '^\d+\.\d+\.\d+\.\d+', 1, 1)" 1 SUM_TOTAL_CPU_TIME 13x.23x.82.116 17845 22640 Remember to stop the monitor when you are finished

The problem seems to be unrelated to the Db2 container. I created a Dockerfile with: FROM registry.access.redhat.com/ubi8/ubi:8.5 as it's only content and could repeat the phenomena. I even removed all things but the mount of /etc/passwd and /etc/groups, but --user still fails. It looks as if --user X becomes uid 1000 in the container, regardless of what username X is, what uid X has in /etc/passwd does not seem to be taken into consideration. The two options I tried to get around this problem is: Create a "dummy" user in the Dockerfile: FROM ibmcom/db2 RUN groupadd --gid 422 db2iadm1 RUN useradd -u 422 -g db2iadm1 db2inst1 ... Or use the uid as an argument to --user: docker exec --user 422:422 -ti mydb2 bash --login -c "db2licm -l" Here I used --login to set up the correct environment. Using podman should remove much of the hassle I guess

a hint / link for the special question https://www.ibm.com/docs/en/db2-for-zos/12?topic=tablespace-reorganizing-catalog-directory PS db2 zos v12 utility guide is a pdf for download available. ----- searching for dsndb01 / dsndb06 (catalog DB) help's ---- the reorg/ rebuild index utility is the same as for user Tablespace

Try DECLARE VAR1_INPUT INT; DECLARE SQLSTRING VARCHAR(5000); DECLARE OUTPUTVAR INT; SET VAR1_INPUT = 5; SET SQLSTRING = 'select MYCOL INTO :OUTPUTVAR FROM MYSCHEMA.MYTABLE where MYVAL = '||CAST(VAR1_INPUT AS VARCHAR(25)); EXECUTE IMMEDIATE SQLSTRING; https://www.ibm.com/docs/en/db2/11.1?topic=statements-select-into PS. SELECT must return one row only. If not then limit the amount of rows returned (with some definite ordering).

If you leave the DB2, the external key cannot be shut off. It can be removed and re-established.Alter table ... drop constraint ... Alter table ... add constraint ...

Supported the removal of the linedataAdapter.FillSchema(dataSet, SchemaType.Mapped);

How can you encrypt the domen in punycode, and the row of the request in UTF, using percent‐encodingFor example, instead http://фр.рф/А/Б write http://xn--p1ah.xn--p1ai/%D0%90/%D0%91