Groovy DBA

   CLICK ON BACKUP   On the GENERAL tab, In the pop up window, choose  (1) a path and file name (2) DIRECTORY as the format   On the DATA OPTIONS tab, make the choices as above Click BACKUP button   Track the backup on the PROCESSES tab. Click on the notepad to see the log:     Run the backup of the same schema for a second time, but this time to capture the POST data. Name the file an appropriate name. But this time in the DATA OPTIONS tab, choose POST-DATA:   In the DATA OPTIONS tab, choose POST-DATA plus the other options as the screenshot above. Then click on the BACKUP button. Again, you can track the backup in the PROCESSES tab. (see pages 3 and 4) On the target database, the schema should not exist. So if exist, please ‘DELETE CASCADE . . .’ the schema.  Right click on RESTORE of the target database:   Then Click on RESTORE   On the pop up window, in the GENERAL tab, choose (1) FORMAT as directory (2) Filename of...

  ALTER USER davide WITH PASSWORD 'hu8jmn3';

 (1)  [tst3ins3@db2tst601  ~] $ db2 connect to wctst10    Database Connection Information  Database server        = DB2/LINUXX8664 11.5.8.0  SQL authorization ID   = TST3INS3  Local database alias   = wctst10 [tst3ins3@db2tst601  ~] $ db2haicu disable Welcome to the DB2 High Availability Instance Configuration Utility (db2haicu). Option 'disable' is not recognized. >>-db2haicu-----+------------------------------------------+->                 +- -f--input file--------------------------+                 +- -o--output file-------------------------+                 +- -disable--------------------------------+                 '- -delete--+---------------------------+--'                     ...

 $  db2set db2comm= ;db2 force applications all;db2stop force;db2start

  gm15@1099ISP201118D MINGW64 /c/Users/gm15/source/repos/gcp (todelete2DBs_1) $ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. gm15@1099ISP201118D MINGW64 /c/Users/gm15/source/repos/gcp (master)        <-- TO SYNC MASTER WITH YOUR LOCAL COPY $ git pull remote: Enumerating objects: 12, done. remote: Counting objects: 100% (12/12), done. remote: Compressing objects: 100% (9/9), done. remote: Total 12 (delta 4), reused 9 (delta 3), pack-reused 0 Unpacking objects: 100% (12/12), 3.97 KiB | 71.00 KiB/s, done. From https://github.com/MensWearhouse/gcp    b5df3d22..6b119f90  master      -> origin/master  * [new branch]        DEVOPS-1298 -> origin/DEVOPS-1298 Updating b5df3d22..6b119f90 Fast-forward  CODEOWNERS                                      |  2 +-...

 -- PUT THE BACKUP AND THE DB2.RERESH.SH SCRIPTS IN THE SAME DIRECTORY $ cp /usr/opt/app/dbdump/db_refresh/db2.refresh.sh  cp /usr/opt/app/dbdump/db_refresh/wcdev1 $  -- AFTER THE BACKUP FILE IS COPIED AND REFRESH SCRIPT IS WHERE THEY ARE SUPPOSE TO BE, THEN ENSURE YOU ARE  LOGGED IN AS THE DATABASE OWNER. IN THIS CASE, dev1ins1 -- VERIFY THAT ALL APPLICATIONS ARE DISCONNECTED: $ db2 list applications -- TO KICK OFF THE APPLICATION AND IMMEDIATELY BOUNCE THE DATABASE $  db2set db2comm= ;db2 force applications all;db2stop force;db2start # db2 force applications all;db2stop force; db2set db2comm=tcpip; db2start #db2 "select count(*) from wcs.inventory" -- THEN CHECK AGAIN TO ENSURE THE APPLICATIONS ARE DISCONNECTED $ db2 list applications db2 terminate db2 deactivate db wcdev9 -- TO KICK OFF THE REFRESH -- $ ./db2.refresh.sh -s wcstg1 -t wcdev1 -l /usr/opt/app/dbdump/db_refresh/wcdev1 $ ./db2.refresh.sh -s wcstg1 -t wcdev9 -l /usr/opt/app/dbdump/db_refresh $ ...

 db2 -v "export to /usr/opt/app/dbdump/dev4ins4/COLLDESC_2rows.del of del lobs to /usr/opt/app/dbdump/dev4ins4  select * from wcs.COLLDESC where collateral_id in ( select collateral_id from wcs.COLLATERAL where name like '%MO_CONFIGURATION_DATA_CONTENT%')" db2 -v "export to /usr/opt/app/dbdump/dev4ins4/COLLDESC.del of del lobs to /usr/opt/app/dbdump/dev4ins4  select * from wcs.COLLDESC" db2 -v "export to /usr/opt/app/dbdump/dev4ins4/STORECONF.del of del lobs to /usr/opt/app/dbdump/dev4ins4  select * from wcs.STORECONF" db2 -v "export to /usr/opt/app/dbdump/dev4ins4/KEYS.del of del lobs to /usr/opt/app/dbdump/dev4ins4  select * from wcs.KEYS" (1) Masking data after post db refresh. truncate table wcs.xuseroptin immediate; -- truncate table wcs.staglog immediate;  <-- only when refreshed from wcstg1 -- truncate table wcs.staglog_archive immediate; <-- only when refreshed from wcstg1 -- truncate table wcs.cacheivl immediate;  <-- on...

  the TAB8K tablespace is defined (by default) as a regular tablespace instead of a large tablespace.  Regular tablespaces have an architectural limit of 16,777,216 pages, and you hit that limit in WCSTG1.   The STAGLOG_ARCHIVE table appears to be the reason that we hit the 16.7M page limit, as STAGLOG_ARCHIVE is using over 6.7 million pages of the tablespace (not including indexes).  This table is not part of the standard WCS schema. We resolved this issue by issuing  ALTER TABLESPACE TAB8K CONVERT TO LARGE  .  This increased the tablespace's page limit to 4,294,967,296 pages. Technically, when you convert a tablespace to large you are also supposed to reorg all indexes for the tables that reside in the tablespace.  However, given the size of all of the standard WCS tables, this is not strictly necessary. However, I would absolutely recommend that you move the STAGLOG_ARCHIVE table to a new large tablespace.  This can be done onlin...