分区表数据泵导入太慢,达不到客户的迁移要求导出语句如下:(10G单节点)userid='/ as sysdba'directory=milk_dirdumpfile=mon_%U.dmplogfile=0828.logschemas=monparallel=8 导入语句(11G的rac):userid='/ as sysdba'directory=milk_dirdumpfile=mon_%U.dmplogfile=0828.logparallel=8CLUSTER=N 整个过程导出花费了3个小

1,根据数据库类型拼接不同URL /** * 根据类型不同拼接连接的URL * @param dbType 1:mysql.2:oracle.3:sql server.4:gp * @param ip * @param port * @param databaseName * @return*/ public static String getTestDbUrl(int dbType, String ip, String port, String databaseName){ String ur

         最近在调整基础信息数据时,新增了几个客户类型,意想不到的事情发生了,在使用新增的客户类型作为 查询条件查询报表时,居然出现了超时的现象,但是用其他以前的客户类型查询就没有问题,用一个以前增加的 客户类型和新增的4个客户类型一起混合查询也没有问题,很快就查询到了数据.          于是我们使用SQL Profiler将对应的脚步抓出来在管理器中直接执行也是很慢,半小时都没有结果,系统当 然会超时了啊.我有查询了下客户类型表,发现客户类型表也没有索引,而且也只有不到20条记录

就像在电话里提到的那样,Oracle内部的优化器是根据一系列的内部算法基于表上的统计信息来产生执行计划的.对于特别复杂的SQL语句,Oracle的优化器有一定几率不能得到最优的执行计划(因为机器代码实际上是比较死板的,虽然得到的执行计划按照内部的算法来看是比较快的,但是实际上这个执行计划可能在实际执行中比较慢).我们现在碰到的就是这种情况,虽然表的统计信息是准的,但恰恰优化器在基于这个统计信息使用内部算法得到的执行计划是不优化的一这是优化器的固有限制.这时候就需要DBA/Oracle Suppo

[2.以下是更新统计信息] DECLARE UpdateStatisticsTables CURSOR READ_ONLY FOR SELECT sst.name, Schema_name(sst.schema_id) FROM sys.tables sst WHERE sst.TYPE = 'U' DECLARE @name VARCHAR(80), @schema VARCHAR(40) OPEN UpdateStatisticsTables FETCH NEXT FROM UpdateSt

/* --作用:根据特定的表名查询出字段,以及描述,数据类型,长度,精度,是否自增,是否为空等信息 --作者:wonder QQ:37036846 QQ群:.NET顶级精英群 ID:124766907 --时间:2011-03-23 11:25 --描述:创建存储过程 --参数:@tableName 表名 */ CREATE PROC sp_GetListsColumnInfoByTableName( )) AS BEGIN then '主键' ELSE '' END IS_KEYS, x.ob

DECLARE UpdateStatisticsTables CURSOR READ_ONLY FOR 02   SELECT sst.name, 03          Schema_name(sst.schema_id) 04   FROM   sys.tables sst 05   WHERE  sst.TYPE = 'U' 06 DECLARE @name   VARCHAR(80), 07         @schema VARCHAR(40) 08   09 OPEN UpdateS

常见的分区表DDL如 split partition.add partition都会生成没有统计信息的表分区table partition,长期以来我对dbms_stats.lock_table_stats有一个错误的认识,即对于没有统计信息的分区,LOCK_STATS并不生效. 实际测试发现锁表统计信息对没有统计信息的分区同样有效,结果就是自动收集统计信息的作业不会收集这些实际没有统计信息的分区: CREATE TABLE MacleanV nologging partition by ran

1.构建db2admin模式下的所有表的重组语句: select ' reorg table '||TABLE_NAME||';' from sysibm.tables where  TABLE_SCHEMA = 'DB2ADMIN' 2.构建db2admin模式下的所有表更新统计信息的语句:  select ' runstats on  table '||replace(TABLE_SCHEMA||'.'||TABLE_NAME,' ','')||' with distribution and

类似于Oracle的分析表,Hive中也提供了分析表和分区的功能,通过自动和手动分析Hive表,将Hive表的一些统计信息存储到元数据中. 表和分区的统计信息主要包括:行数.文件数.原始数据大小.所占存储大小.最后一次操作时间等: 新表的统计信息 对于一个新创建的表,默认情况下,如果通过INSERT OVERWRITE的方式插入数据,那么Hive会自动将该表或分区的统计信息更新到元数据. 有一个参数来控制是否自动统计,hive.stats.autogather,默认为true. 举例来说: 先创

direct path read深入解析 前言 最近碰到一件很奇葩的事情,因为某条SQL执行缓慢,原因是走了笛卡尔(两组大数据结果集),而且笛卡尔还是NL的一个部分,要循环31M次. 很容易发现是统计信息没有导致的,收集完就好了. 结果过了个51假期回来有人反馈其他的SQL慢了,看了下慢的SQL涉及到的表就刚好是上次收集统计信息的表. 统计问题SQL的历史执行情况,发现时间刚好在那天收集完后开始变慢.咋回事. 后边发现慢的原因是对收集的那两张表做全表扫描时候用了直接路径读(DPR).暂定为表A和

表.约束.索引.表空间.分区.序列.统计信息 一.表及其操作 1.创建表 create table 表名 ( 字段名1 字段类型 默认值 是否为空 , 字段名2 字段类型 默认值 是否为空, 字段名3 字段类型 默认值 是否为空, ...... 字段名n 字段类型 默认值 是否为空 ); 2.删除表 delete from 表名; delete删除数据是一条一条的删除数据,后面可以添加where条件,不删除表结构.注意:如果表中有identity产生的自增id列,delete from后仍然从上

作者:王小龙@网易乐得DBA 原文地址: http://mp.weixin.qq.com/s/698g5lm9CWqbU0B_p0nLMw MySQL执行SQL会经过SQL解析和查询优化的过程,解析器将SQL分解成数据结构并传递到后续步骤,查询优化器发现执行SQL查询的最佳方案.生成执行计划.查询优化器决定SQL如何执行,依赖于数据库的统计信息,下面我们介绍MySQL 5.7中innodb统计信息的相关内容. MySQL统计信息的存储分为两种,非持久化和持久化统计信息. 一.非持久化统计信息 非

为什么要写统计信息 最近看到园子里有人写统计信息,楼主也来凑热闹. 话说经常做数据库的,尤其是做开发的或者优化的,统计信息造成的性能问题应该说是司空见惯. 当然解决办法也并非一成不变,“一招鲜吃遍天”的做法已经行不通了(题外话:整个时代不都是这样子吗) 当然,还是那句话,既然写了就不能太俗套,写点不一样的,本文通过分析一个类似实际案例来解读统计信息的更新的相关问题. 对于实际问题,不但要解决问题,更重要的是要从理论上深入分析,才能更好地驾驭数据库. 统计信息基础 首先说一个老掉牙的话题,统计信息

统计信息概念 统计信息是一些对象,这些对象包含在表或索引视图中一列或多列中的数据分布有关的统计信息.数据库查询优化器使用这些统计信息来估计查询结果中的基数或行数. 通过这些基数估计,查询优化器可以生成高质量的执行计划. 例如,查询优化器可以使用基数估计选择索引查找运算符而不是耗费更多资源的索引扫描运算符,从而提高查询性能.[参考MSDN] 其实如果你以前没有接触过统计信息,你可以将其看做是数据库为了得到最优的执行计划,统计数据库里面表.索引等对象的一些数据,例如表的记录数.所有列的平均长度.直方

前言 查询优化器使用统计信息来创建可提高查询性能的查询计划,对于大多数查询,查询优化器已经为高质量查询计划生成必要的统计信息,但是在少数情况下,您需要创建附加的统计信息或者修改查询设计以得到最佳结果.因此理解和合理使用统计信息是数据库优化的方式之一.   统计信息的分类 根据创建源的不同,统计信息分为两种表统计信息和索引统计信息,除非你自定义它们,否则它们之间没有本质的区别. 索引统计信息建立在索引上面,因此对于创建已经存在的数据上,在创建索引的时候会扫描全部数据,这些数据也会创建在索引的统计信

dbms_stats包问世以后,我们可通过一种新的方式来为CBO收集统计数据.目前,已经不再推荐使用老式的Analyze分析表和dbms_utility方法来生成CBO统计数据.dbms_stats能良好地估计统计数据(尤其是针对较大的分区表),并能获得更好的统计结果,最终制定出速度更快的SQL执行计划. --创建用于存放统计信息的舞台表    exec dbms_stats.create_stat_table (ownname => 'SCOTT', stattab => 'ST_T1',

统计信息的含义与作用                                                                                                                                                      对于同一句话,SQL SERVER 有很多种方法来完成它.有些方法适合于数据量比较小的时候,有些方法适合于数据量比较大的时候.同一种方法,在数据量不同的时候,复杂度会有非常大的差别

  1. 统计信息查看 1.1 单个表的全局统计信息.统计效果查看 2. 统计信息分析(收集) 2.1 分析工具选择 2.2 分析前做index重建 2.3 分析某数据表,可以在PL/SQL的command window下执行的 2.4 分析SCHEMA,在SQLPLUS中进行的 2.5 dbms_stats.gather_schema_stats详解 2.6 初始化参数statistics_level与oracle默认统计信息收集JOB的关系 3. 改良.辅助oracle默认统计信息收集JOB

优化器统计范围: 表统计: --行数,块数,行平均长度:all_tables:NUM_ROWS,BLOCKS,AVG_ROW_LEN:列统计: --列中唯一值的数量(NDV),NULL值的数量,数据分布:             --DBA_TAB_COLUMNS:NUM_DISTINCT,NUM_NULLS,HISTOGRAM:索引统计:--叶块数量,等级,聚簇因子:             --DBA_INDEXES:LEAF_BLOCKS,CLUSTERING_FACTOR,BLEVEL:

overview Oracle's cost-based optimizer (COB) uses statistics to calculate the selectivity (the fraction of rows in a table that the SQL statement's predicate chooses) of predicates and to estimate the "cost" of each execution plan. The COB will