davegreen100's questions

我正在尝试使用该pg_upgrade工具从 9.2 升级到 9.5。

我使用的是 CentOS 7.0

current postgres bin folder: /opt/rh/postgresql92/root/usr/bin
new postgres bin folder: /opt/rh/rh-postgresql95/root/usr/bin
current data folder: /mnt/postgres/data
new data folder: /mnt/postgres/data95

我已经设置了LD_LIBRARY_PATH=/opt/rh/rh-postgresql95/root/usr/lib64

当我跑步时

/opt/rh/rh-postgresql95/root/usr/bin/pg_upgrade --link --check --old-bindir=/opt/rh/postgresql92/root/usr/bin --new-bindir=/opt/rh/rh-postgresql95/root/usr/bin --old-datadir=/mnt/postgres/data --new-datadir=/mnt/postgres/data95

我收到这条消息：

Performing Consistency Checks
-----------------------------
Checking cluster versions                                   /opt/rh/postgresql92/root/usr/bin/pg_ctl: error while loading shared libraries: libpq.so.postgresql92-5: cannot open shared object file: No such file or directory

Could not get pg_ctl version data using "/opt/rh/postgresql92/root/usr/bin/pg_ctl" --version: No such file or directory
Failure, exiting

我不确定为什么要尝试使用 9.2 版本的 pg_ctl

which pg_ctl 

回报

/opt/rh/rh-postgresql95/root/usr/bin/pg_ctl

我做错了什么？

我在 Red Hat linux 6 上运行 oracle 11.2.0.4 SE RAC，数据库使用 ASM 进行数据文件管理

我一直在尝试打开 AMM 并设置以下参数

alter system set pga_aggregate_target='0' scope=spfile sid='*';
alter system set sga_target='0' scope=spfile sid='*';
alter system set memory_max_target='8G' scope=spfile sid='*';
alter system set memory_target='8G' scope=spfile sid='*';

但现在我想关闭实例和数据库上的 AMM，但是当我进行所需的更改时

alter system set pga_aggregate_target=2G scope=spfile sid='*';
alter system set sga_target=6G scope=spfile sid='*';
alter system set memory_max_target=0 scope=spfile sid='*';
alter system set memory_target=0 scope=spfile sid='*';

我在启动实例时收到此错误

SQL> startup pfile='?/dbs/initdev12.ora';
ORA-00843: Parameter not taking MEMORY_MAX_TARGET into account
ORA-00849: SGA_TARGET 6442450944 cannot be set to more than MEMORY_MAX_TARGET 0.
ORA-01078: failure in processing system parameters

如果我将 MEMORY_MAX_TARGET 设置回 8G，我可以启动数据库，但我的参数现在看起来像这样

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 6G
sga_target                           big integer 6G
SQL> show parameter memory

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address             integer     0
memory_max_target                    big integer 8208M
memory_target                        big integer 0
shared_memory_address                integer     0
SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 2G

任何想法我做错了什么？

干杯戴夫

我正在使用 实现还原点pg_create_restore_point，然后将有一组脚本使我的用户能够还原到其中一个还原点。显然，我有工作要做备份和归档 WAL 等，但这一切都在手边。

我的问题是，是否有一个列出所有可用还原点的数据库表？

干杯戴夫

红帽 6 上的 oracle 11.2.0.4

SERV1 是运行数据库 MAZ 的 prod 服务器，SERV2 是没有数据库的开发服务器。

我已经记下了 dbid 和最后一个 SCN，然后使用以下命令在 SERV1 上进行了备份

run
{
backup database plus archivelog tag "first";
}

现在将所有备份文件和 pfile 的副本复制到 SERV2。

在 SERV2 上

rman target /
set dbid 2711958994
startup mount pfile=/u01/app/oracle/product/11.2.0/dbhome_2/dbs/initmaz.ora
run {
set controlfile autobackup format for device type disk to '/u03/app/oracle/fast_recovery_area/TEST/autobackup/2015_05_15/%F';
restore spfile to pfile '/u01/app/oracle/product/11.2.0/dbhome_2/dbs/initmaz.ora' from autobackup;
}

shutdown immediate
startup nomount pfile=/u01/app/oracle/product/11.2.0/dbhome_2/dbs/initmaz.ora

run {
set controlfile autobackup format for device type disk to '/u03/app/oracle/fast_recovery_area/TEST/autobackup/2015_05_15/%F';
restore controlfile from autobackup;
}

alter database mount;

catalog start with '/u03/app/oracle/fast_recovery_area/MAZ/backupset/2015_05_15';

现在我检查了它在 SERV2 上可用的备份集

rman target /
RMAN> list backup
2> ;

using target database control file instead of recovery catalog

List of Backup Sets
===================


BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
190     6.59M      DISK        00:00:00     15-MAY-15
        BP Key: 190   Status: AVAILABLE  Compressed: YES  Tag: FIRST
        Piece Name: /u03/app/oracle/fast_recovery_area/MAZ/backupset/2015_05_15/o1_mf_annnn_FIRST_bocjlvfk_.bkp

  List of Archived Logs in backup set 190
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    501     1950316    14-MAY-15 1973213    15-MAY-15
  1    502     1973213    15-MAY-15 1973254    15-MAY-15
  1    503     1973254    15-MAY-15 1974268    15-MAY-15
  1    504     1974268    15-MAY-15 1974295    15-MAY-15
  1    505     1974295    15-MAY-15 1974321    15-MAY-15
  1    506     1974321    15-MAY-15 1976213    15-MAY-15
  1    507     1976213    15-MAY-15 1976251    15-MAY-15
  1    508     1976251    15-MAY-15 1977715    15-MAY-15

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
191     Full    76.84M     DISK        00:00:30     15-MAY-15
        BP Key: 191   Status: AVAILABLE  Compressed: YES  Tag: TAG20150515T105436
        Piece Name: /u03/app/oracle/fast_recovery_area/MAZ/backupset/2015_05_15/o1_mf_nnndf_TAG20150515T105436_bocjlwr0_.bkp
  List of Datafiles in backup set 191
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 1977721    15-MAY-15 /u02/app/oracle/oradata/maz/system01.dbf
  2       Full 1977721    15-MAY-15 /u02/app/oracle/oradata/maz/sysaux01.dbf
  3       Full 1977721    15-MAY-15 /u02/app/oracle/oradata/maz/undotbs01.dbf
  4       Full 1977721    15-MAY-15 /u02/app/oracle/oradata/maz/users01.dbf

BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
192     3.00K      DISK        00:00:00     15-MAY-15
        BP Key: 192   Status: AVAILABLE  Compressed: YES  Tag: FIRST
        Piece Name: /u03/app/oracle/fast_recovery_area/MAZ/backupset/2015_05_15/o1_mf_annnn_FIRST_bocjmzy1_.bkp

  List of Archived Logs in backup set 192
  Thrd Seq     Low SCN    Low Time  Next SCN   Next Time
  ---- ------- ---------- --------- ---------- ---------
  1    509     1977715    15-MAY-15 1977737    15-MAY-15

此时，如果我运行以下命令，那么一切正常

run {
set until scn 1977737;
restore database;
recover database;
}

alter database open resetlogs;

但我想使用标签名称（FIRST）恢复，所以我试试这个

run {
set until scn 1977737;
restore database from TAG=FIRST;
}

我收到消息

Starting restore at 15-MAY-15
using channel ORA_DISK_1

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 05/15/2015 13:15:05
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore

关于我做错了什么的任何想法？

谢谢

我的 postgres 备份/恢复到待机似乎有间歇性问题

Postgres，是在 red hat 6 企业版上运行的 9.2 版

我有一个生产服务器 (PROD1) 和一个热备用服务器 (STANDBY1)，周日晚上我有一个脚本将 PROD1 置于备份模式，在 $PGDATA 目录上执行 tar，将文件复制到 STANDBY1，STANDBY1 上的脚本是然后调用以停止 STANDBY1 上的 postgres，解压缩 tar，然后再次启动 postgres。

与此同时，PROD1 上的 archive_command 继续在 STANDBY1 上复制 WAL 文件，因此理论上 STANDBY1 将被更新。然后在一周的剩余时间里应用 WAL 文件，直到下个星期日该过程再次开始。

PROD1 上备份脚本的代码提取

psql -X -U postgres --set ON_ERROR_STOP=on <<PSQL
select pg_start_backup('${WEEK_START}_DataBackup','true');
PSQL

tar -zcf $WEEKLYBACKUP_DIRECTORY/full_backup_${WEEK_START}.tar.gz --exclude=$PGDATA/pg_xlog/* --exclude=$PGDATA/pg_xlogArchive/* 
--exclude=$PGDATA/pg_xlogRestored --exclude=$PGADTA/postmaster.pid --exclude=$PGDATA/postmaster.opts $PGDATA/

psql -X -U postgres --set ON_ERROR_STOP=on <<PSQL
select pg_stop_backup();
PSQL

scp -p $WEEKLYBACKUP_DIRECTORY/full_backup_${WEEK_START}.tar.gz $DR_SERVER:$WEEKLYBACKUP_DIRECTORY/.

ssh -T $DR_SERVER <<EOF >> $MAILFILE
  cd /var/lib/pgsql/Scripts
  ./postgres-hotStandby $WEEK_START Y
EOF

STANDBY1 上的 hotstandby 脚本的代码提取

pg_ctl stop -D $PGDATA -m i >> $LOGFILE
tar -zxf $WEEKLYBACKUP_DIRECTORY/full_backup_${RESTORE_WEEK}.tar.gz

# create a recovery file
echo "standby_mode = 'on'" >$PGDATA/recovery.conf
echo "primary_conninfo = 'host=${LIVE_SERVER}'" >>$PGDATA/recovery.conf
echo "restore_command = 'cp -f $PGDATA/pg_xlog/%f $PGDATA/pg_xlogRestored'" >>$PGDATA/recovery.conf
echo "trigger_file = '${PGDATA}/failover'" >>$PGDATA/recovery.conf
sed -i 's/#hot_standby = off/hot_standby = on/g' $PGDATA/postgresql.conf
pg_ctl -w -D $PGDATA start

上述过程每秒钟运行一次，其他时间失败，给出消息

“psql: FATAL: 数据库系统正在启动”

当我尝试进入 psql 时。

查看 STANDBY1 上的日志文件，postgres 正在等待它说的 WAL 文件......

cp：无法统计`/vol2/postgres92/pgsql/data/pg_xlog/000000010000005200000003'：没有这样的文件或目录 2015-04-24 00:10:40 EDT -LOG：流复制成功连接到主 2015-04-24 00 :10:40 EDT -FATAL：无法从 WAL 流接收数据：FATAL：请求的 WAL 段 000000010000005200000003 已被删除

运行时pg_start_backup，这将创建一个发送到 STANDBY1 的 WAL 文件（例如 000000010000005200000003），并且在pg_stop_backup运行时会创建一个备份 WAL 的结尾（例如 000000010000005200000003.00000020.backup），该文件也正确发送到 STANDBY1。但是当失败发生时， pg_start_backup WAL 似乎在 STANDBY1 服务器上丢失了。

希望这一切对某人有某种意义，任何想法出了什么问题？我似乎无法在我的测试系统上重现这一点，我认为这可能是一个时间问题，因为 PROD1 和 STANDBY1 的大小和位置，服务器之间的 scp 需要 15 分钟。

谢谢你提供的所有帮助

我正在使用pg_ctl -D $PGDATA status来监视我的 postgres 备用数据库是否已启动并正在运行。有时数据库由于缺少 WAL 文件而无法启动，但其状态报告为“可用”。

有没有一种简单的方法可以使用该选项查看 postgres 是否可用pg_ctl status，或者我是否需要编写脚本来查询 postgres 数据库并监视脚本的输出？

我在 RedHat 6 上使用 PostgreSQL 9.2

我有点困惑为什么会发生以下情况：

1. 当 postgres 运行时，以 root 身份执行“service postgresql92-postgresql status”会导致“postmaster (pid 1379) is running...”（如预期的那样）

2. 当 postgres 运行“pg_ctl stop -D $PGDATA -m s”来停止 postgres

3. 由于 postgres 运行“pg_ctl -D $PGDATA start”来启动 postgres（postgres 现在运行正常）

4. 现在以root身份运行“service postgresql92-postgresql status”，输出现在是“postmaster dead but pid file exists”

我的困惑是为什么当 postgres 正常运行时我会在第 4 步中收到消息？我是否错误地停止/启动 postgres？