关于Insert的问题，可能在一些场景中会有完全不同的期望和结果，在日常工作使用的库中，需要表在Logging模式，必要时需要一些索引 但在数据迁移中，可能为了提高速度，索引就需要考虑重建了。 我做了一些场景的测试，并且做了详细的数据比对。 第一种场景：table在nologging模式下。并且表中没有索引， 在插入不同数据量的时候，生成的redo和响应时间都有一定的幅度提升。 比如插入13240331条记录时，响应时间为63秒，生成323219520bytes(300多M)的redo. nologgin
【DB笔试面试792】在Oracle中，ORA-01578和ORA-26040--NOLOGGING操作引起的坏块-错误解释和解决方案.
--==================================================
在有些情况下，对于表段和索引段可以采用记录日志的模式，也可以使用不记录日志的模式。如在对表段、索引段使用数据泵导入时，可以
（一）NOLOGGING操作引起的坏块（ORA-01578和ORA-26040）简介
Oracle的Hint是用来提示Oracle的优化器，用来选择用户期望的执行计划。在许多情况下，Oracle默认的执行方式并不总是最优的，只不过由于平时操作的数据量比较小，所以，好的执行计划与差的执行计划所消耗的时间差异不大，用户感觉不到而已。但对于书写操作大数据量的SQL而言，其SQL的书写则需要先了解一下执行计划是否最优或满足生产需要。通常当从开发环境迁移到生产环境下时，往往会出现此类情况。
修复由于主库NOLOGGING操作引起的备库ORA-01578和ORA-26040错误
在Oracle中，关键字NOLOGGING、APPEND和PARALLEL提高DML性能方面有什么差别？
在升级的过程中，可能需要准备一些额外的脚本，比如说做数据迁移的时候为了考虑性能，需要做如下的额外工作： 1.将部分表置为nologging 2.将部分index置为nologging 3.将部分foreign key constraint置为disable 4.将部分trigger 置为disable 在完成数据升级后，再置为logging,enable状态。 但是在准备脚本的过程中，总是为这些小脚本而头疼，可能在升级前临时增加了一些表或者取消了部分表。或者有了其他的变更，维护这些脚本就显得有些体力工作了。
快速插入数据可以指定APPEND提示，需要注意的是，在NOARCHIVELOG模式下，默认用了APPEND就是NOLOGGING模式的。在ARCHIVELOG下，需要把表设置程NOLOGGING模式。如：
黄廷忠（网名：认真就输） 云和恩墨技术专家 个人博客：http://www.htz.pw/ 测试环境：OS:RHEL 5.4 X86 DB:10.2.0.4 归档模式 下面是测试结论，此结论只是在本测试环境有效。 1，ctas与create table后insert语句产生的redo是差不多的。 2，ctas生成的undo远远小于create table and insert方式。 3，ctas生成的undo与create table后insert /*+ append */差不多。 4，ct
我们知道,Nologging只在很少情况下生效 通常,DML操作总是要生成redo的
在生产环境中，做数据迁移需要考虑很多的可能性和场景，尽量排除可能发生的问题。我自己总结了下，大体有如下需要注意的地方。 1）充分的测试，评估时间，总结经验，提升性能 在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。 2）完整的备份策略 热备甚至冷备 在数据迁移之前进行完整的备份，一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份
某普通表T，由于前期设计不当没有分区，如今几年来的数据量已达9亿+, 空间占用大约350G，在线重定义为分区表不现实，故采取申请时间窗口停此表应用，改造为分区表。
存放大数据量的表，其表空间占用也比较大，删除数据后并不会自动释放这些记录占用的表空间，所以，即便表里面数据量很少，查询效率依旧很慢，所以，需要释放表空间。
iputb讨论链接: http://www.itpub.net/showthread.php?threadid=242761 我们看以下测试: SQL> archive log list Databa
作者 周天鹏 出品 沃趣技术 上月中旬，Oracle 正式宣布 Oracle Database 18c，配套的官方文档已可以在官网查看。但按照惯例，依然是Oracle Exadata抢得首发，
在Oracle中，如何修复由于主库NOLOGGING引起的备库ORA-01578和ORA-26040错误？
今天说的这个案例发生在年初，某银行的一个数仓系统整体性能不佳，其中还有个奇怪的问题就是，两个结构比较类似的表，用sqlldr加载4000万左右的数据，一个需要1.5小时，另一个就要4.5小时，这对一个跑批业务来说影响是非常大的。客户自查了挺长时间也没找到原因。
今天对表的update进行了性能测试，收获不小。在linux 64位的环境中测试， 数据量是按照40万左右的标准进行的测试。 SQL> select count(*)from test; COUNT(*) ---------- 411426 数据库在archive log 模式下。 没有考虑索引（没有添加索引),没有考虑执行计划优化的影响，为了保证每次执行的环境基本一致，每次执行sql语句之前都先清空buffer cache. 为了横向比较结果，缩小结果的误差，对表test使用了两条类似的sql
众所周知我们的Data Guard数据同步是基于日志流的。所以在主库执行nologging操作是不被允许的。这也就是为什么我们需要在配置Data Guard阶段需要使用Force Logging。但是这也会带来很多问题（SQL执行效率），例如：当我们使用数据泵进行迁移时我们希望最少停机时间完成，这时候我们就可能会考虑到以最小日志导入的方式以加快导入速度，然后重新同步备库。
灰度环境机器配置不好，二百多万数据十来分钟没有导完，产生大量归档日志。删除索引约束后可能要好点。数据量大有风险，可能会导致归档日志撑爆。
在本地的测试库中，本来空间就不足，结果创建了一个表有600多万条记录，想创建一个index. 物理段有340多M. 临时段大小有100M,结果想创建一个索引，总是报临时表空间不足的错误。 [ora11g@rac1 test]$ ksh test.sh "create unique index t_pk on t(object_id) tablespace pool_data nologging online;" create unique index t_pk on t(object_id) tables
若是批量处理海量数据的话通常都是很复杂及缓慢的，方法也很多，但是通常的概念是：分批删除，逐次提交。下面介绍一下提高DML语句效率的常用方法。
表可以按range，hash，list分区，表分区后，其上的索引和普通表上的索引有所不同，Oracle对于分区表上的索引分为2类，即局部索引和全局索引，下面分别对这2种索引的特点和局限性做个总结。 局部索引local index
oracle 常用命令大汇总(第一篇) 第一章：日志管理 1.forcing log switches sql> alter system switch logfile; 2.forcing checkpoints sql> alter system checkpoint; 3.adding online redo log groups sql> alter database add logfile [group 4] sq
Elapsed时间为20分钟，而DB Time为11461分钟，负载很大，很可能有异常的等待事件。每秒的事务数为349.9，比较大，下面查看等待事件：
系统中一些常用的监控都可以使用DDL触发器和系统触发器来实现。可以先创建一张记录DDL语句的表XB_AUDIT_DDL_LHR（由于该表记录数会很大，所以，需创建成按月自动分区的分区表），并创建合适的索引，然后创建存储过程用于插入DDL信息到该日志表中。最后再创建系统触发器就可以将DDL语句或系统事件的信息插入日志表中。下面详细说明DDL触发器和系统触发器的使用。
之前的一篇博客中提到，物化视图的全量刷新也是一种高可用性的体现，但是性能如何呢，下面来简单的测试一下。 首先需要创建一个函数,这个函数会计算当前session下的一些指标信息。比如redo的生成量。 CREATE OR REPLACE FUNCTION "GET_STAT_VAL" (p_name in varchar2) return number as l_val number; begin select b.value into l_val from v$statname a,v$
在生产库上经常发现执行计划中索引选择不合适导致查询效率低下的情况，针对这种情况，我们可以采用重新收集统计信息（或设定统计信息）、绑定执行计划、增加hint写法（修改代码或后台增加hint）等技术手段来优化查询，但这些方法往往有一些前提条件，比如说统计信息过大无法及时收集需要配置定时任务，绑定的执行计划也不是很理想，绑定变量的值不同不能使用一种hint写法等，这样的结果倒推必须进行索引整改，以提高更好的查询效率，但如果涉及的是一张很大的分区表，索引整改必须很慎重，不然调整不理想可能会引起严重的性能问题，因此，本文想根据这个问题提供一种分析思路和操作步骤，使分区大表的索引调整的操作可以考虑得更全面些，更有效达到理想的查询效果。
优化思路有：①采用绑定变量；②使用静态SQL；③采用批量提交或循环外提交；④根据功能，可以去掉PL/SQL块，采用直接一次性插入的方式来完成，SQL为“INSERT INTO T_YH_20170705_LHR SELECT ROWNUM FROM DUAL CONNECT BY LEVEL<=100000;”；⑤采用直接路径方式，例如，“CREATE TABLE T_YH_20170705_LHR AS SELECT ROWNUM X FROM DUAL CONNECT BY LEVEL<=100000;”；⑥采用NOLOGGING和PARALLEL的方式，例如，“CREATE TABLE T_YH_20170705_LHR NOLOGGING PARALLEL 8 AS SELECT ROWNUM X FROM DUAL CONNECT BY LEVEL<=100000;”。
在之前的博文中，讨论过一个根据分区键值发现性能问题的案例。90%以上的数据都分布在了一个分区上，其它的分区要么没有数据要么数据很少，这是很明显的分区问题。当然这个过程中也发现了分区的划分从开发角度和数据角度还是存在很大的差别，导致了分区的问题。 通过分区键值发现性能问题 http://blog.itpub.net/23718752/viewspace-1263068/ 发现了问题，以点带面，发现一些相关的分区表也有类似的问题，最后确认和分析后，发现收到影响的表有20多个，而且数据量都不小。 看来又得是一个
要想提高insert的速度，首先要知道什么影响insert慢，在执行insert的过程中产生redo和undo，要想提高insert的速度，在充分利用系统资源的条件下就要尽量减少insert产生的redo和undo，undo的大小没办法改变，但是我们可以改变redo的量。下面是提高insert方法。
启用IM列存储时，In-Memory FastStart通过将IMCU直接存储在磁盘上来优化IM列存储中数据库对象的数量，使数据库通过将列数据存储在磁盘上更快地打开。数据库在崩溃和恢复之后或在复制到其他Oracle RAC实例期间也可以从IM FastStart区域读取。 简介 当数据库实例重新启动时，IM列存储将被填充，这个过程可能是I /O密集型和CPU密集型的慢速操作。 启用IM FastStart时，数据库会定期将一列列数据保存到磁盘中，以便在实例重新启动期间更快的重新填充。 如果数据库在关闭后重
INTO MD_KPI_ACT_EMU_PRODUCT_MON_01 nologging
在平时的工作中，经常会有一些开发人员提出一些数据库相关的一些问题。可能问的最多的就是sql语句了。 按照一个标准的流程，开发提交的sql语句在完成一系列测试之后，在生产部署前，还需要dba来进行审核。如果是紧急的补丁，也一定不要漏了这个问题。 有时候是开发嫌麻烦，要不就是开发嫌dba麻烦，这个review的过程还是很必要的。 在之前的系统迁移中，印象比较深的一个例子就是，开发写了一个Pl/sql，在测试环境中因为没有大量的数据做测试，测试环境美发现任何问题，结果在生产环境部署的时候就直接提交给客户，dba没
在2017 OOW大会上，关于Oracle Database 12.2 数据库的新特性介绍仍然引人瞩目，会后公布了 Oracle VP Swonger的文档，我们在此进行重点新特性的解读，并把这个PP
墨墨导读：本文来自墨天轮用户投稿，详细描述Oracle分区表之创建维护分区表索引的步骤。
在生产环境中存在着大量的数据，和业务是密切相关的。比如系统中的某个业务流程出现了问题，如果想复现就会显得非常困难，甚至是不太可能的，比如电信系统中存在着大量的客户信息，相关联的表的数据量都基本在千万，亿级。 如果要抽取，是全量抽取还是增量抽取。全量抽取可行，但是实际操作起来也不现实，如果要在测试环境中复现，可能需要大量的存储空间，而且相比来说也显得有些浪费，同事对于数据安全也是很大的隐患，毕竟我们不愿意客户信息这么轻易的暴露出来。 如果增量的，问题的关键是怎么增量，比如从100万客户信息中抽取一个客户的信息
关于数据迁移，在之前也讨论过一些需要注意的地方，可能林林总总列了不少，都是在数据迁移迁移前和迁移时需要注意的。 http://blog.itpub.net/23718752/viewspace-1195364/ http://blog.itpub.net/23718752/viewspace-1254945/ 我在这些帖子的基础上进行更多的总结和补充。 数据库级的检查和建议 1)参数检查 有些参数是需要在数据迁移前临时做变更的，有些是性能相关的，需要考虑。 log_buffer在数据导入的过程中会有极高
DG搭建时，官方文档手册有明确提到要设置数据库为force_logging，防止有nologging操作日志记录不全导致备库应用时出现问题。 虽然是老生常谈的安装规范，但现实中总会遇到不遵守规范的场景，最近就在某客户现场遇到一则这样的案例，因为DG主库设置force_logging晚于DG搭建，导致备库出现坏块，使用dbv检查就表现为DBV-201错误。
聚簇因子是 Oracle 统计信息中在CBO优化器模式下用于计算cost的参数之一，决定了当前的SQL语句是否走索引，还是全表扫描以及是否作为嵌套连接外部表等。如此这般，那到底什么是聚簇因子，那些情况下会影响到聚簇因子，以及如何提高聚簇因子？本文将对此展开描述。
闪回数据库这个特性在很多Oracle DBA眼里就是鸡肋特性，因为谁会因为恢复数据而需要在主库闪回，最后可能丢掉更多的数据，这个观点没错。 但是如果是备库呢，这个特性就顺利成章的满足了绝大多数的恢复需求，无论你是truncate，还是一些drop table的操作都是可以轻而易举的恢复。所以更多的时候我们其实更偏爱于Data Guard基础上的这种数据恢复方式，而原本的逻辑备份exp,expdp，物理备份RMAN就显得有些臃肿了。 拿一个真实的小案例来说明，有一次因为数据查询的SQ
创建测试用表，DBA经常用到，通常都是基于dba_objects来创建的比较多。本文根据Tom大师的big_table进行了整理，供大家参考。
在测试环境中做了3轮数据迁移的演练，最终到了生产环境中，还是出现了不少问题，经过大半夜的奋战，终于是数据都迁移成功了。 1）共享存储的配置问题 共享存储使用NFS来共享存储，但是在实际操作中发现配置出了问题，原因是因为两台服务器上的用户不同在，目标机器上没有任何写权限。 -rw-r--r-- 1 3160 dba 6608 Jun 26 23:35 tmp_gunzip.sh -rw-r--r-- 1 3160 dba 624 Jun 26 23:30 tmp_gzip
1、新建一个表结构，创建索引，将百万或千万级的数据使用insert导入该表。 2、新建一个表结构，将百万或千万级的数据使用isnert导入该表，再创建索引。 这两种效率哪个高呢？或者说用时短呢？ 我感觉无论先建还是后建索引，当有数据时都需要update索引数据，问题是有索引的情况下插数据与有数据的情况下建立索引，各自的消耗。
有关数据块的恢复的内容可以参考我的BLOG：http://blog.itpub.net/26736162/viewspace-2139709/
作者介绍 谢浩 现任职于云和恩墨，具有多年oracle数据库企业级运维经验，擅长结合业务、硬件系统制定各种项目方案。 在oracle性能优化主要包括：数据架构优化、逻辑优化、sql优化、数据库运行参数
临时表在日常工作中可能使用比较多，但是大家都对临时表相关的一些知识了解比较少。我们来简单说数理一下。 首先是临时表空间，临时表都存储在临时表空间中，对于临时表空间，从数据库中查询数据字典就能够很清楚的看到，临时表空间是nologging的，也就是临时表也是nologging的。 SQL> select tablespace_name,logging from dba_tablespaces; TABLESPACE_NAME LOGGING -----------------
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
