Chan Revival Sky

目录莱瑟塔档案 - 地底爬虫人访谈简介莱瑟塔档案 - 地底爬虫人访谈实录I莱瑟塔档案 - 地底爬虫人访谈实录IIthe lacerta files 爬虫族档案II（The Lacerta File II）前言我再次重申以下文章绝对真实非虚构。 我在2000 年4 月27 日与爬虫生物「勒斯塔」第二次访谈过程中，用收录机录制了三卷原始录音带。 应勒斯塔要求，31 页原始文稿中的问答经修订和缩减，一些问题部分浓缩或作了校正，但保证可以撷取出讯息和重要性。 访谈这部分中没有完全提及或部分提及的，主要涉及个人事务，超常示范，爬虫族的社会系统以及外星科技及物理。 第二次会见日期和时间的变更可能是公布第一份手稿后，出于我个人的观察和监督。 尽管勒斯塔建议我保持身份隐匿而我也做了所有尝试，可在文件公布后仅两天，各种不同的事件还是发生了。 请别把我想成妄想狂，不过我相信访谈的公布吸引了官方或某组织的注意。 直到那时我还是认为，相信自己跟从理解了该陈述的那些人只不过都是说笑者而已。 不过自从一月的事件发生以来，我开始转变了看法。 这开始于我家电话好几个小时的失灵。 当恢复以后我打电话时，里面发出静静的回声、奇怪的敲击声和呼呼声。 从表面上找不出什么毛病。 整个晚上，我电脑上的重要资料都从硬碟消失了。 检测程序报告「有缺陷磁区」，而极为奇怪的是，涉及到的只是插图和访谈的全部文字材料。 这些「缺陷磁区」还包括了我实地研究的一种超自然现象材料（所幸的是软碟中留有备份）。 此外，我纯偶然地在一个隐藏目录中发现了一些隐藏资料。 目录和资料名为「E72UJ」。 我一个电脑专家朋友对这个名称毫不知晓，当我要给他看的时候，目录却消失了。 一天晚上，我寓所的门大开着，电视也开着——而我绝对确定自己已经关上了电视。 一辆有英国标识和印有全欧超市连锁字样的小型货车停在我房门前。...

目录莱瑟塔档案 - 地底爬虫人访谈简介莱瑟塔档案 - 地底爬虫人访谈实录I莱瑟塔档案 - 地底爬虫人访谈实录IIthe lacerta files 爬虫族档案I（The Lacerta File I）几周前，一个网友问我可否翻译一份关于UFO 真相、外星人和关于我们人类真实历史的档案，他说从一个瑞典朋友Ole K.（当然不是全名）那儿接到了这份吸引人的档案，其声称采访了一个非人类的爬虫族（Lacerta）存在体。 他表明这份档案包含了关于UFO 和外星人绝对真实的内容（如果有人针对每条「UFO 的绝对真相」，仅给我100 马克的话，我也会变成富翁的。）我知道自己在网上不仅是作为一个UFO 的强烈相信者，而且也是一个对物理和观察知道很多的有智慧的青年。 所以当我头一次读到这份名叫「爬虫族档案1」怪异文件的时候非常吃惊，并且我问他自己是否真的相信这篇科学假想小说。 他非常确定并且说，Ole K. 是他的私人朋友，他绝不会说谎。 关于证据，他告诉我他已经通读了整篇文稿，并且看了Ole K. 在介绍里提到的画和磁带。 我猜每位「正常」的UFO 研究者都会立刻删掉这份档案，但是我却「疯狂地」要翻译它。 我告诫过他我的英语水准不怎么样，不过他确信我能做好，因此我就试着尽可能通俗易懂地翻译它。 这便意味着我并不对档案内容负责，也就并不相信它是真实的。 只意味着我为朋友做了一件翻译工作。 为了便于阅读，我用了些括弧，我不能肯定自己是否用了恰当的辞汇，但我希望你们能够看懂。 我的个人意见（翻译完这篇离奇的文稿大约一周后）是，这篇文稿是一篇很好的科学幻想小说而不是事实或真相。...

目录莱瑟塔档案 - 地底爬虫人访谈简介莱瑟塔档案 - 地底爬虫人访谈实录I莱瑟塔档案 - 地底爬虫人访谈实录IIthe lacerta files 简介1998 年一位地底的年轻雌性爬虫人到地表森林（瑞典）采集资料，无意中拜访一位离群索居于森林小木屋的主人EF，几次的拜访后，爬虫人向他表露真实身分（注：爬虫人具有诱导人类的精神力，能使人类把爬虫人看成是正常普通的人类外表），后来EF 向他朋友Ole K. 透露，并安排Ole K. 与爬虫人分别于1999-12-16、 2000-04-27 的两次访谈。 6,500 万年前两支外星种族－－「类人族」与「爬虫族」（与地底爬虫族无关）为争夺地球铜矿的毁灭战导致200 年的「核子冬天」造成恐龙灭绝，200 年后幸存的物种中出现了一种特殊的小型先进恐龙（1.5 公尺高），有类人的特征－－地底爬虫人的祖先。 经过几千万年的演化，在1,000 万年前，爬虫人透过基因改造成与现今差不多的稳定外貌形体，并已在太阳系其他行星殖民。 150 万年前另一支外星种族来到地球，改造人类祖先－类人猿，经过2 万3 千年七次的改良，最初拥有科技的进化人类存在于70 万年前，后来外星人决定终结他们的首次创造，然后加速了第二次更好的试验系列，接着一次又一次。 最后一次是开始于8,500 年前的第七次文明创造至今。 5,000 年前地底爬虫族与外星人发生长久争战以来的最后一场战役，几十年后外星人出于不明原因离开了地球，他们会再返回地球毁掉本次文明吗？ 另外，爬虫人还提及几次的外星飞碟坠毁事件（包括罗斯威尔事件），美国政府透过对失事飞碟的研究与别有居心的外星人的合作，制造了三角形的飞行器。 14 个在地球活动的外星族类、地底爬虫族、人类政府间相互的竞合对人类与地球的未来会有什么影响？ 信不信由你，就当作故事看吧～

谈谈PostgreSQL数据库的表膨胀什么是PostgreSQL数据库的表膨胀？PostgreSQL 数据库的 表膨胀，简单来说，就是表的数据存储空间变得比实际需要的要大。膨胀现象发生时，虽然表中的数据量没有显著增加，但数据库占用的磁盘空间却比实际数据量大很多。这种现象会影响性能，导致查询速度变慢，并且浪费磁盘空间。 为什么会产生表膨胀？表膨胀的主要原因通常有以下几个： 更新和删除操作导致的“死元组”： PostgreSQL 在执行更新（UPDATE）或删除（DELETE）操作时，不是直接修改或删除原来的数据，而是将旧数据标记为“死元组”，然后在新位置插入新数据。这意味着，原来数据的位置还是被保留在磁盘上，直到进行清理（VACUUM）。如果没有及时执行 VACUUM 操作，死元组就会不断积累，导致表膨胀。 MVCC（多版本并发控制）： PostgreSQL 使用多版本并发控制（MVCC）来处理事务。每个事务都会为每一行数据创建一个版本（tuple），并保持旧版本的数据直到事务完全结束。由于事务未提交或者被回滚时，旧版本不会立即清理，造成空间浪费。 索引膨胀： 索引在插入、删除、更新数据时，也会产生膨胀。特别是在大量数据删除或更新后，索引结构没有及时整理，导致索引占用更多空间。 自增列： 对于包含自增列（如 serial 或 bigserial）的表，删除某些数据后，自增的序列号并不会回收，这可能会导致空间浪费。 检查表膨胀情况的两种方法方法一 查询pg_stat_user_tables、pg_total_relation_size表12345678SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size, ...

PostgreSQL的pageinspect插件安装编译1234su - rootcd /home/postgresql-12.11/contrib/pageinspectmakemake install 安装pageinspect1234567891011psqlcreate extension pageinspect;CREATE EXTENSIONselect lp as tuple,t_xmin,t_xmax,t_field3 as t_cid,t_ctid from heap_page_items(get_raw_page('tbl',0)); tuple | t_xmin | t_xmax | t_cid | t_ctid -------+---------+--------+-------+-------- 1 | 6342159 | 0 | 0 | (0,1)(1 row)

使用yum下载rpm包使用yum下载rpm包的命令是： 1yum install --downloadonly --downloaddir=/tmp <package-name> 请注意，如果下载的包包含未满足的依赖关系，yum将会下载所有依赖关系的包，但不会进行安装。 另外，对于CentOS/RHEL 6或更早期版本，需要安装一个名为yum-plugin-downloadonly的yum插件，才能使用–downloadonly命令选项。

PostgreSQL运维常用命令查看当前连接的用户名12select * from current_userselect user 给普通用户授权1GRANT USAGE ON SCHEMA sch_user TO usr_user; 查询表大小，不含索引12345db_database=> select pg_size_pretty(pg_relation_size('sch_admin.tab_table0')); pg_size_pretty ---------------- 8192 bytes(1 row) 查询表大小，含索引12345db_database=> select pg_size_pretty(pg_total_relation_size('sch_admin.tab_table0')); pg_size_pretty ---------------- 24 kB(1 row) 查WAL文件12345678910 select *,size/1024/1024 as "MB" from pg_ls_waldir(); name | size | modification | MB --------------------------+----------+------------------------+---- cleanup.log | 463 | 2022-07-28 09:45:36+08 | 0 000000010000000800000011 | 16777216 | 2022-08-24 10:10:01+08 | 16...

适用于Oracle数据库 - 企业版 - 版本10.1.0.2至10.2.0.4 [10.1至10.2]Oracle数据库 - 企业版 - 版本12.1.0.2至12.1.0.2 [12.1]Oracle数据库 - 企业版 - 版本11.2.0.4至11.2.0.4 [11.2]Oracle数据库 - 企业版 - 版本11.1.0.7至11.1.0.7 [11.1] 目标以下说明描述了如何在不关闭主（生产）数据库的情况下，使用RMAN复制逐步创建物理备用数据库的过程。Database Name :- primPrimary db_unique_name :- primstandby db_unique_name :- stdbyPrimary Hostname :- raca.idc.oracle.comstandby Hostname :- core1.idc.oracle.com 解决方案 启用强制日志记录。 创建备用重做日志（SRL）。 在主数据库的参数文件中做出适当的更改。 备份数据库，包括数据文件、归档日志和控制文件，以便备用，并将备份复制到备用服务器。 为备用数据库创建参数文件。 从主数据库到备用数据库建立连接。 将备份移动到备用服务器。 和 9. 启动备用实例。 使用RMAN复制命令创建备用数据库。 创建SRL。 启动MRP（管理恢复进程）。 验证是否正确地将日志发送并应用到备用数据库。 步骤1：在主数据库上启用强制日志记录。 1SQL> ALTER DATABASE FORCE LOGGING; 注意：如果不存在，请创建密码文件，同时检查是否已启用归档。 步骤2：在主数据库上配置备用重做日志。 1234SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 3...