如何在oracle数据库中查询记录总条数

如何在oracle数据库中查询记录总条数,第1张

方法和详细的 *** 作步骤如下:

1、第一步,查询该库中的所有表,测试sql,代码见下图,转到下面的步骤。

2、第二步,执行完上面的 *** 作之后,查询有多少个数据表,见下图,转到下面的步骤。

3、第三步,执行完上面的 *** 作之后,在TEST的开头编写一个查询表的脚本,每个表中的记录数,代码见下图,转到下面的步骤。

4、第四步,执行完上面的 *** 作之后,执行sql,在输出窗口中,可以看到每个表的输出,见下图。这样,就解决了这个问题了。

如果你管理的Oracle数据库下某些应用项目有大量的修改删除 *** 作 数据索引是需要周期性的重建的

它不仅可以提高查询性能 还能增加索引表空间空闲空间大小

在ORACLE里大量删除记录后 表和索引里占用的数据块空间并没有释放

重建索引可以释放已删除记录索引占用的数据块空间

转移数据 重命名的方法可以重新组织表里的数据

下面是可以按ORACLE用户名生成重建索引的SQL脚本

SET ECHO OFF; SET FEEDBACK OFF; SET VERIFY OFF; SET PAGESIZE ; SET TERMOUT ON; SET HEADING OFF; ACCEPT username CHAR PROMPT Enter the index username: ; spool /oracle/rebuild_&username sql; SELECT REM + + || chr( ) || REM | INDEX NAME : || owner || || segment_name || lpad( | (length(owner) + length(segment_name)) ) || chr( ) || REM | BYTES : || bytes || lpad ( | (length(bytes)) ) || chr( ) || REM | EXTENTS : || extents || lpad ( | (length(extents)) ) || chr( ) || REM + + || chr( ) || ALTER INDEX || owner || || segment_name || chr( ) || REBUILD || chr( ) || TABLESPACE || tablespace_name || chr( ) || STORAGE ( || chr( ) || INITIAL || initial_extent || chr( ) || NEXT || next_extent || chr( ) || MINEXTENTS || min_extents || chr( ) || MAXEXTENTS || max_extents || chr( ) || PCTINCREASE || pct_increase || chr( ) || ); || chr( ) || chr( ) FROM dba_segments WHERE segment_type = INDEX AND owner= &username ORDER BY owner bytes DESC; spool off;

如果你用的是WINDOWS系统 想改变输出文件的存放目录 修改spool后面的路径成

spool c oraclerebuild_&username sql

如果你只想对大于max_bytes的索引重建索引 可以修改上面的SQL语句

在AND owner= &username 后面加个限制条件 AND bytes> &max_bytes

如果你想修改索引的存储参数 在重建索引rebuild_&username sql里改也可以

比如把pctincrease不等于零的值改成是零

生成的rebuild_&username sql文件我们需要来分析一下 它们是否到了需要重建的程度

分析索引 看是否碎片严重 SQL>ANALYZE INDEX &index_name VALIDATE STRUCTURE; col name heading Index Name format a col del_lf_rows heading Deleted|Leaf Rows format col lf_rows_used heading Used|Leaf Rows format col ratio heading % Deleted|Leaf Rows format SELECT name del_lf_rows lf_rows del_lf_rows lf_rows_used to_char(del_lf_rows / (lf_rows) ) ratio FROM index_stats where name = upper( &index_name );

当删除的比率大于 % 时 肯定是需要索引重建的

经过删改后的rebuild_&username sql文件我们可以放到ORACLE的定时作业里

比如一个月或者两个月在非繁忙时间运行

如果遇到ORA 错误 表示索引在的表上有锁信息 不能重建索引

那就忽略这个错误 看下次是否成功

对那些特别忙的表要区别对待 不能用这里介绍的方法

lishixinzhi/Article/program/Oracle/201311/19038

以oracle表分析为例:

drop table test;

select count() from test;

--创建测试表

create table test

(

id number(9),

nick varchar2(30)

);

--插入测试数据

begin

for i in 1100000 loop

insert into test(id) values(i);

end loop;

commit;

end;

select from test;

--更新nick字段,使数据发生严重倾斜

update test set nick='abc' where rownum<99999;

--创建索引

create index idx_test_nick on test(nick);

update test set nick='def' where nick is null;

--只对索引进行分析

analyze index idx_test_nick compute statistics;

select from user_indexes;

--查看索引名,对应存储的数据块,不同的key数量,记录数(行数)的分析信息

select index_name, LEAF_BLOCKS, DISTINCT_KEYS, NUM_ROWS

from user_indexes

where index_name = 'IDX_TEST_NICK';

--dba_tab_col_statistics

--查看表的统计信息

select COLUMN_NAME, NUM_BUCKETS, num_distinct

from USER_tab_columns

where table_name = 'TEST';

select from test where nick ='abc';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE)

select from test where nick ='def';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE)

--由上可以看到,对索引分析之后,sql的执行路径都是基于规则的,索引的字段的偏移

--先根据索引找到rowid,然后再根据rowid读取记录,这个过程肯定比全表扫描读取记录要慢

--user_part_col_statistics 分区分析信息

--分析表的第二列nick

analyze table test compute statistics for columns size 2 nick;

select from test where nick ='abc';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST'

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE)

--根据上面的执行计划,还是按照规则来执行的

--分析表

analyze table test compute statistics for table;

select from test where nick ='abc';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=49 Card=99998 Bytes=

1499970)

1 0 TABLE ACCESS (FULL) OF 'TEST' (Cost=49 Card=99998 Bytes=14

99970)

--分析表之后,完全按照成本来执行

--删除所有的统计数据,并只对表与列进行分析,不分析索引,

--ORACLE使用CBO的优化器,并产生了正确的执行计划

analyze table test delete statistics;

--分析列nick

analyze table test compute statistics for table for columns size 2 nick;

select from test where nick ='abc';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=49 Card=99998 Bytes=

1499970)

1 0 TABLE ACCESS (FULL) OF 'TEST' (Cost=49 Card=99998 Bytes=14

99970)

--

select from test where nick ='def';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=2 Bytes=30)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=2 Byt

es=30)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE) (Cost

=1 Card=2)

--创建TEST表ID列上的索引,但不对索引进行分析

create index idx_test_id on test(id);

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1000 Bytes=15

000)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1000

Bytes=15000)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_ID' (NON-UNIQUE) (Cost=1

Card=400)

--当条件中即有id,又有nick时,因为nick上有直方图,ORACLE知道nick='abc'的值特别的多,所以不走IDX_TEST_NICK索引,走IDX_TEST_ID上的索引

select from test where id=5 and nick='abc';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1000 Bytes=15

000)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1000

Bytes=15000)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_ID' (NON-UNIQUE) (Cost=1

Card=400)

--当条件中即有id,又有nick时,因为nick上有直方图,ORACLE知道nick='def'的值特别的少,所以走IDX_TEST_NICK上的索引,不走IDX_TEST_ID索引

select from test where id=5 and nick='def';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=15)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1 Byt

es=15)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE) (Cost

=1 Card=2)

select from test where nick='def' and id=5;

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=15)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1 Byt

es=15)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_NICK' (NON-UNIQUE) (Cost

=1 Card=2)

--在分析ID列后,ORACLE发现ID列的选择度更高,所以不再选择IDX_TEST_NICK索引,而是选择IDX_TEST_ID

analyze table test compute statistics for columns size 1 id;

select from test where id=5 and nick='def';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=7)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1 Byt

es=7)

2 1 INDEX (RANGE SCAN) OF 'IDX_TEST_ID' (NON-UNIQUE) (Cost=1

Card=1)

/

下面来看另外一种情况,我们删除所有的统计数据,然后在ID列上创建唯一索引,在此条件下,

只分析表与分析列nick,我们看到ORACLE走了正确的执行计划,

走了UK_TEST_ID,其实从这里也给我们带来很多的启示:

在主键与唯一键约束的列上是否需要直方图的问题

如果在这些列上有像这样的查询where id > 100 and id < 1000,

我们还是需要有直方图的,但除此之外,好像真的没有直方图的必要了!

/

analyze table test delete statistics;

drop index idx_test_id;

create unique index uk_test_id on test(id);

--分析表的第二列nick

analyze table test compute statistics for table for columns size 2 nick;

select from test where id=5 and nick='def';

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=15)

1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TEST' (Cost=2 Card=1 Byt

es=15)

2 1 INDEX (UNIQUE SCAN) OF 'UK_TEST_ID' (UNIQUE) (Cost=1 Car

d=100000)

从以上一系列的实验可以看出,对ORACLE的优化器CBO来说,表的分析与列的分析才是最重要的,索引的分析次之。还有我们可以考虑我们的哪些列上需要直方图,对于bucket的个数问题,oracle的默认值是75个,所以根据你的应用规则,选择合适的桶数对性能也是有帮助的。因为不必要的桶的个数的大量增加,必然会带来SQL语句硬解析时产生执行计划的复杂度问题。

以上就是关于如何在oracle数据库中查询记录总条数全部的内容,包括:如何在oracle数据库中查询记录总条数、在Oracle数据库中按用户名重建索引的方法、如何分析Oracle等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9837045.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-02
下一篇 2023-05-02

发表评论

登录后才能评论

评论列表(0条)

保存