1)数据块(Data Block),是读写数据文件的最小单元,默认是8KB,可以通过SQL语句“SELECT FILE#,NAME,BLOCK_SIZE FROM V D A T A F I L E ; ”查询,单元为 B Y T E 。 2 ) R e d o 日志数据块( R e d o L o g B l o c k ),大小一般即是操纵系统的系统块的大小,一般为 512 或 4096 ,可以通过 S Q L 语句“ S E L E C T B L O C K S I Z E F R O M V DATAFILE;”查询,单元为BYTE。 2)Redo日志数据块(Redo Log Block),大小一般即是操纵系统的系统块的大小,一般为512或4096 ,可以通过 SQL语句“SELECT BLOCKSIZE FROM V DATAFILE;”查询,单元为BYTE。2)Redo日志数据块(RedoLogBlock),大小一般即是操纵系统的系统块的大小,一般为512或4096,可以通过SQL语句“SELECTBLOCKSIZEFROMVLOG;”或“SELECT LEBSZ FROM X K C C L E ; ”查询,单元为 B Y T E 。 3 )控制文件数据块( C o n t r o l F i l e B l o c k ),默认为 16 K B ,可以通过 S Q L 语句“ S E L E C T B L O C K S I Z E F R O M V KCCLE;”查询,单元为BYTE。 3)控制文件数据块(Control File Block),默认为16KB,可以通过SQL语句“SELECT BLOCK_SIZE FROM V KCCLE;”查询,单元为BYTE。3)控制文件数据块(ControlFileBlock),默认为16KB,可以通过SQL语句“SELECTBLOCKSIZEFROMVCONTROLFILE;”查询,单元为BYTE。
1.3 行链接和行迁徙有什么区别?
字典管理表空间(Dictionary Managed Tablespace,DMT),它是Oracle 8i及以前版本利用的一种表空间管理模式,不过在Oracle 8i及以后的版本中仍然保存有该特性。DMT是通过数据字典管理表空间的空间利用(其实是管理区)。每当分配或取消分配区后,Oracle服务器会更新数据字典中的相应表。用于管理的两个数据字典表分别是:UET ( U s e d E x t e n t s )和 F E T (Used Extents)和FET (UsedExtents)和FET(Free Extents)。DMT是为了实现向后兼容而提供的,建议利用本地管理的表空间。
**本地管理表空间(Locally Managed Tablespace,LMT)**是从Oracle 8i出现的一种新的表空间的管理模式,通过位图来管理表空间的空间利用(其实是管理区)。位图中的每个位都对应于一个块或一组块。Oracle 在分配区或释放区后可以重新利用,Oracle 服务器通过更改位图值来显示块的新状态。LMT 在Oracle 9i及以后版本中成了默认选项。
1.9 Redo日志文件(Redo Log Files)的作用是什么?
答案:Redo日志文件包含全部的数据库变革汗青记录,比方全部的DML变革(INSERT、UPDATE、DELETE和SELECT FOR UPDATE)和全部DDL语句造成的数据字典对象的更改及递归语句的更改等,以是,日志文件可以最大限度地包管数据的一致性与安全性。当发生提交动作时,背景历程 LGWR 将Redo日志缓冲区中的数据刷到Redo日志文件里。
1.10 Oracle系统历程主要有哪些,作用是个啥?
How to find the complete SQL statement caused ORA-1555 :
If the Database was not restarted after the error ORA-1555 , so the Statement can be obtained from :
select SQL_TEXT from v$sqlarea where SQL_ID=‘’;
If the Database was restarted after the error ORA-1555 and an AWR snapshot was gathered before the restart , so the Statement can be obtained from :
select SQL_TEXT from DBA_HIST_SQLTEXT where SQL_ID=‘’;
1.11.6 请描述ORA-30036错误原因和解决思绪。
ORA-30036:unable to extend segment by 8 in undo tablespace ‘UNDOTBS1’
当当前UNDO表空间没有更多可用空间用于活动事务时,将报告ORA-30036错误。
UNDO空间分配按以下顺序举行:
1.在没有活动事务的UNDO段中分配数据块。Oracle尝试将事务分发到全部UNDO段。
2.假如找不到UNDO段,则oracle会尝试将脱机UNDO段联机并利用它。
3.假如没有要联机的UNDO段,则创建一个新的UNDO段并利用它。
4.假如空间不允许创建undo段,那么我们尝试重用现有undo段中过期的区段。
对于与UNDO段/extent关联的正在运行的事务,假如它需要更多的UNDO空间,则:
1.假如当前extent有更多可用块,则利用下一个已准备好分配给该extent的可用块。
2.假如当前区段没有空闲块,并且该段的下一区段已过期,则在下一区段中包装该区段并返回第一个区段。
3.假如下一个extent尚未过期,则从UNDO表空间获取空间。假如有可用的扩展数据块,则将其分配给UNDO段,并返回新扩展数据块中的第一个块。
4.假如没有可用的extent,则从脱机UNDO段举行窃取。从脱机UNDO段取消分配数据块,并将其添加到当前UNDO段。返回数据块的第一个空闲块。
5.从联机UNDO段窃取。从联机UNDO段取消分配数据块,并将其添加到当前UNDO段。返回数据块的第一个空闲块。
6.在UNDO表空间中扩展文件。假如文件可以扩展,则向当前UNDO段添加一个区段,然后返回块。
7.否则,尝试从自己的UNDO段重用未过期的区段。假如全部扩展数据块当前都很忙(它们包含未提交的信息),请转至步骤8。否则,请换行到下一个扩展数据块。
8.从脱机UNDO段随机窃取未过期的数据块。假如失败,则尝试联机UNDO段以供重用。
9.假如上述操纵都失败,则返回ORA-30036无法将段扩展%s(在UNDO表空间“%s”中)
1.11.7 如何评估所需UNDO大小?
How To Size UNDO Tablespace For Automatic Undo Management (Doc ID 262066.1)
调解UNDO表空间的大小需要三个数据。
Sizing an UNDO tablespace requires three pieces of data.
(UR) UNDO_RETENTION in seconds
(UPS) Number of undo data blocks generated per second
(DBS) Overhead varies based on extent and file size (db_block_size)
所需的undo空间计算如下:
The undo space needed is calculated as:
UndoSpace = UR * (UPS * DBS)
以下公式计算每秒天生的峰值undo块:
The following formula calculates the peak undo blocks generated per second:
SELECT undoblks / ((end_time - begin_time) * 86400) “Peak Undo Block Generation”
FROM v u n d o s t a t W H E R E u n d o b l k s = ( S E L E C T M A X ( u n d o b l k s ) F R O M v undostat WHERE undoblks = (SELECT MAX(undoblks) FROM v undostat WHEREundoblks=(SELECTMAX(undoblks)FROMvundostat);
列竣事时间和开始时间是日期数据类型。
减去日期数据类型后,结果值为两个日期之间的天数。
要将天转换为秒,需要将86400乘以一天中的秒数(24小时60分钟60秒)。
Column END_TIME and BEGIN_TIME are DATE data types.
When DATE data types are subtracted, the resulting value is the # of days between both dates.
To convert days to seconds, you multiply by 86400, the number of seconds in a day (24 hours * 60 minutes * 60 seconds).
以下查询计算处理峰值撤消活动所需的字节数:
The following query calculates the number of bytes needed to handle a peak undo activity:
SELECT (UR * (UPS * DBS)) AS “Bytes”
FROM (SELECT value AS UR FROM v p a r a m e t e r W H E R E n a m e = ′ u n d o r e t e n t i o n ′ ) , ( S E L E C T u n d o b l k s / ( ( e n d t i m e − b e g i n t i m e ) ∗ 86400 ) A S U P S F R O M v parameter WHERE name = 'undo_retention'), (SELECT undoblks / ((end_time - begin_time) * 86400) AS UPS FROM v parameterWHEREname=′undoretention′), (SELECTundoblks/((endtime−begintime)∗86400)ASUPS FROMvundostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v u n d o s t a t ) ) , ( S E L E C T b l o c k s i z e A S D B S F R O M d b a t a b l e s p a c e s W H E R E t a b l e s p a c e n a m e = ( S E L E C T U P P E R ( v a l u e ) F R O M v undostat)), (SELECT block_size AS DBS FROM dba_tablespaces WHERE tablespace_name = (SELECT UPPER(value) FROM v undostat)), (SELECTblocksizeASDBS FROMdbatablespaces WHEREtablespacename= (SELECTUPPER(value) FROMvparameter
WHERE name = ‘undo_tablespace’));
对于利用调优撤消保存的10g及更高版本,请利用以下查询:
For 10g and Higher Versions where Tuned undo retention is being used,please use below query:
SELECT (UR * (UPS * DBS)) AS “Bytes”
FROM (select max(tuned_undoretention) AS UR from v u n d o s t a t ) , ( S E L E C T u n d o b l k s / ( ( e n d t i m e − b e g i n t i m e ) ∗ 86400 ) A S U P S F R O M v undostat), (SELECT undoblks / ((end_time - begin_time) * 86400) AS UPS FROM v undostat), (SELECTundoblks/((endtime−begintime)∗86400)ASUPS FROMvundostat
WHERE undoblks = (SELECT MAX(undoblks) FROM v u n d o s t a t ) ) , ( S E L E C T b l o c k s i z e A S D B S F R O M d b a t a b l e s p a c e s W H E R E t a b l e s p a c e n a m e = ( S E L E C T U P P E R ( v a l u e ) F R O M v undostat)), (SELECT block_size AS DBS FROM dba_tablespaces WHERE tablespace_name = (SELECT UPPER(value) FROM v undostat)), (SELECTblocksizeASDBS FROMdbatablespaces WHEREtablespacename= (SELECTUPPER(value) FROMvparameter
WHERE name = ‘undo_tablespace’));
2.索引相关
第一种: index unique scan 索引唯一扫描,当可以优化器发现某个查询条件可以利用到主键、唯一键、具有外键约束的列,或者只是访问其中某行索引所在的数据的时间,优化器会选择这种扫描类型。
第二种: index range scan索引范围扫描,当优化器发现在UNIQUE列上利用了大于、小于、大于即是、小于即是以及BETWEEN等就会利用范围扫描,在组合列上只利用部分举行查询,导致查询出多行数据。对非唯一的索引列上举行任何活动都会利用 index range scan。
第三种: index full scan 全索引扫描,假如要查询的数据可以全部从索引中获取,则利用全索引扫描。
第四种:** index fast full scan索引快速扫描**,扫描索引中的全部的数据块,与全索引扫描的方式基本上雷同。两者之间的显着的区别是,索引快速扫描对查询的数据不举行排序,数据返回的时间不是排序的。“在这种存取方法中,可以利用多块读功能,也可以利用并行读入,从而得到最大的吞吐量和缩短实行时间”。
第五种:**索引跳跃式扫描(INDEX SKIP SCAN)**实用于全部类型的复合B树索引(包括唯一性索引和非唯一性索引),它使那些在where条件中没有对目的索引的前导列指定查询条件但同时又对该 索引的非前导列指定了查询条件的目的SQL依然可以用上该索引,这就像是在扫描该索引时跳过了它的前导列,直接从该索引的非前导列开始扫描一样(实际的实行过程并非云云),这也是索引跳跃式扫描中"跳跃"(SKIP)一词的含义。
3.3 Hash Join是不是有排序?Hash Join会在什么时间慢?
临时表空间是Oracle数据库的紧张构成部分,尤其是对于大型的频繁操纵,如创建索引、排序等都需要在临时表空间完成来减少内存的开销。固然对于查询性能要求较高的操纵应尽可能地制止在磁盘上完成这些操纵。
若临时表空间占用过大,起首,要去查抄是什么会话占用了临时表空间,详细占用了多少,临时段的详细类型是什么。通过查询视图GV S O R T U S A G E ( G V SORT_USAGE(GV SORTUSAGE(GVSORT_USAGE和GV T E M P S E G U S A G E 查询的结果是一致的)和 G V TEMPSEG_USAGE查询的结果是一致的)和 GV TEMPSEGUSAGE查询的结果是一致的)和GVSESSION 可以获取到临时表空间的占用情况和临时段的类型等信息。
6.5 如何有效地删除一个大表(即表的EXTENT数很多)?
答案:一个有很多EXTENT(100k+)的表,假如只是简单地用DROP TABLE的话,那么会大量消耗CPU(在DMT管理下,Oracle要对FET 、 U E T 、UET 、UET数据字典举行操纵),可能会用上几天的时间,较好的方法是分多次删除EXTENT,以减轻这种消耗
6.6 Oracle 低落高水位线的方法