New answers tagged

-1

Maybe try something like this: db2move sample export -aw -l lobs -ts USERSPACE1


0

From my experience there can be just 1 catalog per 1 linked server You will need to create separate linked servers for each database on remote server (DB2) that you want to be available for querying on your "local" server (SQL Server)


0

How did you determine that the table(s) has no unique indexes? Primary keys and unique constraints are implemented via unique indexes (unless the are informational constraints, i.e. NOT ENFORCED). Try: SELECT INDSCHEMA, INDNAME FROM SYSCAT.INDEXES WHERE UNIQUERULE IN ('U','P') AND TABSCHEMA = '...' AND TABNAME = '...'


0

https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.5.0/com.ibm.db2.luw.admin.dbobj.doc/doc/c0061097.html It is important to understand that there is no significant difference between a primary key or unique key constraint and a unique index. To implement the concept of primary and unique key constraints, the database manager uses a combination of a ...


0

On Db2 v 11 try adding the ALLOW_READ_ACCESS option: db2 "CALL SYSPROC.ADMIN_MOVE_TABLE ('DB2INST1','SIMLATS','SYSTOOLSPACE','SYSTOOLSPACE','SYSTOOLSPACE','','','','','ALLOW_READ_ACCESS','MOVE')"


2

Try this: with subscription_types (type) as ( values 'type1' , 'type2' ) , subscriptions (user, sub_type, subscribed) as ( values ('U1', 'type1', 'Y') , ('U1', 'type2', 'Y') , ('U2', 'type1', 'Y') ) select u.user, t.type from ( select distinct s.user from subscriptions s ) u, subscription_types t where not exists (select 1 from subscriptions ...


2

It seems to me that you want the cartesian product between users and subscription_types, minus the subscriptions: select distinct s.user, st.subscription_types from subscriptions s cross join subscription_types st except select user, sub_type from subscriptions This can, of course, be expressed in other ways, but this is probably the most obvious one.


2

As a side note, REORGCHK is not the right way to determine if the table needs reorganization post-ALTER. It is intended to analyze object statistics to determine if the table or its indexes can be optimized in some way. Subsequently, an attempt to scan its indexes to update statistics will necessarily fail. REORGCHK calculates several metrics, such as the ...


2

I'm not sure REORGCHK UPDATE STATISTICS is the way to go after a destructive operation (drop column) against a table. I suspect that the drop statement put a Z-lock on some catalog tables which prevents STATISTICS from being updated. If you are only interested in whether you need to reorg a table due to the drop you can: SELECT NUM_REORG_REC_ALTERS, ...


Top 50 recent answers are included