I have a table X in tablespace T1 and a table Y in tabelspace T2.(Oracle DB)
I have to create a trigger in tablespace T1 that will,
on the event of updating a column C in table X,
update column D in table Y (tablespace T2).
Because they are in different tablespaces, my first question is can this be done at all?
And if yes then how it can be done? What privileges are required to do such a thing?
It has not so much to do with the tablespace. You do need privileges to insert into the table (and that particular column) though, and if the table Y is in another schema than the trigger, you need to use the qualified table name: . (In Oracle, the schemaname is the name of the user that owns the object)
CREATE TRIGGER aur_x
AFTER UPDATE OF c ON x
FOR EACH ROW
UPDATE schema_containing_y.Y SET D = ...
;
EDIT:
It just occurred to me that you might not be familiar with the distinction between schema and tablespace, so here's a short explanation. A tablespace is a logical storage container: it dedfines datafiles, growth characteristics, logging types etc. Tablespaces can then be used as to store data associated with schema objects (tables, indexes, views definitions, but also packages and stored procedure definitions etc).
A schema is a collection of objects (like tables, views, pacakages etc.) These objects are owned by a user, and as far as i am aware, in oracle the schema has an name identical to the user that owns the objects. THe objects rely on the storage provided by one or more tablespaces, but tablespaces themselves are not schema objects.
Typically, a schema is used to group functionally related objects (for example, you'd typically create one schema for one application). Tablespaces can also be created especially to store all objects of one application, but you can also create different tablespaces for tables with different characteristics.
Normally, application developers shouldn't worry too much about tablespaces. Your DBA will typically set them up in a way that is convenient for things like backup plan.
Related
I need to get complete list of external tables in db2 database. I have defined schema called DB2INST1. How to get complete list of external tables information using system tables?
The information lives in syscat.tables (documentation here) for Db2-LUW databases that support external tables, which have their PROPERTY column with value Y in position 27 of that column.
Example query returns the fully qualified name of external tables:
select trim(tabschema)||'.'||rtrim(tabname)
from syscat.tables
where substr(property,27,1)='Y'
with ur;
In general, the best and most reliable way to retrieve all information and to recreate the DDL statements for tables is to use the db2look tool. If you want to extract the metadata on your own, there are some catalog views to start with:
SYSCAT.TABLES holds the table information. Look for the PROPERTY column and check there if it is an external table.
SYSCAT.COLUMNS has the basic column information. But there are more related tables depending on types and attributes.
SYSCAT.EXTERNALTABLEOPTIONS shows the actual options for an external table, the things in addition to what makes a regular table.
There are many more tables to hold table properties, depending on the complexity of the table and column definitions.
I have two database.
Primary have a DDL triggers so i can't create memory optimized tables there. So i created secondary database and create there table with memory optimized on. Now, in procedure on primary database i need insert copy data from other table to this optimized.
For example:
INSERT INTO InMemory.dbo.DestTable_InMem SELECT * FROM #T;
And i have:
A user transaction that accesses memory optimized tables or natively compiled modules cannot access more than one user database or databases model and msdb, and it cannot write to master.
Did exists some workarounds from it?
I cannot move my procedure to second database.
There is no other way than using a native procedure to INSERT, UPDATE or DELETE in an in-memory table.
See: A Guide to Query Processing for Memory-Optimized Tables
To move from one DB to the other, the source table must exists locally
I have table A in schema A and table B in schema B with same structure in the same database. Whenever a DML change happens in table A, I need the same in table B. For now, I am using triggers to do the same. Is there any better alternative than using triggers for this scenario?
As the tables belong to different microservices, I need one of the tables with data unmodified even if the other table is dropped.
How do we map the logical table to the tablespace?
Does Postgres automatically creates tablespaces when we create a table or a schema?
Tablespaces and schemas are independent from each other: the first concerns the physical placement of the table, the second the namespace.
PostgreSQL automatically creates a tablespace: it is called pg_default and is located in the base subdirectory of the data directory.
All tables you create are placed there unless:
You use the TABLESPACE clause of CREATE TABLE to place it elsewhere.
The table is in a database with a different tablespace.
You set the default_tablespace parameter to a different tablespace.
Tablespaces are rarely needed, and usually it is best to keep all tables in the default tablespace.
From https://stackoverflow.com/a/17943883/156458
in both Postgres and the SQL Standard we have this containment
hierarchy:
A computer may have one cluster or multiple.
A database server is a cluster.
A cluster has [catalogs][8]. ( Catalog = Database )
Catalogs have [schemas][9]. (Schema = [namespace][10] of tables, and security boundary)
Schemas have [tables][11].
Tables have [rows][12].
Rows have values, defined by [columns][13].
In postgresql, I have a database called students and there is a table called student under it:
postgres=# \c students
You are now connected to database "students" as user "postgres".
students=# \dt;
public | student | table | postgres
I was wondering if database students is also a catalog?
Where is the schema between students and student?
In general, how can I list
all the catalogs and
all the schemas under a catalog, and
all the tables under a schema?
How can I show
the current catalog, and
the current schema?
Thanks.
In shortly, I usually explain to my junior teammate when they starting to research about PostgreSQL.
In PostgreSQL:
A Database Server is like an Industrial Zone, there will have many Databases-Cluster (Building)
Each Database-Cluster (Building) have many Databases. Those are like the floors in Building. The Databases is here as you call the Catalogs. Those Databases-Catalogs (floors) are quite independent with each other, you can not using others materials directly, you must use somethings just like stair, electric wire ... (in database is DBLINK).
Okay, next, each Database-Catalogs have many Schemas, which are like many Rooms on your floors. Those Schemas can use the material from each others.
Then, each Schemas have many cell elements such as Table, View, Function, Sequence .... All schemas have the same structure.
Now, back to you example:
students: is Database (which you call Catalogs)
public: is schema.
student: is table.
public | student | table | postgres is corresponding with schema | table | kind of table | owner of table
You can list:
catalogs (Database) by the command \l in psql or query select * from pg_database;
Schemas under a catalog by the command \dn in psql or query select * from information_schema.schemata;
Tables under a schemas by the query select * from pg_tables WHERE schemaname = 'Your schema';
You can show:
Current Database (Catalogs) by the query select current_database();
Current Schema by the query select current_schema;
Please pay attention that PostgreSQL have two system schema call information_schema and pg_catalog, this maybe make you confuse.
The pg_catalog is a system schema. More information.
The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information. PostgreSQL's system catalogs are regular tables. You can drop and recreate the tables, add columns, insert and update values, and severely mess up your system that way. Normally, one should not change the system catalogs by hand, there are always SQL commands to do that. (For example, CREATE DATABASE inserts a row into the pg_database catalog — and actually creates the database on disk.) There are some exceptions for particularly esoteric operations, such as adding index access methods.
The information_schema is a system schema. More information.
The information schema consists of a set of views that contain information about the objects defined in the current database. The information schema is defined in the SQL standard and can therefore be expected to be portable and remain stable — unlike the system catalogs, which are specific to PostgreSQL and are modeled after implementation concerns. The information schema views do not, however, contain information about PostgreSQL-specific features; to inquire about those you need to query the system catalogs or other PostgreSQL-specific views.
I hope these information will help you clearly.