Maclean’s Oracle Database Tech Blog Archives

  • PostgreSQL中恢复被误删除的行数据

    如果自己搞不定可以找诗檀软件专业PostgreSQL数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 : 13764045638   QQ号:47079569    邮箱:[email protected]   在PostgreSQL中如果误删除了行数据 要如何恢复呢? 例如下面的例子:   postgres=# create database test3; CREATE DATABASE postgres=# \c test3 您现在已经连接到数据库 “test3”,用户 “postgres”. test3=# create table novels(name varchar(100), id int); CREATE TABLE test3=# select * from pg_database where datname=’test3′; oid | datname | datdba | encoding | datcollate | datctype | datistemplate |…

  • postgresql之vacuum

    来源:https://www.cnblogs.com/daduxiong/archive/2010/10/11/1847975.html 数据库总是不断地在执行删除,更新等操作。良好的空间管理非常重要,能够对性能带来大幅提高。在postgresql中用于维护数据库磁盘空间的工具是VACUUM,其重要的作用是删除那些已经标示为删除的数据并释放空间。 VACUUM语法结构: VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ table ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, …] ) ] ]   postgresql中执行delete操作后,表中的记录只是被标示为删除状态,并没有释放空间,在以后的update或insert操作中该部分的空间是不能够被重用的。经过vacuum清理后,空间才能得到释放。可惜的是vacuum工具不能够对相应的索引进行清理,唯一的办法就是手动去重建相应索引(令人非常不爽,而高兴的是在9.0之后有所改进)。 Full Vacuum full vacuum与单纯的vacuum还是有很大的区别的。vacuum只是将删除状态的空间释放掉,转换到能够重新使用的状态,但是对于系统来说该数据块的空闲空间并没有反应到系统的元数据中。类似oracle中高水位标记并没有下降。Full vacuum将会使空间释放的信息表现在系统级别,其实质是将当前删除记录后面的数据进行移动,使得整体的记录连贯起来,降低了“高水位标记”。 Vacuum analyze analyze的功能是更新统计信息,使得优化器能够选择更好的方案执行sql。oracle中同样也有analyze,作用也相同,目前更多的使用的是dbms_stats包。统计信息收集和更新对于系统性能来说非常重要,与oracle维护类似,通常可以通过采用手动或者定制任务的方式。也有不同,oracle在进行imp后自动的对相应数据对象进行统计信息的收集和更新,而postgresql的恢复过程还没有集成到里面,需要手动去执行。 自动vacuum配置 自动vacuum的执行直接由autovacuum参数值决定,默认值是on。 log_autovacuum_min_duration:默认值为-1,关闭vacuum的日志记录,配置为0表示记录autovacuum的所有log。参数设置为正整数表示对于在此时间内完成的vacuum操作不进行log记录,如果没能完成,则记录超出时间内的log。该参数对于了解对象执行vacuum操作的时间非常有用。 autovacuum_max_workers:最大的autovacuum进程的数量,默认值为3。参数大小的配置主要依据系统当前负载和资源。对于系统负载较重的情况,建议开启少量的进程为好,反之,空闲时间可以采用较大值的方式。 autovacuum_naptime:检查数据库的时间间隔。默认为1分钟。 autovacuum_vacuum_threshold:参数表示执行autovacuum操作之前,对单个表中记录执行DML操作的最少行数。达到该行数时自动激活autovacuum操作。该参数针对数据库中的所有表,还可以通过对单个表配置不同的值来改变相应表的autovacuum操作。默认值是50。 autovacuum_analyze_threshold:激活自动analyze操作的最小行数。默认值50。机制与上面相同。 autovacuum_vacuum_scale_factor:该参数采用百分比的方式设定阀值。默认值为20%,当DML涉及的数据量大于某个表的20%时,自动触发autovacuum操作。同样可以通过对单个表进行阀值设定。 autovacuum_analyze_scale_factor:机制与上面相同,到达阀值是自动激活analyze操作。同样可以通过对单个表进行阀值设定。…

  • PostgreSQL 之 autovacuum的触发条件

    本文链接:https://blog.csdn.net/pg_hgdb/article/details/79707659 autovacuum 是 postgresql 里非常重要的一个服务端进程,能够自动地执行,在一定条件下自动地对 dead tuples 进行清理并对表进行分析 autovacuum参数控制 autovacuum 进程是否打开,默认为 “on”   根据postgresql.conf相关配置,理解autovacuum会在两种情况下会被触发: 1.表上(update,delte 记录) >= autovacuum_vacuum_scale_factor* reltuples(表上记录数) + autovacuum_vacuum_threshold   说明: 清理基本阈值是autovacuum_vacuum_threshold 清理的缩放系数是autovacuum_vacuum_scale_factor 元组的数目是 reltuples 可以从统计收集器里面获取,参考sql如下: SELECT reltuples from pg_class WHERE relkind = ‘r’ AND relname = ‘test’;   2.指定表上事务的最大年龄配置参数autovacuum_freeze_max_age,默认为2亿,达到这个阀值将触发 autovacuum进程,从而避免 wraparound。 表上的事务年龄可以通过 pg_class.relfrozenxid查询。 –例如,查询表 test_1 的事务年龄 select relname,age(relfrozenxid) from pg_class where relname=’test_1′;…

  • PostgreSQL源码分析AutoVacuum机制之autovacuum launcher

    来源:http://mysql.taobao.org/monthly/2017/12/04/ 背景 根据之前月报的分析,PostgreSQL中的MVCC机制(详见月报)同时存储新旧版本的元组,对于经常更新的表来说,会造成表膨胀的情况。为了解决这个问题,PostgreSQL 引入了VACUUM和ANALYZE命令,并且引入了AutoVacuum自动清理。 在PostgreSQL中,AutoVacuum自动清理操作包括: 删除或重用无效元组的磁盘空间 更新数据统计信息,保证执行计划更优 更新visibility map,加速index-only scans (详见文档) 避免XID 回卷造成的数据丢失(详见文档) 为了实现自动清理,PostgreSQL引入了两种类型的辅助进程: autovacuum launcher autovacuum worker 本文主要分析autovacuum launcher进程相关操作,autovacuum worker比较复杂和重要,我们将在下期月报详细分析。 autovacuum launcher autovacuum launcher 进程可以理解为AutoVacuum机制的守护进程,周期性地调度autovacuum worker进程。 相关参数 autovacuum launcher 进程在postgresql.conf文件中的相关配置参数(支持对每个表单独配置参数,方法见文档)如下: track_counts:是否开启统计信息收集功能。 autovacuum:是否启动系统自动清理功能,默认值为on。 autovacuum_max_workers:设置系统自动清理工作进程的最大数量。 autovacuum_naptime:设置两次系统自动清理操作之间的间隔时间。 autovacuum_vacuum_cost_limit:声明将在自动VACUUM操作里使用的开销限制数值。 autovacuum_vacuum_cost_delay :声明如果超过了上面的开销限制,则需要延迟清理的时间。 autovacuum_freeze_max_age:设置需要强制对数据库进行清理的XID上限值。 autovacuum_multixact_freeze_max_age:设置需要强制对数据库进行清理的multi XID上限值。 因为AutoVacuum依赖于统计信息,所以只有track_counts=on 且autovacuum=on 时,PostgreSQL才启动autovacuum launcher 进程。 autovacuum launcher 进程会周期性地创建autovacuum worker 进程,最多能够创建autovacuum_max_workers个autovacuum worker 进程。我们将会从下面二个方面来分析autovacuum launcher: 执行周期,即autovacuum…

  • PostgreSQL 参数列表

    postgres=# SHOW all; name | setting | description —————————————-+—————————————————–+——————————————————————————————————————————- allow_system_table_mods | off | Allows modifications of the structure of system tables. application_name | psql | Sets the application name to be reported in statistics and logs. archive_cleanup_command | | Sets the shell command that will be executed at every restart point. archive_command | (disabled) |…

  • PostgreSQL PG 数据文件灾难恢复 – 解析与数据pg_filedump

    作者 digoal 日期 2017-03-10 标签 PostgreSQL , 数据文件 , pg_filedump , 安全 , TDE 背景 俗话说常在河边站哪有不湿鞋,作为一名战斗在一线的DBA或者开发者,可能有遇到过磁盘损坏,磁盘阵列损坏,如果有备份或者备库的话,还好。 如果没有备份,或者没有备库(通常有一些小型或者创业型的企业),那么遇到磁盘损坏或者其他原因(比如掉电文件系统损坏),导致数据库的数据文件并不完整时,如何从有限的资料中找出数据呢? 比如PostgreSQL,如果读到坏块,会报块不可读的错误,这种情况下通过设置zero_damaged_pages=on可以跳过损坏的数据块。 如果连元数据都损坏了,又或者坏了一些磁盘,只有某些表空间被幸免于难,这些情况下你的数据库都已经无法启动时,如何能从有限的数据文件中找回数据呢?     数据文件解析pg_filedump     pg_filedump是PostgreSQL社区托管的一个项目,类似于pg_xlogdump,不需要开启数据库,可以直接从数据文件中将数据dump出来。 pg_filedump实际上可以DUMP 堆表、索引数据文件,控制文件的内容。(从pg_filedump引用的头文件也能看出端倪) 安装很简单     git clone git://git.postgresql.org/git/pg_filedump.git cd pg_filedump export PATH=/home/digoal/pgsql9.6/bin:$PATH make ; make install 命令帮助如下,通常来说,你只需要指定需要DUMP的文件即可。 如果文件的块头损坏了,那么你可以手工指定一些信息,包括块大小,段大小,解析哪个块,根据什么格式解析(字段类型列表)等。     pg_filedump [-abcdfhikxy] [-R startblock [endblock]] [-D attrlist] [-S blocksize] [-s…

  • 那年的海

      我追寻的 是那一年 老张江地铁站 地铁从地下穿梭到地面那一霎那阳光照射的光明,是那一年在冲绳不知名海滩边巧遇的蓝色海水;可能是季节的关系,那算是我看过最蓝的海。            

  • PRM支持恢复ORACLE 12cR1/12cR2/18C/19C 可拔插数据库

    https://zcdn.parnassusdata.com/pdb.mp4   PRM DUL支持 ORACLE 12cR1,12cR2,18C,19C 容器数据库 可拔插数据库 PRM DUL now supports oracle 12cR1,12cR2,18C,19C Container Database Pluggable database PDB/CDB 12CR1 PDB TEST , works! 12cR2 PDB TEST , works! 18c PDB TEST , works! 19c PDB TEST , works! 所有版本的PDB,均可正常读取!

  • Red Hat Enterprise Linux 生命周期

    Red Hat Enterprise Linux 5、6 和 7 红帽提供的订阅服务涵盖 Red Hat Enterprise Linux 每个主发行版本的全部四个生命周期阶段 — 这四个阶段分别为完全支持阶段、维护支持 1 阶段、维护支持 2 阶段,以及延长生命周期阶段。 Red Hat Enterprise Linux 5、6 和 7 都提供 10 年支持(除非在以下的例外章节中有其他说明),并分为完全支持阶段、维护支持 1 阶段、维护支持 2 阶段,以及后续的延长生命阶段。另外,Red Hat Enterprise Linux 5 和 6 的用户还可以购买“延长生命周期支持(Extended Life-cycle Support,简称 ELS)”订阅服务,这可以把有限的订阅服务扩展到维护支持 2 阶段以后。 例外 在 Red Hat Enterprise Linux version 7 的生命周期内,红帽对 Red…

  • flutter pub get缓慢解决方案

    flutter pub get缓慢解决方案 windows set PUB_HOSTED_URL=https://pub.flutter-io.cn set FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn flutter pub get Linux MACOS export PUB_HOSTED_URL=https://pub.flutter-io.cn export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn flutter pub get