In H2 database there is something called as:
DROP ALL OBJECTS;
which drops all existing views, tables, sequences, schemas, function aliases, roles, user-defined aggregate functions, domains, and users (except the current user). If DELETE FILES is specified, the database files will be removed when the last user disconnects from the database. (See here)
How can I do exactly same thing in Postgresql ?
Related
I am wanting to know how an AWS postgres RDS does replication where I rename schemas to "swap" them within the read/write instance of the database.
Does it replicate this action to the read-replicas by sending on the "alter schema" rename commands I gave to my read/write instance? Or after my renames, does it see wholly different sets of data in the schemas and do a whole new copy of each out to the read-replicas?
For example...
In my RDS instance I have a read/write instance of "my_mega_database" which I want to create read-replicas of for my applications to connect to.
Typically, in "my_mega_database" there are two schemas "my_data" and "my_data_old", whereby "my_data" contains data that was delivered last night, and "my_data_old" contains data from the previous night. Each contains many tables and huge amounts of data.
If I were to do the following...
ALTER SCHEMA my_data_old RENAME TO my_data_tmp;
ALTER SCHEMA my_data RENAME TO my_data_old;
ALTER SCHEMA my_data_tmp RENAME TO my_data;
... I have affectively swapped these around.
My expectation is that these actions are replicated via the postgres WAL (ie: it sends the rename commands out to the replicas) and AWS RDS replication won't try and waste time copying huge amounts of data all over the place.
Is this correct?
(Speaking about PostgreSQL here, but RDS is probably similar.)
Renaming a schema (or any other object) is a small update in a catalog table, and no data are moved. Internally PostgreSQL uses only the numeric object ID, which stays the same.
You might wrap the three statements in a transaction to make the whole magic atomic.
The same is true on the standby, it is a trivial (meta)data modification.
The only thing that might be a problem are concurrent sessions holding locks.
I am looking for a way to create folders inside the temp_08 folder. Temp_08 is the only folder I have write access to, so I need to create the folder INSIDE temp_08. I was looking to store tables inside this folder, so to more cleanly organize my tables. What is the best way to perform this function in Redshift?
Amazon Redshift is based on a fork of PostgreSQL. Therefore, it inherits many of the attributes of PostgreSQL.
To arrange your tables into more logical groups, you can use:
CREATE DATABASE
CREATE SCHEMA
From the Schemas documentation:
A database contains one or more named schemas. Each schema in a database contains tables and other kinds of named objects. By default, a database has a single schema, which is named PUBLIC. You can use schemas to group database objects under a common name. Schemas are similar to operating system directories, except that schemas cannot be nested.
Basically, a Database is a separate logical grouping. You connect to a specific database when connecting with Amazon Redshift. Schemas exist within a Database and a search path can determine which one to use (for example, a personal schema first, then a default schema).
I am using the ddlgen tool to get DDLs or whole databases. Now I need to re-generate databases into another location (structure only).
Can anyone help me to re-create database schema in another location?
ddlgen creates sql scripts
To recreate your database structure, just run the scripts in the correct order against your new system.
isql -Uusername -Sservername -iDDLGenScript.sql
If you have multiple scripts, then this is the recommended order from the SAP ASE Documentation
Segment
Group
User
Rules
Defaults
UDDs
Encrypted Keys
User Tables
Proxy Tables
Triggers
Functions and Views
All functions without any dependency
All views without any dependency
All functions and all views with any dependency on any objects
Instead of trigger
Stored Procedures
Extended Stored Procedures
PRS
User Defined Web Services
I have a running database with only one dba (i.e. other than sys, system) "abc". Under this oracle user I have tables, views, sequences, procedures, functions etc. Now I have to copy both the data and schema to another database at another machine that already have a dozen schemas running (one under each separate dba). I have following concerns:
(1) I have to rename the schema at old machine, from "abc" to "pqr" before moving to the new machine.
(2) Inside my procedures and functions, I am using AUTHID CURRENT_USER, therefore have to use "abc." qualifier before name of tables, views, sequences, procedures, functions. When changing schema name, is there some automatic way to change qualifiers too.
(3) In order to copy data, I know only one way, which is to take backup of database of only one user "abc" (i.e. not take backup of sys, system). Then restore that to the new database. Can this in anyway destroy the other schemas or their data.
(4) In my schema, I am creating oracle users with limited rights using a procedure. The new usernames are stored in a Users table. I am also creating database roles and associating users with roles. The rolenames are stored in a Roles table. When migrating to new machine I have to make sure to prefix my users and roles with something unique so I not disturb oracle users created by other schemas.
(5) I know that in the new database, there have to be a new dba user called "pqr". Do I also have to have sysdba privilege. I am not responsible about the whole database at new machine, I am responsible about my schema only. Being a sysdba, can I in anyway hurt other dbas (like dropping them, or changing their schemas). If I not have sysdba privilege, what limitations do I get. I am using OracleText so have to use some built-in packages. I also have to create physical directory on file system in windows. I also have to create, alter (change password), drop roles and users via stored procedures when connected to database using "pqr".
Both old and new database are running on separate dedicated machines. Its windows server 2003 with oracle 10gr1.
The simplest option would be to use the Oracle export utility (classic or DataPump) to take a logical backup of the abc schema in the first database and to import the backup using the Oracle import utility into the new database. If you're using the classic version, you'd use the FROMUSER and TOUSER parameters to specify that you want to import the data into a different schema. If you're using the DataPump version, you'd use the REMAP_SCHEMA parameter. The DataPump version will be more efficient if you have a relatively large amount of data.
Unfortunately, though, there is no way to change explicit schema qualifiers. You'll need to edit the code after you import it or pull the code from your source control system, edit the code, and deploy it to the new database.
I have a schema schema1 in a postgres database A. I want to have a duplicate of this schema (model + data) in database B under the name schema2.
What are my options ?
I currently :
* dump schema1 from database A
* sed my way through schema renaming in the dump : schema1 becomes schema2
* restore schema2 in database B
but I am looking for a more efficient procedure. For instance, via direct file operations on postgres binary files.
Thanks for your help
Jerome Wagner
First, be aware (as others have commented) that Postgresql and Mysql have different ideas on what is a SCHEMA. In Postgresql (and in the SQL standard) a schema is just a namespace inside a database, which you can use to qualify object names (analogous to directories and files; and there is a 'public' schema whichs is used as default for unqualified names). Schemas, then, are related to organization of names, not isolation: as long as we are inside a database, objects (tables, views...) from different schemas are mutually visible; so that, for example, a view can mix tables of different schemas, or a FK can refer to other schema. On the contrary, objects in different databases are isolated (they only share users and groups), you can't join tables of different databases.
A dump-restore is the only sane way I can think of, for copying a schema from one database to another. Even so, from the above, it might not be safe/possible if the schema depends on other schemas of the database (it's like you are copying the classes of a Java package from one project to another). I would not dream on attempting a copy of the binary files.