Each database is owned by a server principal (aka login). Inside that database, the owning principal is known as dbo
(aka *D*ata*B*ase *O*wner). The database principal (aka user) loses its real name.
For example, for a database I own:
select [user].name as UserName -- Database specific
, [login].name as LoginName -- Server wide
from sys.databases d
join sys.database_principals as [user]
on [user].sid = d.owner_sid
join sys.server_principals as [login]
on [login].sid = d.owner_sid
Will print "dbo", "Andomar". If you'd change the owner to sa
:
exec sp_changedbowner 'sa'
The query would return "dbo", "sa".
You cannot modify the default schema for the user that owns a database. It is always user name dbo
with default schema name dbo
.
When you issue an ALTER TABLE
in PostgreSQL it will take an ACCESS EXCLUSIVE
lock that blocks everything including SELECT
. However, this lock can be quite brief if the table doesn't require re-writing, no new UNIQUE
, CHECK
or FOREIGN KEY
constraints need expensive full-table scans to verify, etc.
If in doubt, you can generally just try it! All DDL in PostgreSQL is transactional, so it's quite fine to cancel an ALTER TABLE
if it takes too long and starts holding up other queries. The lock levels required by various commands are documented in the locking page.
Some normally-slow operations can be sped up to be safe to perform without downtime. For example, if you have table t
and you want to change column customercode integer NOT NULL
to text
because the customer has decided all customer codes must now begin with an X
, you could write:
ALTER TABLE t ALTER COLUMN customercode TYPE text USING ( 'X'||customercode::text );
... but that would lock the whole table for the re-write. So does adding a column with a DEFAULT
. It can be done in a couple of steps to avoid the long lock, but applications must be able to cope with the temporary duplication:
ALTER TABLE t ADD COLUMN customercode_new text;
BEGIN;
LOCK TABLE t IN EXCLUSIVE MODE;
UPDATE t SET customercode_new = 'X'||customercode::text;
ALTER TABLE t DROP COLUMN customercode;
ALTER TABLE t RENAME COLUMN customercode_new TO customercode;
COMMIT;
This will only prevent writes to t
during the process; the lock name EXCLUSIVE
is somewhat deceptive in that it excludes everything except SELECT
; the ACCESS EXCLUSIVE
mode is the only one that excludes absolutely everyting. See lock modes. There's a risk that this operation could deadlock-rollback due to the lock upgrade required by the ALTER TABLE
, but at worst you'll just have to do it again.
You can even avoid that lock and do the whole thing live by creating a trigger function on t
that whenever an INSERT
or UPDATE
comes in, automatically populates customercode_new
from customercode
.
There are also built-in tools like CREATE INDEX CONCURRENTLY
and ALTER TABLE ... ADD table_constraint_using_index
that're designed to allow DBAs to reduce exclusive locking durations by doing work more slowly in a concurrency-friendly way.
The pg_reorg
tool or its successor pg_repack
can be used for some table restructuring operations as well.
Best Answer
My first quesiton is, what is "very huge?" Depending on the answer to that question, there may be other ways to optimize your migrations to reduce the time that they take.
Second question is, how often are you making schema changes on your live application?
If the online schema change tools don't work for you, you could try this from another angle. Use master/master replication in active/passive mode to minimize your downtime.
The following assumes that you have db1 and db2 in an active/passive master/master configuration...
For this to work, your schema migrations have to be backwards compatible, which is likely the case anyhow in most applications. This isn't zero downtime, but it is close. Realistically, most applications can tolerate a small amount of downtime periodically for maintenance. True zero downtime is a very expensive luxury.
To potentially speed up your table alters, look into using Percona Server and the expand_fast_index_creation setting.
Also, another option for online schema changes is Facebook's OSC.