My DBA LIFE

      之前测试过 PostgreSQL 的 mysql_fdw， file_fdw ，今天有空，测试了 oracle_fdw,
什么是 oracle_fdw 呢？简单的说， 通过安装 oracle_fdw, 在 PostgreSQL 中可以访问
Oracle 库中的表，类似 dblink，下面是 oracle_fdw 的安装过程。

一 环境信息
--1.1 Installation Requirements
PostgreSQL:  PostgreSQL 9.1 或更高版本

                PostgreSQL 9.2 Beta 版已经出来了，主要特性包括 Index-only scans，read-only 场景
强大的支撑 (300,000 queries per second)，写性能的改善，CPU资源消耗降低，以及 Cascading replication 
等，有空可以测试下，下面是来自 PostgreSQL 官网 http://www.postgresql.org/about/news/1395/

       根据 PostgreSQL 的 MVCC 机制，数据被插入时 PostgreSQL 会分配给每行 tuples 一个 事务ID，即表上的

隐含字段  Xmin， 而 PostgreSQL 的事务号由 32 bit  位 ( 40 亿) 组成，事务号分配完了后会循环，这样会造成过去

的记录不可见的情况，为了解决这个问题，理论上在 20 亿事务之内需要 vacuum 每一个数据库的每一个表， 而

 vacuum 操作会替换某些老记录的xid 成 FrozenXID，这样即使事务号循环，这些被替换成 FrozenXID 的记录依然

对当前事务可见，下面是模拟表数据的tuples 的 xid 被替换成 FrozenXID 的几个例子。

  
      今天在测试库上发现 autovacuum 无法正常启动，数据库版本 9.1.0，经查已经配置 autovacuum=on ，
 发现日志出现如下信息
  
--1 csvlog
2012-03-08 11:14:59.017 CST,,,1155,,4f582407.483,1,,2012-03-08 11:14:15 CST,,0,LOG,00000,"could not resolve ""localhost"": Temporary failure in name resolution",,,,,,,,,""
2012-03-08 11:14:59.017

 
 
          之前在读到手册 "Preventing Transaction ID Wraparound Failures" 时，一直有段话不太明白，这段话内容如下：
今天在听德哥培训课时，终于理解了，德哥原BLOG: http://blog.163.com/digoal@126/blog/static/163877040201183043153622/
今天参考德哥BLOG 做了下测试，终于明白了以下手册内容。
 

--手册内容的一段话

            最近有个项目需要跨 IDC 迁移，需将一个生产库迁移到另一个IDC，数据量不大，版本为 9.1.2，
由于尽可能地减少停机时间，这次迁移采用的是 PostgreSQL 的流复制技术，即先搭建好备库，然后再
主备切换，完成迁移，这种方法迁移，能将业务中断时间缩减在5分钟以内甚至更更快；流复制数据库迁
移的步骤如下：

1 流复制搭建
   具体步骤可参考之前的 blog:  http://francs3.blog.163.com/blog/static/40576727201108864230/

2 主备切换

           PostGIS 2.0.0 Released  已经有段时间了，新版本 postgis 包括以下新特性，对 postgis 感兴趣的

朋友可以下载测试下。

The development process for 2.0 has been very long, but has resulted in a release with a number of exciting new features.

• Raster data and raster/vector analysis in the database
• Topological