数据库(EnterpriseDb)
Aug 12

MySQL是一个易于使用的数据库,同时有许多开源的Web应用程序都是直接在它上面开发的。

  另外一种主要的开源数据库是PostgreSQL,相比MySQL,PostgreSQL能提供更加安全、更加可靠、数据也更加完整的服务。

  但是,这同样也有一定的缺陷。PostgreSQL对于设置和使用的要求比较高,它利用的是特殊权限、底层操作系统的安全性以及数据库内提供的角色(roles)和特权。如果你对这些东西不够了解的话,会使得PostgreSQL的使用变得困难。但一旦你掌握了它们,你就可以像使用MySQL一样很容易的使用PostgreSQL。

  与MySQL相类似,PostgreSQL的工作基于这样一种原则,即特定的用户有特定的数据访问权限。在PostgreSQL里,这些被称之为“角色(roles)”,通过采用CREATE ROLE, ALTER ROLE, and DROP ROLE这些语句可以创建和管理它们。和MySQL不同的是,这些“角色”可以映射和绑定到系统的用户,这就意味着它可以利用不同形式的体系认证:ident server authentication、LDAP server authentication、PAM和Kerberos。而对于本地连接,你也可以通过使用这些文件体系的权限来确定谁可以访问Unix域套接字,以及它的位置。

  PostgreSQL中,访问控制的方法是使用pg_hba.conf。对于身份识别,也可采用pg_ident.conf;这可以用于将数据库用户映射到本地用户。假如用户“joe”是允许访问的PostgreSQL用户数据库“joe”和“电子商务”。pg_hba.conf文件包含如下:

  而pg_ident.conf可能会包括:

  这就允许系统用户“joe”作为“joe”或者“ecommerce.”来访问数据库。它也允许系统“postgres”用户以“joe”的身份连接到数据库。同时强化对于名字为“esite”识别方法的映射类型,如在pg_ident.conf中所定义的那样。这就意味着在本地类型(Unix域套接字)和本地TCP/IP地址(127.0.0.1)中,只有joe和postgres能够连接到数据库。没有其他的用户有权来访问它。

  这种识别方法是一种很好的方式,用于控制哪一个本地用户可以连接到哪一个数据库。这种方法只对本地主机(TCP/IP 或者UNIX 域套接字)的连接起作用,而对于远程控制是无效的。

  虽然对于那些习惯使用MySQL的人来说这看起来似乎有点混乱,但目前对具有这种认证精度的数据库的需求确是实实在在的。MySQL只支持基于登录证书的身份验证,而这些证书只由数据库本身进行储存和管理。

  另一方面,PostgreSQL不仅允许这种采用密码机制的身份验证,而且允许采用无密码的身份验证。这些验证机制包括像讨论的认证机制、PAM(其中规定了许多有意思的验证方案)以及LDAP 和 Kerberos。Kerberos是一种在MySQL使用多年的方式(事实上,出现于2004年11月的MySQL错误#6733就需要得到Kerberos的支持)。许多公司的偏好Kerberos和LDAP密码存储目录,这就使得PostgreSQL成为了一个引人关注的数据库。

  还有其他很多特色使得PostgreSQL更加适用于企业。虽然安全性很重要,但除此之外PostgreSQL对于数据完整性、访问控制、ACID规则以及其他一些重要方面的关注和支持,都很好的解释了在众多的数据库管理者中为什么PostgreSQL享有如此高的赞誉。

详见enterprisedb 官方文档

Aug 10

超级用户:类似于其他系统的sa、root、sysdba

  • initdb.exe 初始化是建立的第一个superuser 的名字 和 执行initdb.exe是的os帐号相同
  • 第一个superuser的oid=10
  • superuser是不受postgresq的对象权限系统控制的,可以在系统里做任何事情!危险!!

 

对象的所有者owner:很特殊的角色

  • 对象的权限系统是对象上权限的有限集合,但有些权限是无法grant、revoke的,这就是owner所特性的:owner用户很多普通用户不具备的权利
  • owner权限可以有superuser来转移

 

postgresql自8.1后不再区分用户、组了。统统称之为角色role

  • role是和数据库无关的
  • role就是权限的集合
  • role可以互相交叉、继承、被赋于对象权限

 

特殊的public角色 :属于所有role的公共角色

  • create role role_name [login createdb super iherit ...]
  • create user role_name  等于 create role role_name login
  • drop role
  • grant {all| priviliges} on object to role_name
  • revoke {all| priviliges} on object from role_name

From:http://www.cnblogs.com/jinzhenshui/archive/2009/06/29/1513074.html

 

角色:
sql>create role role1 noinherit password '1234';
sql>GRANT CONNECT ON DATABASE testljs TO role1;
sql>grant connect on schema testljs  to role1;

用户:
sql>create role user1 login noinherit password '1234';
sql>grant connect on database testljs  to role1;
sql>grant connect on schema testljs  to role1; -- schema usage
sql>revoke connect on database  testljs from user1;  --
sql>connect user1/1234@localhost:5444/testljs ; --ok
sql>revoke connect  from user1; 
sql>connect user1/1234@localhost:5444/testljs ; --faile

 

sql>grant  connect to role1; -- ok 可以连接
GRANT group1 TO user1;

 

sql>create role role2 noinherit password '1234';
sql>create role user2 login noinherit password '1234';
sql>revoke connect from user2;
sql>grant role2 to user2;
sql>revoke connect from role2;
sql>grant  connect to role2;
sql>revoke connect from role1;
sql>grant role2 to role1;

Jul 30

支持的平台

PostgreSQL能够运行在什么版本的Windows上?

PostgreSQL支持Windows 2000, XP 和 2003。在执笔之时,它仅在32位的windows系统中测试过。

听说还支持NT4,是真的么?

虽然没有官方正式支持,PostgreSQL可以在Windows NT4上运行,但会伴随一些小问题:

  • 安装程序工作不正常,故您可能需要手工从源代码编译以及安装。
  • PostgreSQL使用了一个名为'reparse points'的NTFS特性来实现表空间(tablespaces)。Reparse points在NT4上不可用,应此,无法使用表空间。
  • Windows NT4标准组件未包括'runas.exe',所以从管理帐户启动PostgreSQL服务器将遇到困难。

此外还要注意的是,NT4上仅进行过非常有限的测试。

Windows 95/98/ME怎样?

PostgreSQL需要一些这些平台没有提供的功能,所以不能在这些版本上运行。如果您必须在这些平台上运行,可以参考Cygwin移植版本 ,它提供对于9x平台的基本支持。

有为Windows准备的64位版本么?

截至此时,简单来说,没有 。当然,32位编译的PostgreSQL能在64位的平台上工作,而且事实上有很多理由让我们相信,相对其他软件而言,64位的版本对PostgreSQL来说并不是非常重要。

  • PostgreSQL依赖于操作系统来完成大部分的数据缓存。由于32位进程的主要限制是所能访问的内存空间,一个依靠这样的数据库引擎完成所有缓存的系统将无法使用系统的所有内存,比如16GB时。而对于PostgreSQL,很多缓存工作都留给了可以使用完全内存空间的操作系统。
  • PostgreSQL使用了多进程的架构,而非多线程。在一个多线程的数据库服务器上,所有连接的客户端共享同一块内存空间,于是受一个可访问内存区域总量的限制。而使用PostgreSQL时,每个数据库后端(必要时)可以轻易地配给1Gb以上的内存,而不会导致共享内存的耗尽,这点更减小了对于64位的潜在需求。
  • 在某些实际情况下,32位对于降低内存消耗更有帮助。64位系统中,每个指针和整数数据都要占用成倍于32位系统的内存空间。这个额外开销可能是显著的,且很可能是不必要。

安装

在Windows上安装PostgreSQL,我需要些什么?

在Windows上安装PostgreSQL最简单的方式是从PostgreSQL FTP站点以及镜像上取得Windows安装包。该安装包将安装一份预编译的PostgreSQL、pgAdmin(一个图形化的管理工具)以及一些精选的贡献辅助模块,用以提供额外的专业化功能;此外还能选择安装所需的过程语言。

您需要一台运行Windows 2000、XP或2003,并安装了Windows Installer服务的计算机以运行该安装程序。安装程序将按需创建一个服务帐号,并初始化数据库簇。

安装程序可以从这里 取得。

从源代码编译PostgreSQL,我需要些什么?

位于http://www.postgresql.org/files/documentation/faqs/FAQ_MINGW.html 的 Windows编译常见问题和解答包含了在Windows系统中编译PostgreSQL源代码的全部细节。


 

为什么我需要一个非管理员帐号来运行PostgreSQL?

当一个骇客通过软件的缺陷获得了侵入一台计算机的入口时,她获得的是这个程序运行所用用户帐号的对应权限。由于我们无法预知PostgreSQL中是否还存在这样的bug,所以我们强制使用一个非管理员的服务帐号来最小化潜在的骇客利用此类漏洞对系统进行破坏的风险。这样的设置已是Unix界的惯例做法,同时在Windows世界中,Microsoft以及其他供应商也开始采用这样的做法来改进他们系统的安全性。补充: 自PostgreSQL 8.2发行后,从管理帐号启动变得可行。PostgreSQL 8.2及后续版本会在启动后不可撤销地放弃管理权限,从而保证了当极端不可能事件,当PostgreSQL受到入侵时,系统的安全性。

我能将PostgreSQL安装在一个FAT分区上么?

PostgreSQL的第一优先是数据的完整性。FAT与FAT32文件系统没有提供保障完整的可靠性。此外,FAT安全机制的缺失使防止原始数据被非发篡改变得不可能。最后,PostgreSQL使用了名为'reparse points'的功能来实现数据表空间。该功能在FAT分区上不可用。 NTFS是一个日志型文件系统,提供了更好的可靠性和崩溃保护。此外,它具有全面的访问控制系统。以及提供了PostgreSQL所需的reparse points功能。有鉴于此,PostgreSQL安装包将不会初始化位于NTFS以外文件系统上的数据库簇。服务器程序以及其他工具可以安装于任何类型分区中。当然,考虑到在一些系统,比如开发者所用的PC上,FAT可能是唯一的选择。在这种情况下,您可以像通常那样使用安装程序,但是跳过初始化数据库簇的步骤。当安装结束后,在FAT分区中手工运行'initdb.exe'。当然安全性和可靠性将受到威胁,任何创建表空间的操作也会失败。

PostgreSQL需要怎样的文件系统权限?

PostgreSQL服务帐号需要位于服务所在目录路径上所有目录的读取 权限。它 需要对数据目录具有写入 权限。特别是对于二进制文件作在的目录,它不应当 被赋予读取 以外的任何权限。(安装目录中所有子目录的权限都会由安装程序自动设置,所以除非您进行过改动,不然不会遇到问题)。 PostgreSQL也需要能读取 系统的动态链接DLL文件,比如kernel32.dll、user32.dll等等,这些权限默认都已给予。还需要能是用CMD.EXE,在某些场合,可能给系统策略所禁用,需要打开。如果您在多用户系统中运行PostgreSQL,则应当去除所有非管理用户对于PostgreSQL目录的权限许可。没有其他用户需要 文件系统权限来访问数据库——所有的通讯都是通过libpg连接来实现的。文件的直接访问权限可能导致资料外泄或系统不稳定!

为什么我不能选择Unicode作为编码方式?

注意! 从PostgreSQL 8.1开始,能全面支持Windows的(UTF8) UNICODE 编码方式。该条目描述的信息仅对8.0版有效。

在PostgreSQL中,"UNICODE" 意味着 "UTF8"。 Windows无法正确支持UTF8,所以在8.0版中不可用。安装程序将允许您选择您的Windows以及PostgreSQL服务器同时 支持的编码方式。

Aleksander Kmetec在pgsql-hackers邮件列表的一次发言解释了Unicode问题:

由于Postgres的一些串处理相关函数依赖于操作系统,操作系统必须支持数据库所使用的编码方式。不幸的是,Windows不支持部分PG能使用的服务器端编码。

如果上面的段落不好理解,这里是个小例子: 对于一个UNICODE数据库(实际上是UTF8),在运行initdb时,你必须使用兼容的区域设置(locale);就我的情况来说,我用是"sl_SI.utf8"(Linux)或"Slovenian_Slovenia.65001"(Windows)。

65001是Windows的utf8编码页,只是他不是一个真正有效的编码页。 出自 http://www.sharmahd.com/tm/codepages.html 的文档(不幸原地址已失效)指出:

"65000 (UTF-7) 与 65001 (UTF-8) 实乃伪编码页,没有响应的NLS文件对应。这些编码页ID只能使用于 WideCharToMultiByte( ) 与 MultiByteToWideChar( ) API调用。"

这意味着UPPER()、 LOWER() 与 ORDER BY 在unicode的数据库中将会工作不正常。目前为止,哪怕想使用65001编码的区域设置去运行initdb都是不可能的。在对initdb稍作修改后,我得以将 LC_COLLATE 设置为 Slovenian_Slovenia.65001 ,但是排序结果依然混乱,正验证了上面的引用。

经过一番检查后,我得出了一个PG能支持,但未在任何地方提到能被Windows支持的编码列表:

*UTF8
*EUC_CN
*EUC_TW
*LATIN6 (ISO 8859-10/ECMA 144)
*LATIN7 (ISO 8859-13)
*LATIN8 (ISO 8859-14)
*LATIN10 (ISO 8859-16/ASRO SR 14111)

我安装的时候没有使用英语,但怎么所有的消息都是英文?!

安装过程中的语言选择仅是选择安装程序所使用的语言。要更改安装产品中消息的语言,请确保您安装了区域语言支持(Natural language support) 功能组件。然后编辑安装的 postgresql.conf 配置文件,修改其中的lc_messages 参数值为您需要的语言。

常见安装错误

PostgreSQL 与/或 安装程序在启动时崩溃,启动失败或在启动时挂起

显然最常见的解释是,防病毒软件或者防火墙作祟。如果您在系统中安装了任何防火墙软件,请试图要么将其禁用,或将其卸载。如果您安装了任何防病毒软件,对于PostgreSQL所将要使用的目录您必须 将其禁用。如果这样依然不能解决问题,可能需要将其从系统中彻底卸载。

有报道针对 nod32 反病毒产品的特殊问题。如果您正使用该产品,请将"postmaster.exe"加入排除进程名单(位于高级选项中),可以修复此问题。也有关于 McAfee 和 Panda 反病毒软件与 NetLimiter 网络监控程序的特殊问题报告。但也有些用户在与这些软件包一同使用PostgreSQL时并未遇见问题,所以这是个别安装的问题,可能需要卸载这些软件。如果您已安装了 cygwin ,且 cygwin\bin 目录存在于系统PATH变量中,也可能会遇到问题。cygwin目录中一些与解释语言(TCL, perl, python)有关的DLL文件存在bug,可能引起安装程序或者安装的PostgreSQL发行失去响应或崩溃。将cygwin\bin从系统PATH 中去除再运行安装程序!

安装程序提示指定的帐号是个管理员,但它并不是

很可能给定的帐号是 administrator 或 power user 而您并没有意识到。安装程序将会特别检查给定帐号是否为 Administrators 或 Power Users 组的成员。使用控制面板中的用户及用户组工具检查该帐号是否为Administrator组的成员以及组成员,等等。 安装程序将会检查任一等级的嵌套用户组。

我得到了类似“该用户并未被授权在本计算机上以此方式登陆”的错误信息

确保给定的PostgreSQL帐号具有“作为服务登录(Log on as a service)”与“本地登陆(Log on locally)”权。“本地登陆”仅为安装时所需,一旦安装完毕可以去除。(可使用“本地安全策略”的MMC扩展授权或者除权,“本地登陆”默认给予,而“作为服务登录”通常由安装程序自动授予。)如果您依然遇到问题,请打开审计功能(依然在“本地安全策略”中),并让我们了解在您安装时还需要什么其他权限。注意,如果您的计算机是域的成员,安全策略的设置将由域的组策略决定。

在安装或运行initdb时我遇到了权限错误

请确保PostgreSQL服务帐号具有安装路径上所有目录的必要权限。安装程序将会设置安装目录的权限但不会理会它的父目录。

我收到错误消息,说PostgreSQL不能从终端服务会话中安装

PostgreSQL后端将无法从一个TS会话启动。为了进行initdb,安装程序必须启动一个独立后端。应此,安装必须在控制台进行。注意,如果您使用 Windows Server 2003,您能获得控制台的远程访问,而不是管理会话。为此,请用 mstsc /console 启动远程桌面连接,然后照常使用。这将锁住计算机的本地控制台然后将控制转交给此会话。这样PostgreSQL将正常安装。

我更改了安装目录但是PostgreSQL依然安装在默认目录

请确保您更改的目录属于根功能 。PostgreSQL安装程序允许为某些功能设置单独的安装目录。如果您更改了根功能 ("PostgreSQL")的目录,任何子功能(如"Database Server")将默认自动继承这个值,而如果您更改了一个子功能的目录,安装的其余部分还将位于默认位置。

在升级时,安装程序提示我没有权限安装一个服务,但我是作为管理员登录系统的

此问题的解决方法之一是: 卸载 之前的版本。注意这并不会 移除您的数据!然后再安装新的版本,同时请确保您使用了确切的相同目录 。这将解决这个问题。注意,这仅对小版本的升级有效,比如 8.2.5 到 8.2.6。需要使用dump/reload的大版本升级无法使用此法。

我得到错误消息提示安装包无法打开

导致此问题可能有两种原因: 您双击了ZIP文件包中的MSI文件,而安装需要先解压缩整个ZIP文件至一临时位置再运行它。另一个原因是下载文件已损坏,请尝试重新下载,可使用另外的镜像。


 

常见运行时问题

在安装过程语言时,我得到“动态加载错误”("dynamic load error")

通常这意味着过程语言所需的实际DLL文件缺失了。PostgreSQL发布中的DLL仅包括了语言的绑定,此外还需要语言发布本身的DLL文件位于系统的PATH中。要获取当前不同过程语言所需要的DLL文件列表,可访问 安装指引 。要查找缺失的具体DLL文件,您可使用Microsoft提供的depends 工具,可在Windows安装光盘的Windows支持工具中找到。运行depends plpython.dll (以PL/python为例)将显示哪个引用文件缺失。

我发现了一大堆postgres.exe进程,尽管我只启动了一次服务器程序

这是正常情况。PostgreSQL使用了多进程架构。对于一个空转的系统,您将看到2至5个进程。当客户端开始连接后,进程数将增加。

怎样设置环境变量?

一些PostgreSQL设置使用了环境变量。对于大多数Windows版本而言,环境变量可在 我的电脑 -> 属性 -> 高级 中进行设置。注意,那里提供了两组环境变量,一组应用于整个系统,而另一组仅影响当前用户。如果您期望一个环境变量影响PostgreSQL服务,您必须更改系统环境变量。之后您必须重新启动该服务。

尽管硬件很强劲,但我无法同时运行多于125个连接

当作为系统服务运行时,在处理多于大约125个并发连接时,您可能会遇到失败。这是由于PostgreSQL所依赖的一些库依赖于 user32.dll,后者从内存中一块称为桌面堆(Desktop Heap)的区域中分配内存。桌面堆被分配给了每一个登录的会话,通常一个非交互的会话将会分配给512KB。每个postgres进程典型的桌面堆消耗是3.2KB,加上其他的额外开销,大约在125个连接左右时,分配的堆空间便会耗尽。当在命令行方式运行时,不会发生这种情况(更确切地说,将会在远大于此连接数时发生),因为每个交互登录会话将会分配给3MB的桌面堆。您可以像这篇Microsoft 智库文章 描述的那样通过修改注册表中第三个SharedSection的值来增大非交互会话的桌面堆。注意如此操作需要非常小心,一旦指定的值过大,系统将无法启动。

来源:http://wiki.postgresql.org/wiki/%E5%9C%A8Windows%E5%B9%B3%E5%8F%B0%E4%B8%8A%E5%AE%89%E8%A3%85%E4%B8%8E%E8%BF%90%E8%A1%8CPostgreSQL%E7%9A%84%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E4%B8%8E%E8%A7%A3%E7%AD%94

Jul 30

EnterpriseDb 图形化的表空间备份恢复测试:
 有数据库test,表student,主键pk_student 放在testDb 表空间,索引。。。放在test_indx 表空间

1 在异机建立数据库test2(即和备份的数据库不同名称):执行恢复前清空数据 情况:会把表相关弄过去,但是但是会是在默认的模式里面默认的表空间进行,同时新建我们原来的模式test,但是里面没有数据,再次执行时才有:以下是返回的结果
-- Table: test.student

-- DROP TABLE test.student;

CREATE TABLE test.student
(
  sno integer NOT NULL,
  sname character varying(50),
  CONSTRAINT pk_student PRIMARY KEY (sno) -- sdf
)
WITH (
  OIDS=FALSE
);
ALTER TABLE test.student OWNER TO "admin";
COMMENT ON CONSTRAINT pk_student ON test.student IS 'sdf';

-- Index: test.student_index_name
-- DROP INDEX test.student_index_name;

CREATE UNIQUE INDEX student_index_name
  ON test.student
  USING btree
  (sname);
COMMENT ON INDEX test.student_index_name IS '根据name 索引';

 

-- Table: student

-- DROP TABLE student;

CREATE TABLE student
(
  sno integer NOT NULL,
  sname character varying(50),
  CONSTRAINT pk_student PRIMARY KEY (sno) -- sdf
)
WITH (
  OIDS=FALSE
);
ALTER TABLE student OWNER TO "admin";
COMMENT ON CONSTRAINT pk_student ON student IS 'sdf';


-- Index: student_index_name

-- DROP INDEX student_index_name;

CREATE UNIQUE INDEX student_index_name
  ON student
  USING btree
  (sname);
COMMENT ON INDEX student_index_name IS '根据name 索引';

 


2 在异机建立数据库test(即和备份的数据库相同名称):执行恢复前清空数据 情况:会把表相关弄过去,但是但是会是在默认的模式里面默认的表空间进行,同时新建我们原来的模式test,但是里面没有数据,再次执行时才有:以下是返回的结果
C:\PostgresPlus\8.3R2AS\dbserver\bin\pg_restore.exe --host 192.168.1.35 --port 5444 --username "admin" --dbname test --clean --verbose "C:\Documents and Settings\dell\桌面\test_20100730_0934.backup"
pg_restore: 正在连接到数据库以进行恢复
pg_restore: 正在删除 COMMENT INDEX student_index_name
pg_restore: [存档程序] PROCESSING TOC 时出错:
pg_restore: [存档程序] 错误来自 TOC 条目 2490;0 0 COMMENT INDEX student_index_name enterprisedb
pg_restore: [存档程序] could not set search_path to "test": ERROR:  schema "test" does not exist
pg_restore: 正在删除 INDEX student_index_name
pg_restore: [归档 (db)] 错误来自 TOC 条目 2483;1259 52242 INDEX student_index_name enterprisedb
pg_restore: [归档 (db)] could not execute query: ERROR:  schema "test" does not exist
    Command was:
DROP INDEX test.student_index_name;
pg_restore: 正在删除 COMMENT CONSTRAINT pk_student ON student
pg_restore: 正在删除 CONSTRAINT pk_student
pg_restore: [归档 (db)] 错误来自 TOC 条目 2482;2606 52240 CONSTRAINT pk_student enterprisedb
pg_restore: [归档 (db)] could not execute query: ERROR:  schema "test" does not exist
    Command was: ALTER TABLE ONLY test.student DROP CONSTRAINT pk_student;
pg_restore: 正在删除 TABLE student
pg_restore: [归档 (db)] 错误来自 TOC 条目 2033;1259 52237 TABLE student enterprisedb
pg_restore: [归档 (db)] could not execute query: ERROR:  schema "test" does not exist
    Command was: DROP TABLE test.student;
pg_restore: 正在删除 COMMENT SCHEMA test
pg_restore: 正在删除 SCHEMA test
pg_restore: [归档 (db)] 错误来自 TOC 条目 7;2615 52236 SCHEMA test enterprisedb
pg_restore: [归档 (db)] could not execute query: ERROR:  schema "test" does not exist
    Command was: DROP SCHEMA test;
pg_restore: 正在创建 SCHEMA test
pg_restore: [归档 (db)] could not execute query: ERROR:  role "enterprisedb" does not exist
    Command was: ALTER SCHEMA test OWNER TO enterprisedb;
pg_restore: 正在创建 COMMENT SCHEMA test
pg_restore: 正在创建 TABLE student
pg_restore: [存档程序] 错误来自 TOC 条目 2033;1259 52237 TABLE student enterprisedb
pg_restore: [存档程序] could not set default_tablespace to "testTB": ERROR:  tablespace "testTB" does not exist
pg_restore: [归档 (db)] could not execute query: ERROR:  relation "test.student" does not exist
    Command was: ALTER TABLE test.student OWNER TO enterprisedb;
pg_restore: 正在为表 "student" 恢复数据
pg_restore: 正在创建 CONSTRAINT pk_student
pg_restore: 正在创建 COMMENT CONSTRAINT pk_student ON student
pg_restore: 正在创建 INDEX student_index_name
pg_restore: [存档程序] 错误来自 TOC 条目 2483;1259 52242 INDEX student_index_name enterprisedb
pg_restore: [存档程序] could not set default_tablespace to test_indx: ERROR:  tablespace "test_indx" does not exist
pg_restore: 正在创建 COMMENT INDEX student_index_name
pg_restore: 正在为 SCHEMA test 设置所有者和权限
pg_restore: 正在为 COMMENT SCHEMA test 设置所有者和权限
pg_restore: 正在为 TABLE student 设置所有者和权限
pg_restore: 正在为 CONSTRAINT pk_student 设置所有者和权限
pg_restore: 正在为 COMMENT CONSTRAINT pk_student ON student 设置所有者和权限
pg_restore: 正在为 INDEX student_index_name 设置所有者和权限
pg_restore: 正在为 COMMENT INDEX student_index_name 设置所有者和权限
警告: 恢复时忽略了错误:9

表的定义:

-- Table: test.student

-- DROP TABLE test.student;

CREATE TABLE test.student
(
  sno integer NOT NULL,
  sname character varying(50),
  CONSTRAINT pk_student PRIMARY KEY (sno) -- sdf
)
WITH (
  OIDS=FALSE
);
ALTER TABLE test.student OWNER TO "admin";
COMMENT ON CONSTRAINT pk_student ON test.student IS 'sdf';


-- Index: test.student_index_name

-- DROP INDEX test.student_index_name;

CREATE UNIQUE INDEX student_index_name
  ON test.student
  USING btree
  (sname);
COMMENT ON INDEX test.student_index_name IS '根据name 索引';

进程退出并返回 1。

 


3

C:\PostgresPlus\8.3R2AS\dbserver\bin\pg_restore.exe --host 192.168.1.35 --port 5444 --username "admin" --dbname test --clean --verbose "C:\Documents and Settings\dell\桌面\test_20100730_0934.backup"
pg_restore: 正在连接到数据库以进行恢复
pg_restore: 正在删除 COMMENT INDEX student_index_name
pg_restore: 正在删除 INDEX student_index_name
pg_restore: 正在删除 COMMENT CONSTRAINT pk_student ON student
pg_restore: 正在删除 CONSTRAINT pk_student
pg_restore: 正在删除 TABLE student
pg_restore: 正在删除 COMMENT SCHEMA test
pg_restore: 正在删除 SCHEMA test
pg_restore: 正在创建 SCHEMA test
pg_restore: [归档 (db)] PROCESSING TOC 时出错:
pg_restore: [归档 (db)] 错误来自 TOC 条目 7;2615 52236 SCHEMA test enterprisedb
pg_restore: [归档 (db)] could not execute query: ERROR:  role "enterprisedb" does not exist
    Command was: ALTER SCHEMA test OWNER TO enterprisedb;
pg_restore: 正在创建 COMMENT SCHEMA test
pg_restore: 正在创建 TABLE student
pg_restore: [存档程序] 错误来自 TOC 条目 2033;1259 52237 TABLE student enterprisedb
pg_restore: [存档程序] could not set default_tablespace to "testTB": ERROR:  tablespace "testTB" does not exist
pg_restore: [归档 (db)] could not execute quer
进程退出并返回 1。


4 创建test库和相应的test 模式

C:\PostgresPlus\8.3R2AS\dbserver\bin\pg_restore.exe --host 192.168.1.35 --port 5444 --username "admin" --dbname test --no-owner --clean --verbose "C:\Documents and Settings\dell\桌面\test_20100730_0934.backup"
pg_restore: 正在连接到数据库以进行恢复
pg_restore: 正在删除 COMMENT INDEX student_index_name
pg_restore: 正在删除 INDEX student_index_name
pg_restore: 正在删除 COMMENT CONSTRAINT pk_student ON student
pg_restore: 正在删除 CONSTRAINT pk_student
pg_restore: 正在删除 TABLE student
pg_restore: 正在删除 COMMENT SCHEMA test
pg_restore: 正在删除 SCHEMA test
pg_restore: 正在创建 SCHEMA test
pg_restore: 正在创建 COMMENT SCHEMA test
pg_restore: 正在创建 TABLE student
pg_restore: [存档程序] PROCESSING TOC 时出错:
pg_restore: [存档程序] 错误来自 TOC 条目 2033;1259 52237 TABLE student enterprisedb
pg_restore: [存档程序] could not set default_tablespace to "testTB": ERROR:  tablespace "testTB" does not exist
pg_restore: 正在为表 "student" 恢复数据
pg_restore: 正在创建 CONSTRAINT pk_student
pg_restore: 正在创建 COMMENT CONSTRAINT pk_student ON student
pg_restore: 正在创建 INDEX student_index_name
pg_restore: [存档程序] 错误来自 TOC 条目 2483;1259 52242 INDEX student_index_name enterprisedb
pg_restore: [存档程序] could not set default_tablespace to test_indx: ERROR:  tablespace "test_indx" does not exist
pg_restore: 正在创建 COMMENT INDEX student_index_name
pg_restore: 正在为 SCHEMA test 设置所有者和权限
pg_restore: 正在为 COMMENT SCHEMA test 设置所有者和权限
pg_restore: 正在为 TABLE student 设置所有者和权限
pg_restore: 正在为 CONSTRAINT pk_student 设置所有者和权限
pg_restore: 正在为 COMMENT CONSTRAINT pk_student ON student 设置所有者和权限
pg_restore: 正在为 INDEX student_index_name 设置所有者和权限
pg_restore: 正在为 COMMENT INDEX student_index_name 设置所有者和权限
警告: 恢复时忽略了错误:2

5 当所有的环境都和原先备份的差不多的时候:ok
C:\PostgresPlus\8.3R2AS\dbserver\bin\pg_restore.exe --host localhost --port 5444 --username enterprisedb --dbname test --clean --verbose "D:\28服务器备份\EnterpriseDb\gk\test_20100730_0934.backup"

进程退出并返回 0。


把表移动到另外一个表空间:

ALTER TABLE distributors SET TABLESPACE fasttablespace;

把表移动到另外一个模式:

ALTER TABLE myschema.distributors SET SCHEMA yourschema;

分页: 1/4 第一页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]