I use DB2 Z/OS 11.01.
It's possible to rename a tablespace already defined on DB2 z/OS?
From the documentation I don't see any constraints but I can't.
Below I show you my test case:
I create a TS, a table and an index.
--
CREATE TABLESPACE TSFOOT
IN DBTEST01
USING STOGROUP SGTEST01
PRIQTY 48 SECQTY 48
ERASE NO
FREEPAGE 0 PCTFREE 5
GBPCACHE CHANGED
TRACKMOD YES
MAXPARTITIONS 1
LOGGED
DSSIZE 4 G
SEGSIZE 32
BUFFERPOOL BP1
LOCKSIZE ANY
LOCKMAX SYSTEM
CLOSE YES
COMPRESS NO
CCSID EBCDIC
DEFINE YES
MAXROWS 255;
--
COMMIT;
--
CREATE TABLE TEST01.TBFOOT
(FIELD1 CHAR(2) FOR SBCS DATA NOT NULL,
FIELD2 DATE NOT NULL,
FIELD3 DECIMAL(7, 0) NOT NULL,
FIELD4 DECIMAL(7, 0) NOT NULL,
FIELD5 DECIMAL(3, 0) NOT NULL,
CONSTRAINT PK_TBFOOT
PRIMARY KEY (FIELD1,
FIELD2))
IN DBTEST01.TSFOOT
PARTITION BY SIZE
AUDIT NONE
DATA CAPTURE NONE
CCSID EBCDIC
NOT VOLATILE
APPEND NO ;
--
COMMIT;
--
CREATE UNIQUE INDEX TEST01.IXFOOTP
ON TEST01.TBFOOT
(FIELD1 ASC,
FIELD2 ASC)
USING STOGROUP SGTEST01
PRIQTY 48 SECQTY 48
ERASE NO
FREEPAGE 0 PCTFREE 10
GBPCACHE CHANGED
CLUSTER
COMPRESS NO
INCLUDE NULL KEYS
BUFFERPOOL BP2
CLOSE NO
COPY NO
DEFER NO
DEFINE YES
PIECESIZE 2 G;
--
COMMIT;
--
CREATE SYNONYM TBFOOT FOR TEST01.TBFOOT;
--
COMMIT;
--
I run the statements to rename the tablespace.
RENAME TABLESPACE TSFOOT TO TSFOOT_NEW;
I get the following error:
ILLEGAL SYMBOL "TSFOOT". SOME SYMBOLS THAT MIGHT BE LEGAL ARE: . TO. SQLCODE=-104, SQLSTATE=42601, DRIVER=4.19.56
Can I get some help here, please?
Thank you very much.
Using Db2 you have to be cautious when looking for the documentation.
There are 2 different platforms:
Db2 (formerly Db2 for Linux UNIX and Windows)
Db2 for z/OS
Basically they have the same syntax. But there are slightly differences when digging deeper. Rule of thumb: z/OS supports less commands than Unix/Windows.
In your case look at the correct documentation (and create a bookmark): https://www.ibm.com/support/knowledgecenter/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_rename.html
And you see that renaming table spaces on z/OS is not possible.
Related
Here is the test case and results:
drop table if exists test1;
drop table if exists test2;
drop trigger if exists test1_tr on test1;
drop function if exists tf_test1;
create table test1 (name varchar(8) not null);
create table test2 (name varchar(8) not null);
\echo create trigger function tf_test1
CREATE OR REPLACE FUNCTION tf_test1() RETURNS trigger AS $BODY$
BEGIN
IF TG_OP = 'INSERT' THEN
INSERT INTO test2(name) VALUES (NEW.name);
END IF;
return new;
END
$BODY$
LANGUAGE 'plpgsql';
\echo create trigger test1_tr
CREATE TRIGGER test1_tr
AFTER INSERT OR UPDATE OR DELETE ON test1 FOR EACH ROW
EXECUTE PROCEDURE tf_test1();
\echo Insert
insert into test1 (name) values ('NAME_001');
insert into test1 (name) values ('NAME_002');
insert into test1 (name) values ('NAME_003');
insert into test1 (name) values ('NAME_004');
\echo Select test1
select * from test1;
\echo Select test2
select * from test2;
---------------------------- output -------------------------------
DROP TABLE
DROP TABLE
DROP TABLE
DROP TABLE
DROP TRIGGER
DROP FUNCTION
CREATE TABLE
CREATE TABLE
create trigger function tf_test1
CREATE FUNCTION
create trigger test1_tr
CREATE TRIGGER
Insert
INSERT 0 1
psql:test3.sql:28: ERROR: cache lookup failed for type 113
CONTEXT: SQL statement "INSERT INTO test2(name) VALUES (NEW.name)"
PL/pgSQL function tf_test1() line 4 at SQL statement
INSERT 0 1
INSERT 0 1
Select test1
name
----------
NAME_001
NAME_003
NAME_004
(3 rows)
Select test2
name
----------
NAME_001
NAME_003
NAME_004
(3 rows)
We have several servers running various flavors of RHEL 7.x. All Postgres instances are v11. This is happening on about 1/2 of them. There doesn't seem to be any consistent RH version that is the culprit.
I have queried both pg_class and pg_type for the OID referenced as the missing type. In all cases, the result set is empty.
Any help is appreciated.
I would also appreciate an insight into what's happening with Postgres. I'm a long-time Oracle DBA, but fairly new to Postgres. It seems like an internal Postgres error and not really a code problem, but a web search doesn't turn up much.
Follow-up on this to provide some closure. We had increased our buffer and effective cache size in the Postgresql.conf file and also turned Auditing on (pgaudit extension) full blast...For the machines where the PG memory conf parameters exceeded the physical memory of the machine and auditing was turned on, we would get cache lookup errors. A clue about this was the errors would hop around in the job flow, were not consistent from machine to machine and were effectively unsquashable bugs (dropping the offending trigger would just cause the cache error somewhere else in the job stream).
For now, we have increased the physical memory of the servers and turned auditing off. The cache lookup errors are gone. Further tuning is needed so we can eventually turn auditing back on.
I'm attempting to move a SQL Server DB which is used by a C# application (+EF6) to Postgres 12 but I'm not having much luck with getting case-insensitive string comparisons working. The existing SQL Server db uses SQL_Latin1_General_CP1_CI_AS collation which means all WHERE clauses don't have to worry about case.
I understand that CIText was the way to do this previously, but is now superseded by non-deterministic collations.
I created such a collation;
CREATE COLLATION ci (provider = icu, locale = 'und-u-ks-level2', deterministic = false);
and when this is applied to the CREATE TABLE on a per-column basis it does work - case is ignored.
CREATE TABLE casetest (
id serial NOT NULL,
code varchar(10) null COLLATE "ci",
CONSTRAINT "PK_id" PRIMARY KEY ("id"));
But from what I have read it must be applied to every varchar column and can't be set globally across the whole db.
Is this correct?
I don't want to use .ToLower() everywhere due to clutter and that any index on the column is then not used.
I tried modifying the pre-existing 'default' collation in pg_collation to match the settings of 'ci' collation but it has no effect.
Thanks in advance.
PG
You got it right. From PostgreSQL v15 on, ICU collations can be used as database collations, but only deterministic ones (that don't compare different strings as equal). So your case-insensitive collation wouldn't work there either. Since you are using v12, you cannot use ICU collations as database default collation at all, but have to use them in column definitions.
This limitation is annoying and not in the nature of things. It will probably be lifted in some future version.
You can use a DO statement to change the collation of all string columns:
DO
$$DECLARE
v_table regclass;
v_column name;
v_type oid;
v_typmod integer;
BEGIN
FOR v_table, v_column, v_type, v_typmod IN
SELECT a.attrelid::regclass,
a.attname,
a.atttypid,
a.atttypmod
FROM pg_attribute AS a
JOIN pg_class AS c ON a.attrelid = c.oid
WHERE a.atttypid IN (25, 1042, 1043)
AND c.relnamespace::regnamespace::name
NOT IN ('pg_catalog', 'information_schema', 'pg_toast')
LOOP
EXECUTE
format('ALTER TABLE %s ALTER %I SET DATA TYPE %s COLLATE ci',
v_table,
v_column,
format_type(v_type, v_typmod)
);
END LOOP;
END;$$;
During the upgrade from DB2 9 to DB2 10 on z/OS, the previous (now retired) DBA converted all tablespaces from "simple" to "universal". How can I determine if they are partition-by-range or partition-by-growth?
Using RC/Query in CA/Tools from Computer Associates, I was able to reverse-engineer the CREATE TABLESPACE statement, but it's not obvious from the code which type of tablespace this is.
CREATE TABLESPACE SNF101
IN DNF1
USING STOGROUP GNF2
PRIQTY 48
SECQTY 48
ERASE NO
BUFFERPOOL BP1
CLOSE NO
LOCKMAX SYSTEM
SEGSIZE 4
FREEPAGE 0
PCTFREE 5
GBPCACHE CHANGED
DEFINE YES
LOGGED
TRACKMOD YES
COMPRESS NO
LOCKSIZE ANY
MAXROWS 255
CCSID EBCDIC
;
Given that CREATE TABLE statement, how can I determine if this is partition-by-range or partition-by-growth?
Thanks!
Check if your version of the CA/Tools is capable of recognizing the tablespace types and also generating the matching DDL.
Check the SYSIBM.SYSTABLESPACE column TYPE, value G indicates partition-by-growth, value R indicates partition by range.
I have HEX data like this (F9F9F9F9) returned from a query. When I checked from IBM link :
https://www.ibm.com/support/knowledgecenter/en/SS2MB5_14.1.0/com.ibm.xlf141.bg.doc/language_ref/asciit.html
F9 = 9 and F9 = 9
Here I should get result as 9999
I jhave around 1000 hex records like this in a table.
How can I convert this hex values to it corrsponding EBCDIC ?
I tried like :
select cast(col char(2) as codebase(37)) from table
How ever, its not working.
THis link is also not working: I'm not sure if its a cobol code or DB2 script. : http://www.ibmmainframeforum.com/db2/topic8785.html
Please help.Thanks.
select cast(col char(2) as codebase(37)) from table
Correct Syntax.
select cast(col as char(2) ccsid 37) as col from table
Generally you don't want to do this over and over so maybe just alter the table.
ALTER TABLE mylib/Z1 ALTER COLUMN JOJOB SET DATA TYPE CHARACTER (
10) CCSID 37 NOT NULL WITH DEFAULT
Or create a view over the table for read only data and read from the view.
create view tablev as
select cast(col as char(2) ccsid 37) as col from table
I an learning to write triggers in DB2. I need one and only 1 record in mytable have ENABLED_IND= 'Y'.
CREATE TABLE MYTABLE(
OBJECTID BIGINT GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1, NO CACHE, NO CYCLE),
MYDATA VARCHAR(8) NOT NULL,
....
ENABLED_IND CHAR(1) NOT NULL
) IN "TS_PROF_D" INDEX IN "TS_PROF_IX" ;
when ever I insert into mytable I need all existing ENABLED_IND to be set to "N". I came up with the following, a oracle EE dba says it should work, but does not
CREATE TRIGGER MYSCHEMA.MYTRIGGER BEFORE INSERT ON MYSCHEMA.MYTABLE
FOR EACH ROW MODE DB2SQL
BEGIN ATOMIC
UPDATE MYSCHEMA.MYTABLE SET ENABLED_IND = 'N';
END
All db2 is telling me "illegal character" We don't see an illegal character. The web examples of db2 triggers are very confusing.