iihero@CSDN

在执行大量写操作的系统上，调优检查点对于获得良好的性能至关重要。然而，检查点是我们经常发现混淆和配置问题的地方之一，无论是在社区邮件列表中，还是在为客户提供支持和咨询期间。这篇文章旨在解释检查点是什么——目的和数据库如何实现它——以及如何调优它们。注:这是在2016年最初原作者写的一篇博文的更新版本，更新后反映了PostgreSQL配置的各种变化。否则，总体调优方法基本保持不变。现在您应该了解了检查点的目的，以及调优检查点的基本知识。

下边的内容来自技术博客，感觉内容真心不错。完整的介绍到这里，与大家共享。最近，在调试一个CREATE INDEX操作的性能问题时，我被提醒，PostgreSQL在执行并行查询(包括并行索引创建)时可能会产生临时文件，因为每个工作进程都有自己的内存，可能需要使用磁盘空间来排序或散列表。所以，为了尝试加快索引创建，我认为使用tmpfs将这些临时文件直接移动到内存中是有益的，并想测试这个理论，写这篇博客文章:-)

在数据库的使用过程中，有很多场合是要自行去构造大规模数据，以供测试、性能功能验证使用。PostgreSQL - 大规模随机数据生成方法里介绍了PostgreSQL中生成大规模随机数据的方法。这种方法，生成数据比较快，但是数据大多是对业务场景没有太大意义的数据，或者说对业务不够友好。本文再介绍通过一些第三方库，插入一些相对友好的随机数据。那就是通过Python faker库来生成数据。Faker是一个Python软件包，可为您生成伪造数据。

直观来讲，数据库是典型的以空间换时间的思路去提高数据检索的效率。我们先把数据“入”进去，组织好，建好索引，都为了什么？相当大一部分只不过是为了最终能快速得到查询的结果。当然这又引发了好多子项，比如，怎么“入”得快而又不发生冲突，怎么在相对少的资源的情况下得到相同的效果。这其间，空间的膨胀，几乎不可避免，重要的是，膨胀是否理？是否在物理资源的承受范围之内？前边提到了PostgreSQL的空间膨胀，这篇短文将提到ASE中比较典型的空间膨胀现象，以及如何有效的去避免它。

PostgreSQL数据库，由于其自身特有的MVCC机制，它没有自己的Undo Log。更新操作相当于一个删除叠加一个插入操作，反映在表数据文件当中就是内部的一条新增记录，加上原有记录的删除。那些已被删除的元组(死元组)所占的空间如果得不到及时的回收，那么表数据文件所用空间将会不断膨胀，查询及其它CUD操作也会变慢，直到系统不可承受。这就是AutoVaccum存在的原因。

昨天，一朋友向我咨询Sybase ASE中定长字符串类型的行为，说他们的客户反映，同样的char类型的数据，通过jdbc来查，Sybase库不会带空格，而PostgreSQL会带。而varchar(N) NULL与NOT NULL，行为也一致，无论是直接取值，还是拼接后再取值，都留一个多余的字符(长度够宽的话)。这样来看，只要不在SQL语句里头拼接，那么char(N) NULL或NOT NULL，两种数据库的行为应该是一样的。如果是Not Null的char(N)，则不会截掉空格，无论是否与其它字符拼接。

HANA中如何快速生成大批量随机数据？ 让你快速弄懂并熟悉。

try {// 连接到数据库)";= null) {发现 PostgreSQL11和12及以后的版本，插入到表t1中的记录值不一样。a48(3 rows)a------4848.148.9(3 rows)这个问题如何分析？从驱动层来看，发送过去的内容或指令应该是一样的。

在实际使用中，通过HANA的admin控制台，确实可以得到很多重要的信息。但有的时候不如人愿，你需要提供相应的SQL语句得到具体的信息。将上述统计信息纳入日常监控，就可以对数据库表的使用情况了如指掌。结合表的记录条数信息。非常有助于HANA数据库的日常监控与维护。比如，我要得到所有的行表的内存及磁盘占用信息；我需要得到所有列表的内存及磁盘占用信息。实际上HANA是有这些统计的SQL语句的。

一个小小的jdbc驱动，HANA数据库为它提供的功能还是比较强悍的。在关键的时候，能起到非常大的作用。如果只是一些非常简单的连接性需求，甚至不需要任何第三方工具，直接使用简单的命令行就可以顺利完成。

SAP HANA Cloud中引入了用户自定义的应用锁。这是用于自定义应用程序的，可以通过调用过程获得或释放。详细的锁的功能介绍见文档：sap-hana-cloud-sap-hana-database-administration-guide/locks[3]

针对PostgreSQL进行压缩，有很多相关的工具。有同学又要问了，为何还要再搞一个？比如，pgbench, sysbench之类的，已经很强大了。是的，它们都很强大。但有时候，在一些特殊的场景，可能自己构造一个更能接近真实的生产环境。这里，我半写，半借助于ChatGPT，搞出一个代码片段来模拟启动一段多线程并发SQL请求，作用于PostgreSQL数据库。然后，你可以对请求执行完以后的结果进行观测，尤其是表膨胀，受影响记录条数之类的。基于此，我们还可以进行持续改造，快速用于工作之中。

最近在CF (Cloud Foundry) 云平台上遇到一个比较经典的案例。因为牵扯到JVM （app进程）与数据库连接两大块，稍有不慎，很容易引起不快。在云环境下，有时候相互扯皮的事蛮多。如果是DB的问题，就会找DB相关部门。关键是如何自证。涉及到职场生存法则，大家都不愿意去背锅，谁背锅，意味着谁要担责。下边我们看看这个案例。有的时候，问题不是孤立存在的，从各个层面进行分析，逐个排错，最后还是能找到出问题的原因。如何规避此类事件再次发生，只能进一步加强监控。

就是说，你不能在远程直接通过ASE的isql命令行连接cloud上的数据库，必须通过特定的tunnel。曾经，经常遇到有人问，Sybase (ASE， 国内基本上把以前的Sybase ASE数据库简称为Sybase数据库, 现在官方已经叫做SAP ASE，在我看来无所谓。基于上述需求，我开源了一个短小的ase.isql命令行工具，完全java实现，基于现有的Sybase Jconn JDBC驱动。于是，既能提供日常操作，同时又能调用SQL脚本用于远程执行的Java isql客户端，就有存在的必要了。

这里简要介绍一下PG中的Copy以及\Copy快速加载数据的基本用法及注意事项。同时也比较了Batch Insert与Copy之间的性能差异。它们在PG日常维护与使用的场景中经常要用到。

创建file_fdw 扩展创建外部表(file_fdw)24 empno int, -- primary key, 此处不能加外键7 age int,像普通表一样访问外部表使用元命令 \des 和 \det 查看库中有哪些外部表和外部服务器模块提供了外部数据包装器，它可以被用来访问存储在外部PostgreSQL服务器中的数据。这个模块提供的功能大体上覆盖了较老的dblink模块的功能。但是提供了更透明且更兼容标准的语法来访问远程表，并且可以在很多情况下给出更好的性能。

没想到Sybase ASA现在也做得越来越大了，几年前，不过二三十兆的样子，现在ASA 12.0.1安装完以后，差不多400M.可是其中的Sun目录(jvm)就占了差不多100M。如果直接删掉这个目录，那么应用就跑不起来。比如比较常用的dbisql.exe, scjview.exe, mlmon.exe等等。有两种办法可以手动掉这个庞大的Sun目录。1. 设置用户环...

SAP云应用程序编程模型(CAP)是一个语言、库和工具框架，用于构建企业级服务和应用程序。它引导开发人员沿着一条经过验证的最佳实践的“黄金之路”前进，并为反复出现的任务提供大量开箱即用的解决方案。我们这就来看看SAP BTP的CAP到底提供了哪些便利。也以PostgreSQL作为数据库的后端为例 ，看看如何简单的应用CAP相关技术和技术栈。CAP不仅可以快速生成云上的应用，也可以生成本地可以运行的应用。CAP框架的特点是混合了经过验证并被广泛采用的开源和SAP技术，如下图所示。

refer to: https://www.postgresql.org/docs/14/datatype.html为避免一些不必要的麻烦，不要用关键字去定义数据库对象的名字。它会给PG的解析造成潜在的问题。尤其是在生产环境中，不要给自己制造麻烦。E前缀，C风格的转义符位串常量，二进制使用B前缀，16进制采用X作前缀3、简单SQL3.1、基础SQL建表删表更改表see: https://www.postgresql.org/docs/14/sq

PostgreSQL中对于稍长一点的列，直接使用了TOAST表来存储，默认是会对表中的数据进行压缩的。关于TOAST, 以后或有时间专门做简单介绍。这是一个很有意思的话题。尤其是在我们做物理设计和空间大小评估的时候。这里以table相关size为例，重点介绍一下。如何计算对应的toast表相关的空间大小？数据库中表的物理大小。