ALTER DATABASE - Amazon Redshift
Required privilegesSyntaxParametersUsage notesExamples
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

ALTER DATABASE

Changes the attributes of a database.

Required privileges

To use ALTER DATABASE, one of the following privileges is required..

  • Superuser

  • Users with the ALTER DATABASE privilege

  • Database owner

Syntax

ALTER DATABASE database_name
{ RENAME TO new_name
| OWNER TO new_owner
| CONNECTION LIMIT { limit | UNLIMITED }
| COLLATE { CASE_SENSITIVE | CASE_INSENSITIVE }
| ISOLATION LEVEL { SERIALIZABLE | SNAPSHOT }
| INTEGRATION {{SET REFRESH_INTERVAL <interval>} | REFRESH {{ ALL | INERROR } TABLES [IN SCHEMA schema [, ...]] | TABLE schema.table [, ...]}}
}

Parameters

database_name

Name of the database to alter. Typically, you alter a database that you are not currently connected to; in any case, the changes take effect only in subsequent sessions. You can change the owner of the current database, but you can't rename it:

alter database tickit rename to newtickit;
ERROR:  current database may not be renamed
RENAME TO

Renames the specified database. For more information about valid names, see Names and identifiers. You can't rename the dev, padb_harvest, template0, template1, or sys:internal databases, and you can't rename the current database. Only the database owner or a superuser can rename a database; non-superuser owners must also have the CREATEDB privilege.

new_name

New database name.

OWNER TO

Changes the owner of the specified database. You can change the owner of the current database or some other database. Only a superuser can change the owner.

new_owner

New database owner. The new owner must be an existing database user with write privileges. For more information about user privileges, see GRANT.

CONNECTION LIMIT { limit | UNLIMITED }

The maximum number of database connections users are permitted to have open concurrently. The limit is not enforced for superusers. Use the UNLIMITED keyword to permit the maximum number of concurrent connections. A limit on the number of connections for each user might also apply. For more information, see CREATE USER. The default is UNLIMITED. To view current connections, query the STV_SESSIONS system view.

Note

If both user and database connection limits apply, an unused connection slot must be available that is within both limits when a user attempts to connect.

COLLATE { CASE_SENSITIVE | CASE_INSENSITIVE }

A clause that specifies whether string search or comparison is case-sensitive or case-insensitive.

You can change the case sensitivity of the current database which is empty.

You must have the privilege to the current database to change case sensitivity. Superusers or database owners with the CREATE DATABASE privilege can also change database case sensitivity.

ISOLATION LEVEL { SERIALIZABLE | SNAPSHOT }

A clause that specifies the isolation level used when queries run against a database.

  • SERIALIZABLE isolation – provides full serializability for concurrent transactions. For more information, see Serializable isolation.

  • SNAPSHOT isolation – provides an isolation level with protection against update and delete conflicts.

For more information about isolation levels, see CREATE DATABASE.

Consider the following items when altering the isolation level of a database:

  • You must have the superuser or CREATE DATABASE privilege to the current database to change the database isolation level.

  • You can't alter the isolation level of the dev database.

  • You can't alter the isolation level within a transaction block.

  • The alter isolation level command fails if other users are connected to the database.

  • The alter isolation level command can alter the isolation level settings of the current session.

INTEGRATION REFRESH {{ ALL | INERROR } TABLES [IN SCHEMA schema [, ...]] | TABLE schema.table [, ...]}

A clause that specifies whether Amazon Redshift will refresh all tables or tables with errors in the specified schema or table. The refresh will trigger the tables in the specified schema or table to be fully replicated from the source database.

For more information, see Working with zero-ETL integrations in the Amazon Redshift Management Guide. For more information about integration states, see SVV_INTEGRATION_TABLE_STATE and SVV_INTEGRATION.

INTEGRATION {SET REFRESH_INTERVAL <interval>}

The SET REFRESH_INTERVAL clause sets the approximate time interval, in seconds, to refresh data from the zero-ETL source to the target database. The interval can be set 0–432,000 seconds (5 days) for zero-ETL integrations whose source type is Aurora MySQL, Aurora PostgreSQL, or RDS for MySQL. For Amazon DynamoDB zero-ETL integrations, the interval can be set 900–432,000 seconds (15 minutes –5 days).

For more information about creating databases with zero-ETL integrations, see Creating destination databases in Amazon Redshift in the Amazon Redshift Management Guide.

Usage notes

ALTER DATABASE commands apply to subsequent sessions not current sessions. You must reconnect to the altered database to see the effect of the change.

Examples

The following example renames a database named TICKIT_SANDBOX to TICKIT_TEST: 

alter database tickit_sandbox rename to tickit_test;

The following example changes the owner of the TICKIT database (the current database) to DWUSER: 

alter database tickit owner to dwuser;

The following example changes the database case sensitivity of the sampledb database:

ALTER DATABASE sampledb COLLATE CASE_INSENSITIVE;

The following example alters a database named sampledb with SNAPSHOT isolation level.

ALTER DATABASE sampledb ISOLATION LEVEL SNAPSHOT;

The following example refreshes the tables schema1.sample_table1 and schema2.sample_table2 in the database sample_integration_db in your zero-ETL integration.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH TABLE schema1.sample_table1, schema2.sample_table2;

The following example refreshes all synced and failed tables within your zero-ETL integration.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH ALL tables;

The following example sets the refresh interval for zero-ETL integrations to 600 seconds..

ALTER DATABASE sample_integration_db INTEGRATION SET REFRESH_INTERVAL 600;

The following example refreshes all tables that are in the ErrorState in the schema sample_schema.

ALTER DATABASE sample_integration_db INTEGRATION REFRESH INERROR TABLES in SCHEMA sample_schema;