服务器管理

服务器设置和操作

和对外部世界可访问的任何服务器守护进程一样，我们也建议在一个独立的用户账户下运行UDB-TX。这个用户账户应该只拥有被该服务器管理的数据，并且应该不能被其他守护进程共享。特别是，建议UDB-TX不为此用户帐户所有，以确保受感染的服务器进程无法修改这些可执行文件。

UDB-TX 的预打包版本通常会在包安装期间自动创建一个合适的用户帐户。

以下的所有命令按照您安装的实际路径来

创建数据库集簇

  • 在你做任何事情之前，你必须在磁盘上初始化一个数据库存储区域。我们称之为一个数据库集簇（SQL标准使用的术语是目录集簇）。

  • 一个数据库集簇是被一个运行数据库服务器的单一实例所管理的多个数据库的集合。在初始化之后，一个数据库集簇将包含一个名为unvdb的数据库，它表示被功能、用户和第三方应用所使用的默认数据库。

  • 数据库服务器本身并不要求unvdb数据库存在。另一个在初始化过程中为每一个集簇创建的数据库被称为template1。顾名思义，它将被用于创建后续数据库的模板；它不应该被用于实际工作。

  • 在文件系统术语中，一个数据库集簇是一个单一目录，所有数据都将被存储在其中。我们称它为数据目录或数据区域。在哪里存储你的数据完全由你选择。没有默认的位置，不过/usr/local/unvdb/data 或 /var/lib/unvdb/data位置比较流行。 数据目录必须在使用前初始化，必须使用与UDB一起安装的程序initdb。

要手动初始化数据库集群，请运行 initdb 并使用 -D 选项指定所需的数据库集群文件系统位置，例如：

$ initdb -D /usr/local/unvdb/data

另一种替代方案是，你可以通过ud_ctl程序来运行initdb：

$ ud_ctl -D /usr/local/pgsql/data initdb

启动服务器

在任何人可以访问数据库前，你必须启动数据库服务器。 数据库服务器程序是unvdbsvr

如果您使用的是UDB-TX的预打包版本，那么几乎可以肯定的是，它包含了根据操作系统的约定将服务器作为后台任务运行的规定。 使用包的基础设施来启动服务器比自己弄清楚如何启动要简单得多。有关详细信息，请参阅包级文档。

手动启动服务器的基本方法是直接调用 unvdbsvr，使用 -D 选项指定数据目录的位置，例如：

$ unvdbsvr -D /usr/local/unvdb/data

这将把服务器放在前台运行。这个步骤同样必须以UDB-TX用户帐户登录来操作。如果没有-D选项，服务器将尝试使用环境变量UDDATA命名的目录。如果这个环境变量也没有提供则导致失败。

通常最好在后台启动unvdbsvr。要这样做，使用常用的 Unix shell 语法：

$ unvdbsvr -D /usr/local/unvdb/data >logfile 2>&1 &

另外，我们提供了包装器程序ud_ctl以简化一些任务。例如：

ud_ctl start -l logfile

将在后台启动服务器并且把输出放到指定的日志文件中。-D选项和unvdbsvr中的一样。ud_ctl还可以用于停止服务器。

通常，你会希望在计算机启动的时候启动数据库服务器。自动启动脚本是操作系统相关的。在 contrib/start-scripts 目录中有一些随 UDB-TX分发的示例脚本。安装将需要 root 权限。

关闭服务器

有几种关闭数据库服务器的方法。在后台，它们都简化为向主管 unvdbsvr 进程发送信号。

如果您使用的是 UDB-TX 的预打包版本，并且您使用其规定来启动服务器，那么您还应该使用其规定来停止服务器。 有关详细信息，请参阅包级文档。

直接管理服务器时，可以通过向 unvdbsvr 进程发送不同的信号来控制关闭的类型：

  • SIGTERM

    这是智能关闭模式。在接收SIGTERM后， 服务器将不允许新连接，但是会让现有的会话正常结束它们的工作。仅当所有的会话终止后它才关闭。 如果服务器处在线备份模式，它将等待直到在线备份模式不再被激活。当在线备份模式被激活时， 仍然允许新的连接，但是只能是超级用户的连接（这一例外允许超级用户连接来终止在线备份模式）。 如果服务器在恢复时请求智能关闭，恢复和流复制只有在所有正常会话都终止后才停止。

  • SIGINT

    这是快速关闭模式。服务器不再允许新的连接，并向所有现有服务器进程发送SIGTERM，让它们中断当前事务并立刻退出。然后服务器等待所有服务器进程退出并最终关闭。 如果服务处于在线备份模式，备份模式将被终止并致使备份无用。

  • SIGQUIT

    这是立即关闭模式。服务器将给所有子进程发送 SIGQUIT并且等待它们终止。如果有任何进程没有在 5 秒内终止，它们将被发送 SIGKILL。主服务器进程将在所有子进程退出之后立刻退出，而无需做普通的数据库关闭处理。这将导致在下一次启动时（通过重放 WAL 日志）恢复。只在紧急 时才推荐这种方式。

ud_ctl程序提供了一个发送这些信号关闭服务器的方便的接口。 另外，你在非 Windows 系统上可以用kill直接发送这些信号。可以用ps程序或者从数据目录的unvdbsvrmaster.pid文件中找到unvdbsvr进程的PID。例如，要做一次快速关闭：

$ kill -INT `head -1 /usr/local/unvdb/data/unvdbsvrmaster.pid`

服务器配置

参数设置

参数名称和值

所有参数名都是大小写不敏感的。每个参数都可以接受五种类型之一的值： 布尔、字符串、整数、 浮点数或枚举。该类型决定了设置该参数的语法：

  • 布尔: 值可以被写成 on, off, true, false, yes, no, 1, 0 （都是大小写不敏感的）或者这些值的任何无歧义前缀。

  • 字符串: 通常值被包括在单引号内，值内部的任何单引号都需要被双写。不过，如果值是一个简单数字或者 标识符，引号通常可以被省略。 (与 SQL 关键字匹配的值需要在某些上下文中引用。)

  • 数字（整数和浮点）: 数字参数可以规定为惯用的整数和浮点格式；如果参数为整数类型，则小数值四舍五入到最接近的整数。 证书参数还接受十六进制输入(以0x开头)和十进制输入(以0开头)，但是这些格式不能有小数。 不能使用千位分隔符。引号是不是必需的，除了十六进制输入。

  • 枚举:枚举类型的参数以与字符串参数相同的方式指定，但被限制到一组有限的值。 这样一个参数可用的值可以在pg_settings.enumvals 中找到。枚举参数值是大小写无关的。

设置这些参数最基本的方法是编辑unvdbsvr.conf文件， 它通常被保存在数据目录中（当数据库集簇目录被初始化时，一个默认的拷贝将会被安装在那里）。一个该文件的例子看起来是：

# This is a commentlog_connections = yeslog_destination = 'syslog'search_path = '"$user", public'shared_buffers = 128MB

每一行指定一个参数。名称和值之间的等号是可选的。空白是无意义的（除了在一个引号引用的参数值内）并且空行被忽略。井号（#）指示该行的剩余部分是一个注释。非简单标识符或者数字的参数值必须用单引号包围。

除unvdbsvr.conf之外，UDB-TX 数据目录还包含一个文件unvdbsvr.auto.conf， 它具有和unvdbsvr.conf相同的格式但是原自动编辑，而不是手工编辑。 这个文件保存了通过ALTER SYSTEM命令提供的设置。 每当unvdbsvr.conf被读取时这个文件会被自动读取，并且它的设置会以同样的方式生效。 unvdbsvr.auto.conf中的设置会覆盖unvdbsvr.conf中的设置。

或者我们可以使用SQL命令来对默认值进行修改，UDB-TX提供了三个SQL命令来建立配置默认值。 已经提到过的ALTER SYSTEM命令提供了一种改变全局默认值的从SQL可 访问的方法；它在功效上等效于编辑unvdbsvr.conf。此外，还有两个命令 可以针对每个数据库或者每个角色设置默认值：

  • ALTER DATABASE命令允许针对一个数据库覆盖其全局设置。

  • ALTER ROLE命令允许用用户指定的值来覆盖全局设置和数据库设置。

只有当开始一个新的数据库会话时，用ALTER DATABASE和 ALTER ROLE设置的值才会被应用。它们会覆盖从配置文件或服务器命令行 获得的值，并且作为该会话后续的默认值。注意某些设置在服务器启动后不能被更改，并且因此 不能被这些命令（或者下文列举的命令）设置。

一旦一个客户端连接到数据库，UDB-TX会提供两个额外的SQL命令（ 以及等效的函数）用以影响会话本地的配置设置：

  • SHOW命令允许察看所有参数的当前值。对应的函数是 current_setting(setting_name text)。

  • SET命令允许修改对于一个会话可以本地设置的参数的当前值， 它对其他会话没有影响。对应的函数是 set_config(setting_name, new_value, is_local)。

文件位置

除了已经提到过的unvdbsvr.conf文件之外，UDB-TX还使用另外两个手工编辑的配置文件，它们控制客户端认证。默认情况下，所有三个配置文件都存放在数据库集簇的数据目录中。

  • data_directory (string)

    指定用于数据存储的目录。这个选项只能在服务器启动时设置。

  • default_tablespace (string)

    指定默认表空间和索引目录。

  • temp_tablespaces (string)

    指定默认临时表空间目录。

  • config_file (string)

    指定主服务器配置文件（通常叫unvdbsvr.conf）。这个参数只能在unvdbsvr命令行上设置。

  • hba_file (string)

    指定基于主机认证配置文件（通常叫ud_hba.conf）。这个参数只能在服务器启动的时候设置。

  • ident_file (string)

    指定用于用户名称映射的配置文件（通常叫ud_ident.conf）。这个参数只能在服务器启动的时候设置。

  • external_pid_file (string)

    指定可被服务器创建的用于管理程序的额外进程 ID（PID）文件。这个参数只能在服务器启动的时候设置。

在默认安装中不会显式设置以上参数。相反，命令行参数-D或者环境变量PGDATA指定数据目录，并且上述配置文件都能在数据目录中找到。

连接和认证

连接设置：

listen_addresses (string)

指定服务器在哪些 TCP/IP 地址上监听客户端连接。值的形式是一个逗号分隔的主机名和/或数字 IP 地址列表。

port (integer)

服务器监听的 TCP 端口；默认是 5432 。请注意服务器会同一个端口号监听所有的 IP 地址。这个参数只能在服务器启动时设置。

max_connections (integer)

决定数据库的最大并发连接数。默认值通常是 100 个连接，但是如果内核设置不支持（initdb时决定），可能会比这个 数少。这个参数只能在服务器启动时设置。

当运行一个后备服务器时，你必须设置这个参数等于或大于主服务器上的参数。否则，后备服务器上可能无法允许查询。

superuser_reserved_connections (integer)

决定为UDB超级用户连接而保留的连接“槽”数。 同时活跃的并发连接最多[max_connections]个。

unix_socket_directories (string)

指定服务器用于监听来自客户端应用的连接的 Unix 域套接字目录

安全和认证

authentication_timeout (integer) ： 允许完成客户端认证的最长时间

password_encryption (enum)

当在CREATE ROLE或者ALTER ROLE中指定了口令时，这个参数决定用于加密该口令的算法。默认值是md5，它会将口令存为一个MD5哈希（on也会被接受，它是md5的别名）。将这个参数设置为scram-sha-256将使用SCRAM-SHA-256来加密口令。

客户端认证

hba文件

客户端认证是由一个配置文件（通常名为ud_hba.conf并被存放在数据库集簇目录中）控制（HBA表示基于主机的认证）。在initdb初始化数据目录时，它会安装一个默认的ud_hba.conf文件。不过我们也可以把认证配置文件放在其它地方。

每条记录指定一种连接类型、一个客户端 IP 地址范围（如果和连接类型相关）、一个数据库名、一个用户名以及对匹配这些参数的连接使用的认证方法。第一条匹配连接类型、客户端地址、连接请求的数据库和用户名的记录将被用于执行认证。这个过程没有“落空”或者“后备”的说法：如果选择了一条记录而且认证失败，那么将不再考虑后面的记录。如果没有匹配的记录，那么访问将被拒绝。

记录可以有多种格式：

local         database  user  auth-method [auth-options]
host          database  user  address     auth-method  [auth-options]
hostssl       database  user  address     auth-method  [auth-options]
hostnossl     database  user  address     auth-method  [auth-options]
hostgssenc    database  user  address     auth-method  [auth-options]
hostnogssenc  database  user  address     auth-method  [auth-options]
host          database  user  IP-address  IP-mask      auth-method  [auth-options]
hostssl       database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnossl     database  user  IP-address  IP-mask      auth-method  [auth-options]
hostgssenc    database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnogssenc  database  user  IP-address  IP-mask      auth-method  [auth-options]

各个域的含义如下：

  • local

    这条记录匹配企图使用 Unix 域套接字的连接。 如果没有这种类型的记录，就不允许 Unix 域套接字连接。

  • host

    这条记录匹配企图使用 TCP/IP 建立的连接。 host记录匹配SSL和非SSL的连接尝试， 此外还有GSSAPI 加密的或non-GSSAPI 加密的连接尝试。

  • hostssl

    这条记录匹配企图使用 TCP/IP 建立的连接，但必须是使用SSL加密的连接。要使用这个选项，编译服务器的时候必须打开SSL支持。

  • hostnossl

    这条记录的行为与hostssl相反；它只匹配那些在 TCP/IP上不使用SSL的连接企图。

  • hostgssenc

    这条记录匹配企图使用TCP/IP建立的连接，但仅当使用GSSAPI加密建立连接时。要使用这个选项，服务器必须具备GSSAPI支持。

  • hostnogssenc

    这个记录类型具有与hostgssenc相反的表现; 它仅匹配通过不使用GSSAPI加密的TCP/IP进行的连接尝试。

认证方式

UDB-TX为认证用户提供不同的方法:

  • Trust authentication

    简单的信任用户声称的身份。当trust认证被指定时，UDB-TX假设任何可以连接到服务器的人都被授权使用他们指定的任何数据库用户名（即使是超级用户）访问数据库。当然，在database和 user列中设置的限制仍然适用。只有当在操作系统层对进入服务器的连接有足够保护时，才应该使用这种方法。

  • Password authentication 需要用户提供密码。有基于scram-sha-256，md5，password等多种格式的口令认证

  • GSSAPI authentication 依靠GSSAPI兼容的安全库，常常用于访问认证服务器，例如Kerberos或微软活动目录服务器。

  • SSPI authentication 用windows规定的类似于GSSAPI的协议。

  • Ident authentication], 依靠客户机器上的 “Identification Protocol” (RFC 1413)服务，(在本地Unix-socket 连接,这个按对等认证处理)。

  • Peer authentication依靠操作系统工具来识别本地连接另一端的进程。这种方法不支持远程连接。

  • LDAP authentication], 依靠LDAP认证服务器.

  • RADIUS authentication, 依靠RADIUS认证服务器.

  • Certificate authentication], 需要SLL连接和通过SSL证书检查的认证用户。

  • PAM authentication, 依靠PAM库(Pluggable Authentication Modules，可插拔认证模块)。

  • BSD authentication, 依靠BSD认证框架(当前仅在OpenBSD上应用)。

对等身份验证通常适用于本地连接,信任认证在某些情况下也许是比较适合的。 密码认证是远程连接的常见选择。 所有其它的选项都需要某种外部安全基础架构(通常是认证服务器或颁发 SSL 证书的证书颁发机构。)，或用于某些特定平台。

数据库角色

数据库角色

数据库角色在一个数据库集簇安装范围内是全局的（而不是独立数据库内），可以使用CREATE/DROP ROLE name命令来对角色进行创建或删除。

为了方便，createuser和dropuser程序被提供作为这些 SQL 命令的包装器，它们可以从 shell 命令行调用：

createuser namedropuser name

ud_sql程序的\du元命令也可以用来列出现有角色。

为了引导数据库系统，一个刚刚被初始化好的系统总是包含一个预定义角色。这个角色总是一个“superuser”，并且默认情况下（除非在运行initdb时修改）它的名字和初始化数据库集簇的操作系统用户相同。习惯上，这个角色将被命名为unvdbsvr。为了创建更多角色，你首先必须以初始角色的身份连接。

每一个到数据库服务器的连接都是使用某个特定角色名建立的，并且这个角色决定发起连接的命令的初始访问权限。要使用一个特定数据库连接的角色名由客户端指示，该客户端以一种应用相关的风格发起连接请求。例如，ud_sql程序使用-U命令行选项来指定要以哪个角色连接。很多应用假定该名字默认是当前操作系统用户（包括createuser和ud_sql）。因此在角色和操作系统用户之间维护一个名字对应关系通常是很方便的。

一个给定客户端连接能够用来连接的数据库角色的集合由该客户端的认证设置决定。因为角色身份决定一个已连接客户端可用的权限集合，在设置一个多用户环境时要小心地配置权限。

角色属性

一个数据库角色可以有一些属性，它们定义角色的权限并且与客户端认证系统交互。

  • login privilege

    只有具有LOGIN属性的角色才能被用于一个数据库连接的初始角色名称。一个带有LOGIN属性的角色可以被认为和一个“数据库用户”相同。要创建一个带有登录权限的角色，使用两者之一：

    CREATE ROLE name LOGIN;CREATE USER name;

    （CREATE USER和CREATE ROLE等效，除了CREATE USER默认假定有LOGIN，而CREATE ROLE`不这样认为）。

  • superuser status

    一个数据库超级用户会绕开所有权限检查，除了登入的权利。这是一个危险的权限并且应该小心使用，最好用一个不是超级用户的角色来完成你的大部分工作。要创建一个新数据库超级用户，使用CREATE ROLE name SUPERUSER。你必须作为一个超级用户来完成这些。

  • database creation

    一个角色必须被显式给予权限才能创建数据库（除了超级用户，因为它们会绕开所有权限检查）。要创建这样一个角色，使用CREATE ROLE name CREATEDB。

  • role creation

    一个角色必须被显式给予权限才能创建更多角色（除了超级用户，因为它们会绕开所有权限检查）。要创建这样一个角色，使用CREATE ROLE name CREATEROLE。一个带有CREATEROLE权限的角色也可以修改和删除其他角色，还可以授予或回收角色中的成员关系。然而，要创建、修改、删除或修改一个超级用户角色的成员关系，需要以超级用户的身份操作。CREATEROLE不足以完成这一切。

  • initiating replication

    一个角色必须被显式给予权限才能发起流复制（除了超级用户，因为它们会绕开所有权限检查）。一个被用于流复制的角色必须也具有LOGIN权限。要创建这样一个角色，使用CREATE ROLE name REPLICATION LOGIN。

  • password

    只有当客户端认证方法要求用户在连接数据库时提供一个口令时，一个口令才有意义。password和md5认证方法使用口令。数据库口令与操作系统命令独立。在角色创建时指定一个口令：CREATE ROLE name PASSWORD 'string '。

在创建后可以用ALTER ROLE修改一个角色属性。

角色成员关系

把用户分组在一起来便于管理权限常常很方便：那样，权限可以被授予一整个组或从一整个组回收。在UDB-TX中通过创建一个表示组的角色来实现，并且然后将在该组角色中的成员关系授予给单独的用户角色。

要建立一个组角色，首先创建该角色：

CREATE ROLE name;

通常被用作一个组的角色不需要有LOGIN属性，不过如果你希望你也可以设置它。

一旦组角色存在，你可以使用GRANT和REVOKE命令增加和移除成员：

GRANT group_role TO role1, ... ;REVOKE group_role FROM role1, ... ;

你也可以为其他组角色授予成员关系（因为组角色和非组角色之间其实没有任何区别）。数据库将不会让你设置环状的成员关系。另外，不允许把一个角色中的成员关系授予给PUBLIC。

组角色的成员可以以两种方式使用角色的权限。第一，一个组的每一个成员可以显式地做SET ROLE来临时“成为”组角色。在这种状态中，数据库会话可以访问组角色而不是原始登录角色的权限，并且任何被创建的数据库对象被认为属于组角色而不是登录角色。第二，有INHERIT属性的成员角色自动地具有它们所属角色的权限，包括任何组角色继承得到的权限。作为一个例子，假设我们已经有：

CREATE ROLE joe LOGIN INHERIT;CREATE ROLE admin NOINHERIT;CREATE ROLE wheel NOINHERIT;GRANT admin TO joe;GRANT wheel TO admin;

在作为角色joe连接后，一个数据库会话将立即拥有直接授予给joe的权限，外加任何授予给admin的权限，因为joe“继承了” admin的权限。然而，授予给wheel的权限不可用，因为即使joe是wheel的一个间接成员，但是该成员关系是通过带NOINHERIT属性的admin得到的。在：

SET ROLE admin;

之后，该会话将只拥有授予给admin的权限，但是没有授予给joe的权限。在执行：

SET ROLE wheel;

之后，该会话将只拥有授予给wheel的权限，但是没有授予给joe或admin的权限。初始的权限状态可以使用下面命令之一恢复：

SET ROLE joe;SET ROLE NONE;RESET ROLE;

删除角色

由于角色可以拥有数据库对象并且能持有访问其他对象的特权，删除一个角色 常常并非一次DROP ROLE就能解决。任何被该用户所拥有 的对象必须首先被删除或者转移给其他拥有者，并且任何已被授予给该角色的 权限必须被收回。

对象的拥有关系可以使用ALTER命令一次转移出去，例如：

ALTER TABLE bobs_table OWNER TO alice;

此外，REASSIGN OWNED命令可以被用来把要被删除的 角色所拥有的所有对象的拥有关系转移给另一个角色。由于 REASSIGN OWNED不能访问其他数据库中的对象，有必要 在每一个包含该角色所拥有对象的数据库中运行该命令（注意第一个这样的 REASSIGN OWNED将更改任何在数据库间共享的该角色拥 有的对象的拥有关系，即数据库或者表空间）。

一旦任何有价值的对象已经被转移给新的拥有者，任何由被删除角色拥有的剩余对象 就可以用DROP OWNED命令删除。再次，由于这个命令不能 访问其他数据库中的对象， 有必要在每一个包含该角色所拥有对象的数据库中运行 该命令。还有，DROP OWNED将不会删除整个数据库或者表空间， 因此如果该角色拥有任何还没有被转移给新拥有者的数据库或者表空间，有必要手工 删除它们。

DROP OWNED也会注意移除为不属于目标角色的对象授予给目标 角色的任何特权。因为REASSIGN OWNED不会触碰这类对象，通 常有必要运行REASSIGN OWNED和 DROP OWNED（按照这个顺序！）以完全地移除要被删除对象的 从属物。

总之，移除曾经拥有过对象的角色的方法是：

REASSIGN OWNED BY doomed_role TO successor_role;DROP OWNED BY doomed_role;-- 在集簇中的每一个数据库中重复上述命令DROP ROLE doomed_role;

如果不是所有的拥有对象都被转移给了同一个后继拥有者，最好手工处理异常 然后执行上述步骤直到结束。

管理数据库

少量的对象，例如角色、数据库和表空间名，是在集群级别定义并存储在pg_global表空间之中的。 集群内部有多个数据库，相互之间彼此隔离，但可以访问集群级对象。 每个数据库内部都有多个模式，它们包含表和函数等对象。因此，完整的层级结构为:集群、数据库、模式、表(或一些其他类型的对象，如函数)。

当连接到数据库服务器时，客户端必须在它的连接请求中指定数据库名称。每个连接不可能访问多于一个数据库。 但是，客户端可以对同一个数据库打开多个连接，或可以打开不同的数据库。 数据库级别的安全有两个组成部分:访问控制，在连接级进行管理，还有授权控制，通过授权系统进行管理。 外部数据包装器,允许一个数据库中的对象作为其他数据库或集群中的对象的代理。 旧的dblink模块提供了类似的功能。默认情况下，所有用户可以使用所有连接方法连接所有的数据库。

如果一个UDB-TX服务器集群计划包含不相关的项目或用户，在很大程度上，彼此之间是不知道的，那么建议将它们放到单独的数据库中，并且调整相应的授权和访问控制。 如果项目或用户是相互关联的，因此应该能够互相使用彼此的资源，它们讲被放在同一个数据库中，但可能被放入相互独立的模式中; 这提供了具有名称空间隔离和授权控制的模块化结构。关

虽然可以在单个集群中创建多个数据库，但建议仔细考虑好处是否大于风险和限制。 特别是，共享WAL对备份和恢复选项的影响。从用户的角度来看，集群中的各个数据库是隔离的，但从数据库管理员的角度来看，它们是紧密绑定的。

创建数据库

数据库是使用CREATE DATABASE，并且用DROP DATABASE命令删除。要确定现有数据库的集合，可以检查系统目录pg_database，例如

SELECT datname FROM pg_database;

ud_sql序的\l元命令和-l命令行选项也可以用来列出已有的数据库。

有时候你想为其他人创建一个数据库，并且使其成为新数据库的拥有者， 这样他们就可以自己配置和管理这个数据库。要实现这个目标，使用下列命令之一： 用于 SQL 环境的

CREATE DATABASE dbname OWNER rolename;

或者用于 shell 的

createdb -O rolename dbname

只有超级用户才被允许为其他人（即为一个你不是其成员的角色）创建一个数据库。

模板数据库

CREATE DATABASE实际上通过拷贝一个已有数据库进行工作。默认情况下，它拷贝名为template1的标准系统数据库。所以该数据库是创建新数据库的“模板”。 如果你为template1数据库增加对象，这些对象将被拷贝到后续创建的用户数据库中。 这种行为允许对数据库中标准对象集合的站点本地修改。例如，如果你把过程语言PL/Perl安装到 template1中，那么你在创建用户数据库后不需要额外的操作就可以使用该语言。

系统里还有名为template0的第二个标准系统数据库。 这个数据库包含和template1初始内容一样的数据，也就是说，只包含你的UDB-TX版本预定义的标准对象。 在数据库集簇被初始化之后，不应该对template0做任何修改。 通过指示CREATE DATABASE使用template0取代template1进行拷贝， 你可以创建一个“原始的”用户数据库（其中不存在用户定义的对象，并且系统对象没有被改变），它不会包含任何template1中的站点本地附加物。 这一点在恢复一个pg_dump转储时非常方便：转储脚本应该在一个原始的数据库中恢复以确保我们重建被转储数据库的正确内容，而不和任何现在可能已经被加入到template1中的附加物相冲突。

另一个从template0而不是template1复制的常见原因是， 可以在复制template0时指定新的编码和区域设置，而一个template1的副本必须使用和它相同的设置。这是因为的template1可能包含编码相关或区域相关的数据，而template0中没有。

要通过拷贝template0来创建一个数据库，使用：SQL 环境中的

CREATE DATABASE dbname TEMPLATE template0;

或者 shell 中的

createdb -T template0 dbname

可以创建额外的模板数据库，并且实际上可以通过将集簇中任意数据库指定为CREATE DATABASE的模板来从该数据库拷贝。不过，我们必需明白，这个功能并不是设计作为一般性的“COPY DATABASE”功能。主要的限制是当源数据库被拷贝时，不能有其他会话连接到它。如果在CREATE DATABASE开始时存在任何其它连接，那么该命令将会失败。在拷贝操作期间，到源数据库的新连接将被阻止。

对于每一个数据库在pg_database中存在两个有用的标志： datistemplate和datallowconn列。datistemplate可以被设置来指示该数据库是不是要作为CREATE DATABASE的模板。如果设置了这个标志，那么该数据库可以被任何有 CREATEDB权限的用户克隆；如果没有被设置，那么只有超级用户和该数据库的拥有者可以克隆它。如果datallowconn为假，那么将不允许与该数据库建立任何新的连接（但已有的会话不会因为把该标志设置为假而被中止）。template0通常被标记为datallowconn = false来阻止对它的修改。template0和template1通常总是被标记为datistemplate = true。

数据库配置

回顾一下1.4.2，UDB-TX服务器提供了大量的运行时配置变量。你可以为其中的许多设置数据库相关的默认值。

例如，如果由于某种原因，你想禁用指定数据库上的GEQO优化器，正常情况下你不得不对 所有数据库禁用它，或者确保每个连接的客户端小心地发出了SET geqo TO off。要令这个设置在一个特定数据库中成为默认值，你可以执行下面的命令：

ALTER DATABASE mydb SET geqo TO off;

这样将保存该设置（但不是立即设置它）。在后续建立的到该数据库的连接中它将表现得像在会话开始后马上调用SET geqo TO off;。注意用户仍然可以在该会话中更改这个设置，它只是默认值。要撤消这样的设置，使用ALTER DATABASE *dbname* RESET *varname*。

销毁一个数据库

数据库用DROP DATABASE命令删除：

DROP DATABASE name;

只有数据库的拥有者或者超级用户才可以删除数据库。删除数据库会移除其中包括的所有对象。数据库的删除不能被撤销。

你不能在与目标数据库连接时执行DROP DATABASE命令。不过，你可以连接到任何其它数据库，包括 template1数据库。template1也是你删除一个给定集簇中最后一个用户数据库的唯一选项。

为了方便，有一个在 shell 程序可以删除数据库，dropdb：

dropdb dbname

（和createdb不同，删除当前用户名的数据库不是默认动作）

表空间

UDB-TX中的表空间允许数据库管理员在文件系统中定义用来存放表示数据库对象的文件的位置。一旦被创建，表空间就可以在创建数据库对象时通过名称引用。

通过使用表空间，管理员可以控制一个UDB-TX安装的磁盘布局。 这么做至少有两个用处。首先，如果初始化集簇所在的分区或者卷用光了空间，而又不能在逻辑上扩展或者做别的什么操作，那么表空间可以被创建在一个不同的分区上，直到系统可以被重新配置。

其次，表空间允许管理员根据数据库对象的使用模式来优化性能。例如，一个很频繁使用的索引可以被放在非常快并且非常可靠的磁盘上，如一种非常贵的固态设备。同时，一个很少使用的或者对性能要求不高的存储归档数据的表可以存储在一个便宜但比较慢的磁盘系统上。

要定义一个表空间，使用CREATE TABLESPACE命令，例如：

CREATE TABLESPACE fastspace LOCATION '/ssd1/unvdbsvr/data';

这个位置必须是一个已有的空目录，并且属于UDB-TX操作系统用户。 所有后续在该表空间中创建的对象都将被存放在这个目录下的文件中。该位置不能放在可移动 或者瞬时存储上，因为如果表空间丢失会导致集簇无法工作。

表空间的创建本身必须作为一个数据库超级用户完成，但在创建完之后之后你可以允许普通数据库用户来使用它。要这样做，给数据库普通用户授予表空间上的CREATE权限。

表、索引和整个数据库都可以被分配到特定的表空间。想这么做，在给定表空间上有 CREATE权限的用户必须把表空间的名字以一个参数的形式传递给相关的命令。例如，下面的命令在表空间space1中创建一个表：

CREATE TABLE foo(i int) TABLESPACE space1;

另外，还可以使用default_tablespace参数：

SET default_tablespace = space1;CREATE TABLE foo(i int);

当default_tablespace被设置为非空字符串，那么它就为没有显式TABLESPACE子句的CREATE TABLE和CREATE INDEX命令提供一个隐式TABLESPACE子句。

还有一个temp_tablespaces参数，它决定临时表和索引的位置，以及用于大数据集排序等目的的临时文件的位置。 这可以是一个表空间名的列表，而不是只有一个。因此，与临时对象有关的负载可以散布在多个表空间上。每次要创建一个临时对象时，将从列表中随机取一个成员来存放它。

与一个数据库相关联的表空间用来存储该数据库的系统目录。此外，如果没有给出TABLESPACE子句并且没有在default_tablespace或temp_tablespaces（如适用）中指定其他选择，它还是在该数据库中创建的表、索引和临时文件的默认表空间。如果一个数据库被创建时没有指定表空间，它会使用其模板数据库相同的表空间。

当初始化数据库集簇时，会自动创建两个表空间。pg_global表空间被用于共享系统目录。pg_default表空间是template1和template0数据库的默认表空间（并且，因此也将是所有其他数据库的默认表空间，除非被一个CREATE DATABASE中的TABLESPACE子句覆盖）。

表空间一旦被创建，就可以被任何数据库使用，前提是请求的用户具有足够的权限。这也意味着，一个表空间只有在所有使用它的数据库中所有对象都被删除掉之后才可以被删掉。

要删除一个空的表空间，使用DROP TABLESPACE系统目录，例如

SELECT spcname FROM pg_tablespace;

ud_sql程序的\db元命令也可以用来列出现有的表空间。

服务器应用

用户在shell命令行中可以命令+选项的方式对命令功能进行选择和配置。

在介绍具体命令之前，先介绍几乎存在于每个命令中的通用选项：

-V --version

打印命令版本并退出。

-? --help

显示相关命令行参数的帮助并退出。

--debug

打印冗长的调试输出

-P --progress

启用进度报告。在从源集簇拷贝数据时，打开这个选项将会发送一个近似的进度报告。

initdb

initdb-创建新的UDB-TX数据库

一个数据库集簇的创建包括创建存放数据库数据的目录、生成共享目录表（属于整个集簇而不是任何特定数据库的表）并且创建template0、template1和test数据库

使用方法：initdb [option…] [ --udb_data | -D ] directory

选项：

-D directory --udb_data=directory  #这个选项指定数据库集簇应该存放的目录。这是`initdb`要求的唯一信息-E encoding --encoding=encoding  #选择模板数据库的编码。默认为SQL_ASCII-e directory --encrypt-algorithm=algorithm  #这个选项指定数据库集簇使用的透明加密算法，默认为SM4（可选RC4）-k --data-checksums #在数据页面上使用校验码来帮助检测 I/O 系统造成的损坏。启用校验码将会引起显著的性能惩罚。如果被设置，在所有数据库中会为所有对象计算校验码。 所有的检验故障均会在sys_stat_database视图中被报告

例子

启动数据库并指定目录

initdb -D /usr/local/unvdb/data

ud_archivecleanup

ud_archivecleanup-清理UDB-TX WAL 归档文件

ud_archivecleanup被设计用作 archive_cleanup_command在作为后备服务器运行时来清理 WAL 文件归档。 ud_archivecleanup也可以被用作一个单独的程序来清理 WAL 文件归档。

使用方法： ud_archivecleanup [option…] archivelocation oldestkeptwalfile

选项：

-d  #在`stderr`上打印很多调试日志输出。-n  #在`stdout`上打印将被移除的文件的名字（执行一次演习）。-x extension #提供一个扩展名，在决定所有的文件是否应该被删除之前，将从文件名中剥离这个扩展名

例子：

在 Linux 或者 Unix 系统上，你可能会用：

archive_cleanup_command = 'ud_archivecleanup -d /mnt/standby/archive %r 2>>cleanup.log'

其中归档目录位于后备服务器上，这样archive_command通过 NFS 来访问它，但是文件对于后备服务器来说是本地的。这将会

  • 在cleanup.log中产生调试输出

  • 从归档目录中移除不再需要的文件

ud_checksums

ud_checksums — 启用、禁用或检查UDB-TX数据库集簇中的数据校验和

在验证校验和时，如果没有校验和错误，则退出状态为零;如果检测到至少一个校验和失败，则退出状态为非零。启用或禁用校验和时，如果操作失败，则退出状态为非零。

在验证校验和时，将扫描集群中的每个文件。启用校验和时，将重写集群中的每个文件。禁用校验和只更新文件ud_control。

使用方法：ud_checksums [option…] [[ -D | --udb_data ] datadir]

选项：

-D directory --udbase_data=directory #指定存储数据库集群的目录-b --bad-block  #统计单个文件中未通过校验的块（包括页头错误、校验和错误和忙碌块）计数。仅在检查模式下可用。-c --check  #检查校验和。如果没有指定其他内容，这就是默认模式。-d --disable #禁用校验和。-e --enable  #启用校验和。

ud_controldata

ud_controldata — 显示一个UDB-TX数据库集簇的控制信息

ud_controldata打印在initdb期间初始化的信息，例如目录版本。它也显示关于预写式日志和检查点处理的信息

使用方法：ud_controldata [option] [[ --ud_data | -D ] datadir]

ud_ctl

ud_ctl — 初始化、启动、停止或控制一个UDB-TX服务器

ud_ctl是一个用于初始化UDB-TX数据库集簇，启动、停止或重启UDB-TX数据库服务器，或者显示一个正在运行服务器的状态的工具。尽管服务器可以被手工启动，ud_ctl包装了重定向日志输出以及正确地从终端和进程组脱离等任务.

示例：

ud_ctl start  #启动服务器ud_ctl -o "-F -p 5433" start #要使用端口 5433 启动服务器并且运行时不使用fsyncud_ctl stop  #停止使用服务器ud_ctl stop -m smart  #-m选项允许关闭ud_ctl restart  #重启服务器ud_ctl status   #显示服务器状态

ud_resetwal

ud_resetwal — 重置一个UDB-TX数据库集簇的预写式日志以及其他控制信息

ud_resetwal会清除预写式日志（WAL）并且有选择地重置存储在ud_control文件中的一些其他控制信息。如果这些文件已经被损坏，某些时候就需要这个功能。当服务器由于这样的损坏而无法启动时，这只应该被用作最后的手段。

使用方法：ud_resetwal [ --force | -f ] [ --dry-run | -n ] [option…] [ --kingbase_data | -D ] datadir

选项：

-f` `--force  #即使`ud_resetwal`无法从`ud_control`中确定有效的数据（如前面所解释的），也强迫`ud_resetwal`继续运行。
-n` `--dry-run  #`-n`/`--dry-run`选项指示`ud_resetwal`打印从`ud_control`重构出来的值以及要被改变的值，然后不修改任何东西退出。这主要是一个调试工具，但是可以用来在允许`ud    _resetwal`真正执行下去之前进行完整性检查。

ud_rewind

ud_rewind —把一个UDB-TX数据目录与另一个从该目录中复制出来的数据目录同步

ud_rewind是用于在集簇的时间线分叉以后，同步一个 UDB-TX 集簇和同一集簇的另一份拷贝的工具。一种典型的场景是在失效后让一个旧的主服务器重新上线，同时有一个后备机跟随着新的主机。

使用方法：ud_rewind [option…] { -D | --target-udb_data } directory { --source-udb_data=directory | --source-server=connstr }

选项：

-D directory` `--target-udbase_data=directory

这个选项指定要与源数据目录同步的目标数据目录。在运行sys_rewind之前目标服务器必须被干净地关闭。

--source-kingbase_data=directory

指定要和目标服务器同步的源服务器的数据目录的文件系统路径。这个选项要求源服务器必须被干净地关闭。

--source-server=connstr

指定一个 libkci 连接串用于连接要与目标服务器同步的源 KingbaseES服务器。 该连接必须是正常的(非复制的)连接

ud_test_fsync

ud_test_fsync — 为UDB-TX判断最快的 wal_sync_method

ud_test_fsync是想告诉你在特定的系统上，哪一种 wal_sync_method 最快，还可以在发生认定的 I/O 问题时提供诊断信息

使用方法 ： ud_test_fsync [option…]

选项

-f --filename

指定要写入测试数据到其中的文件名。这个文件必须位于和 sys_wal目录所在或者将被放置的同一个文件系统中（ sys_wal包含WAL文件）。默认是当前 目录中的ud_test_fsync.out。

-s --secs-per-test

指定每次测试的秒数。每个测试的时间越长，测试的精度就越高

ud_test_timing

ud_test_timing — 度量计时开销

ud_test_timing是一种度量在你的系统上计时开销以及确认系统时间绝不会回退的工具

使用方法： ud_test_timing [option…]

选项：

-d duration` `--duration=duration

指定测试的持续时间，以秒计。更长的持续时间会给出更好一些的精确度，并且更可能发现系统时钟回退的问题。默认的测试持续时间是 3 秒

ud_upgrade — 升级UDB-TX服务器实例

ud_upgrade允许将存储在UDB数据文件中的数据升级到一个更高的UDB-TX主版本，而无需进行主版本升级（例如从 udb22.3-udb22.4）通常所需的数据转储/重载。

使用方法：ud_upgrade -b oldbindir -B newbindir -d oldconfigdir -D newconfigdir [option…]

选项：

-b bindir --old-bindir=bindir  #旧的 UDB 可执行文件目录-B bindir --new-bindir=bindir  #新的 UDB 可执行文件目录-c --check  #只检查集簇，不更改任何数据-d datadir --old-datadir=datadir #旧的集簇数据目录；-D datadir --new-datadir=datadir #新的集簇数据目录；-j --jobs   #要同时使用的进程或线程数-k --link  #使用硬链接来代替将文件拷贝到新集簇

ud_waldump

ud_waldump — 以人类可读的形式显示一个UDB-TX数据库集簇的预写式日志

ud_waldump显示预写式日志（WAL），它主要用于调试或者教育目的。

这个工具只能由安装该服务器的用户运行，因为它要求对数据目录的只读访问

使用方法：ud_waldump [option…] [startseg [endseg]]

  • startseg

    从指定的日志段文件开始读取。这也隐含地决定了要搜索文件的路径以及要使用的时间线。

  • endseg

    在读取指定的日志段文件后停止。

-b --bkp-details    #输出有关备份块的细节--block-size=size   #设置表块大小，以千字节为单位。默认的尺寸为8千字节。该值必须是2的整数次幂，并且在1到32之间。这个选项需要与initdb设置的--block-size大小保持一致，否则会影响相关的计算结果。-e end --end=end    #在指定的WAL位置停止读取，而不是一直读取到日志流的末尾。-f --follow         #在到达可用 WAL 的末尾之后，保持每秒轮询一次是否有新的 WAL 出现。-n limit --limit=limit   #显示指定数量的记录，然后停止。

unvdbsvr

unvdbsvr — UDB-TX数据库服务器

unvdbsvr是UDB-TX数据库服务器。一个客户端应用为了能访问一个数据库，它会（通过一个网络或者本地）连接到一个运行着的unvdbsvr实例。该unvdbsvr实例接着会开始一个独立的服务器进程来处理该连接。

一个unvdbsvr实例总是管理正好一个数据库集簇的数据。一个数据库集簇是一个数据库的集合，它们被存储在一个共同的文件系统位置（“数据区”）上。 一个系统上可以同时运行多个unvdbsvr实例，只要它们使用不同的数据区和不同的通信端口（见下文）。unvdbsvr启动时需要知道数据区的位置，该位置必须通过-D选项或PGDATA环境变量指定，对此是没有默认值的。通常，-D或PGDATA会直接指向由initdb创建的数据区目录

默认情况下，unvdbsvr会在前台启动并将日志消息打印到标准错误流。但在实际应用中，unvdbsvr应当作为一个后台进程启动，而且多数是在系统启动时自动启动。

使用大纲：unvdbsvr [选项…]

选项：

-B nbuffers

设置被服务器进程使用的共享内存缓冲区数量。这个参数的默认值是initdb自动选择的。指定这个选项等效于设置shared_buffers配置参数。

-c name=value

设置一个命名的运行时参数。

-C name

打印命名运行时参数的值，并且退出（详见上面的-c选项）。这可以被用在一个运行服务器上，并且从unvdbsvr.conf中返回值，这些值可能被在这次调用中的任何参数修改过。它并不反映集簇启动时提供的参数。

这个选项用于与一个服务器实例交互的其他程序来查询配置参数值，例如ud_ctl。面向用户的应用应该使用SHOW或者pg_settings视图。

-d debug-level

设置调试级别。数值设置得越高，写到服务器日志的调试输出就越多。取值范围是从 1 到 5。还可以针对某个特定会话使用-d 0来阻止父unvdbsvr进程的服务器日志级别被传播到这个会话。

-D datadir

指定数据库配置文件的文件系统位置。