Pg::Snapshot USAGE

上面那篇PostgreSQL MVIEW的USAGE:

As database superuser (often postgres, but check for your system), do the following:

INSTALLATION

1.  Load PL/Perlu into your database.  See the createlang documents for details on how to do this;

2.  Make shure that DBI is installed on your Perl system and that the DBD of the database you choose is also installed;

3. Edit the Makefile.sh file and change the KEY variable to a better "secret" value and theBASE_SCHEMA variable to where the base(internal) Pg::Snapshot tables should be placed. Also remember to setup the remaining variables like SUPERUSER.

4.  On the PostgreSQL::Snapshots root, execute:
    # ./Makefile.sh

5. Load the database driver:
    - On PostgreSQL:
    # psql -d <database> -h <host> -U <user> -f ./drivers/pg/snapshot.sql
    - On Oracle, inside SQL+:
    SQL> @./drivers/oracle/snapshot.sql

6.  Load the pgsnapshots.sql file:
    # psql -d <database> -h <host> -U <user> -f pgsnapshots.sql

7. Allow the access from your workstation(or remote server) to one or more master tables on the current database:
    - Inside psql, conected as POSTGRES user:
    db=# select snapshot_do('<key>', 'ALLOW', '<masterschema>', '<mastername>', '<ip>');
    - or inside SQL+, conected as SYS user:
    SQL> begin
         snapshot_do('<key>', 'ALLOW', '<masterschema>', '<mastername>', '<ip>');
         end;
         /

    Where:
        <key> is the "secret" value placed on the KEY variable inside the Makefile.sh file.
        <masterschema> is the schema name of the master table you wish to allow access to
        <mastername> is the name of the master table you wish to allow access to
        <ip> is the IP address of your workstation/server to whom you wish to give access

8.  Use the underlying methods aka functions as needed.

AVAILABLE FUNCTIONS

1. create_dblink (implementation of "CREATE DBLINK")
    This function creates a link between databases. It takes the name of the DBLINK to be created and the necessary parameters do establish the remote connection.
    
    Syntax:
    create_dblink(dblinkname text, datasource text, username text, password text, attributes text)
    dblinkname: name of the DBLINK to be created
    datasource: Perl:DBI CONNECTION string to the remote database
    username: NAME of the remote database user
    password: PASSWORD of the remote database user
    attributes: connection ATTRIBUTES, like AutoCommit, RaiseErrors, etc.

2. drop_dblink (implementation of "DROP DBLINK")
    This function removes a link between databases taking only the DBLink name as a parameter.
    
    Syntax:
    drop_dblink(dblinkname text)
    dblinkname: name of the DBLINK to be removed

3. create_snapshot (implementation of "CREATE SNAPSHOT" or "CREATE MATERIALIZED VIEW")
    This function creates a materialized view or snapshot based on a query. The query can be referencing a database link or not.
    
    Syntax:
    create_snapshot(schemaname text, snapshotname text, query text, dblink text, refresh_method text, prebuilt_table text)
    schemaname: name of the schema where the snapshot will be created
    snapshotname: name of the snapshot to be created
    query: SQL query that will be executed at the remote database and which result will fill the snapshot
    dblink: optional parameter that take the name of the DBLink to be used. If the value is NULL, the query will be executed by the local database.
    refresh_method: can be "COMPLETE", "FAST" or "FORCE".
    prebuilt_table: name of the prebuilt table, on the same schema of the snapshot, over which the snapshot will be created (existing data are preserved). This is an optional parameter.

    IMPORTANT: the table will not be filled by this function.

4. drop_snapshot (implementation of "DROP SNAPSHOT" or "DROP MATERIALIZED VIEW")
    This function removes a materialized view or snapshot taking the schema name and the snapshot name as parameters.
    
    Syntax:
    drop_snapshot (schemaname text, snapshotname text)
    schemaname: name of the schema where the snapshot resides
    snapshotname: name of the snapshot to be removed

5. create_snapshot_log (implementation of "CREATE MATERIALIZED VIEW LOG" or "CREATE SNAPSHOT LOG")
    This function creates a log table bound to a master table. This log table allows the creation of fast refreshing snapshot(FAST REFRESH).

    Syntax:
    create_snapshot_log (schemaname text, mastername text, withwhat text)
    schemaname: name of the schema where the master table resides
    mastername: name of the master table
    withwhat: use the this clause to indicate whether the snapshot log should record the primary key, the rowid, or both the primary key and rowid when rows in the master are updated. This clause also specifies whether the snapshot records filter columns, which are non-primary-key columns referenced by subquery snapshots. The syntax is:
        1) "PRIMARY KEY": indicate that the primary key of all rows updated in the master table should be recorded in the snapshot log;
        2) "OID": indicate that the OID of all rows updated in the master table should be recorded in the snapshot log;
        3) "(<filter-columns>)" : a parenthesis-delimited comma-separated list that specifies the filter columns to be recorded in the snapshot log. For fast-refreshable primary-key snapshots defined with subqueries, all filter columns referenced by the defining subquery must be recorded in the snapshot log;
        4) Any combination of the above in any order.

6. drop_snapshot_log (implementation of "DROP MATERIALIZED VIEW LOG" or "DROP SNAPSHOT LOG")
    This function removes a log table previously bound to a master table.

    Syntax:
    drop_snapshot_log (schemaname text, mastername text)
    schemaname: name of the schema where the master table resides
    mastername: name of the master table

5. refresh_snapshot (implementation of "DBMS_SNAPSHOTS.REFRESH")
    This function refreshes the data on a materialized view or snapshot taking the schema and snapshot names as parameters.
    
    Syntax:
    refresh_snapshot (schemaname text, snapshotname text)
    schemaname: name of the schema where the snapshot resides
    snapshotname: name of the snapshot to be refreshed

时间: 2024-09-28 02:24:51

Pg::Snapshot USAGE的相关文章

PlateSpin 完全复制由于LVM没有可用空闲空间导致失败

  使用PlateSpin复制居然会由于LVM的卷组VG没有空闲可用的空间(available free space in the LVM volume group)创建快照而导致失败,特此记录一下:免得每次都将卷组VG里面的空间全部使用完.在进行存储分配.规划时,如果有使用PlateSpin做复 制,一定要留意这个事情. The use of LVM snapshots is the default way of migrating hard drive partitions on LVM l

use zfs snapshot rollback postgresql&#039;s primary to old status in PG HA

前几天讲过zfs的snapshot用作PostgreSQL PITR, 使用接近还原点的snapshot可以减少xlog的apply, 缩短数据库的恢复时间. 其实snapshot还有一个作用, 用作流复制HA的主备角色切换后避免因为XLOG的差异导致old primary无法切换成standby角色. 例如  :  一个PG 流复制的HA场景如下 :  在发生failover后, standby节点切换成主节点, 老的主节点切换成standby节点. 但是由于standby节点和老的主节点存在

PG 9.4 行冻结信息的测试

有在网上找过一些关于vacuum_freeze_min_age参数是如何影响vacuum冻结旧行的文章.类似的参考资料可以参看链接: http://blog.csdn.net/luojinbai/article/details/45848381 但是自己在做类似的测试时发现,并没有出现相同的结果,反复测试几次,仍然不同.后来咨询了下德哥说,看源码,行冻结的信息不再通过改变xmin来实现行冻结的信息.当时就觉得绝望了,对于一个完全不懂任何高级开发语言的人来说,这个等于对PG又多了个谜.后来想到,是

Sonatype OSS Maven Repository Usage Guide

原文:https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide Sonatype OSS Maven Repository Usage Guide Attachments:4 Added by Juven Xu, last edited by Joel Orlina on Jun 05, 2013  (view change) 1. Introduction 1a. Terms o

pg 函数sfa_tmp_sleep()执行越来越慢-sql分析

pg 函数sfa_tmp_sleep()执行越来越慢                                                                                                                                                                                                                                

PgSQL · 源码分析 · PG中的无锁算法和原子操作应用一则

原子操作概述 近年来随着服务器上CPU核数的不断增加,无锁算法(Lock Free)越来越广泛的被应用于高并发的系统中.PostgreSQL 做为世界上最高级开源数据库也在9.5时引入了无锁算法.本文先介绍了无锁算法和原子操作在PostgreSQL中的具体实现, 再通过一个Patch来看一下在PostgreSQL中是如何利用它来解决实际的高并发问题的. 无锁算法是利用CPU的原子操作实现的数据结构和算法来解决原来只能用锁才能解决的并发控制问题. 众所周知,在一个并发系统中特别是高并发的场景下,锁

如何检测、清理Greenplum垃圾 - 阿里云HybridDB for PG最佳实践

标签 PostgreSQL , Greenplum , HDB for PG 背景 Greenplum通过多版本支持数据的删除和更新的并发和回滚,在删除数据时(使用DELETE删除),对记录的头部xmax值进行标记.在删除记录时,对记录的头部进行标记,同时插入新的版本. 这一就会导致一个问题,如果用户经常删除和插入或更新数据,表和索引都会膨胀. PostgreSQL是通过HOT技术以及autovacuum来避免或减少垃圾的.但是Greenplum没有自动回收的worker进程,所以需要人为的触发

ZFS snapshot used with PostgreSQL PITR or FAST degrade or PG-XC GreenPlum plproxy MPP DB&#039;s consistent backup

上一篇BLOG介绍了一下ZFS的使用, 以及zfs的log和l2arc机制带来的读写性能提升. 本文将介绍一下ZFS的另一大功能, snapshot和clone. 结合PostgreSQL的PITR来使用, snapshot可以替换基础备份. 从而提高PostgreSQL恢复到过往时间点的速度(就近选择snapshot). 同时还可以作为 PG-XC GreenPlum plproxy 等并行数据库解决方案的全局一致性备份, 对于pg-xc有冻结事务的功能, 所以可以不停库实现一致性备份, 对于

azure-VM的snapshot是存储在哪里?谁知道‘、、、、

问题描述 VM的snapshot是存储在哪里?谁知道'.... 大家好!!!!!VM的snapshot是存储在哪里?谁知道???谢谢!!求解答!! 解决方案 也是以增量的vhdx的形式存在azure blob里的. 解决方案二: 虚拟硬盘的快照,是存在于硬盘上的.无论是不是在虚拟机中使用. 一般来说,快照时将当前使用的虚拟盘的读写做一个中断,以后对此虚拟盘的读写,会以"差分"的方式写到另外一个文件(可以想象成一个系数矩阵) 比如下图,原始盘是"Win2008R2.vmdk&q