RNDr. Michal Kopecký, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague

Transcription

1 seminář: Administrace Oracle (NDBI013) LS2017/18 RNDr. Michal Kopecký, Ph.D. Department of Software Engineering, Faculty of Mathematics and Physics, Charles University in Prague

2 Database structure Database structure Database files Memory structure Process structure Data access SQL execution SQL optimization Indexes

3 1. Data stored in files and/or disc partitions 2. Data accessed by the database instance set of processes communicating via the shared memory.

4 1. Each file consists of 1. Header 2. Used space 3. Free space

5 select file_id, file_name, status, blocks, maxblocks, user_blocks from dba_data_files; FILE_ID FILE_NAME STATUS BLOCKS MAXBLOCKS USER_BLOCKS 4 /mnt/data/oradata/jedenact/users01.dbf AVAILABLE /mnt/data/oradata/jedenact/undotbs01.dbf AVAILABLE /mnt/data/oradata/jedenact/sysaux01.dbf AVAILABLE /mnt/data/oradata/jedenact/system01.dbf AVAILABLE from dba_temp_files; FILE_ID FILE_NAME STATUS BLOCKS MAXBLOCKS USER_BLOCKS 1 /mnt/data/oradata/jedenact/temp01.dbf ONLINE

6 1. Data (tables and indexes) stored each in its own segment a linked list of extents. 2. Extent logically continuous set of database blocks 3. Database block the I/O unit. Fixed size for whole tablespace (usually for whole database).

7

8 select tablespace_name, status from dba_tablespaces; TABLESPACE_NAME STATUS SYSTEM ONLINE SYSAUX ONLINE UNDOTBS1 ONLINE TEMP ONLINE USERS ONLINE

9 1. Data stored in so called tablespaces logical database volumes. 2. Inidividually managed 1. Quotas 2. Offline/Online 3. Back up/restore 4. Recover

10 1. Dictionary managed obsolete information about free and used space in data dictionary

11 1. Dictionary managed obsolete information about free and used space in data dictionary 2. Locally managed bitmap of free/used space in the tablespace itself 1. Automatic space management

12

13 select owner, segment_name, segment_type, tablespace_name, extents, blocks from dba_segments where owner='dbapl2'; OWNER SEGMENT_NAME SG_TYPE TS_NAME EXTENTS BLOCKS DBAPL2 DRUH TABLE USERS 1 8 DBAPL2 ZVIRE TABLE USERS 1 8 DBAPL2 KATEGORIE TABLE USERS 1 8 DBAPL2 VYBEH TABLE USERS 1 8 DBAPL2 POBYT TABLE USERS 1 8 DBAPL2 DRUH_PK INDEX USERS 1 8 DBAPL2 ZVIRE_PK INDEX USERS 1 8 DBAPL2 DRUH_IDKAT_INX INDEX USERS 1 8 DBAPL2 ZVIRE_NAZEV_INX INDEX USERS 1 8 DBAPL2 KATEGORIE_PK INDEX USERS 1 8 DBAPL2 KATEGORIE_U_NAZKAT INDEX USERS 1 8 DBAPL2 VYBEH_PK INDEX USERS 1 8 DBAPL2 SYS_C INDEX USERS 1 8 DBAPL2 POBYT_IDVYBEH_INX INDEX USERS 1 8

14

15 select owner, segment_name, segment_type, extent_id, tablespace_name, file_id, block_id, blocks from dba_extents where owner='dbapl2'; OWNER SEGMENT_NAME SG_TYPE EXT_ID TS_NAME FILE_ID BLK_ID BLOCKS DBAPL2 POBYT_IDVYBEH_INX INDEX 0 USERS DBAPL2 SYS_C INDEX 0 USERS DBAPL2 VYBEH_PK INDEX 0 USERS DBAPL2 KATEGORIE_U_NAZKAT INDEX 0 USERS DBAPL2 KATEGORIE_PK INDEX 0 USERS DBAPL2 ZVIRE_NAZEV_INX INDEX 0 USERS DBAPL2 DRUH_IDKAT_INX INDEX 0 USERS DBAPL2 ZVIRE_PK INDEX 0 USERS DBAPL2 DRUH_PK INDEX 0 USERS DBAPL2 POBYT TABLE 0 USERS DBAPL2 VYBEH TABLE 0 USERS DBAPL2 KATEGORIE TABLE 0 USERS DBAPL2 ZVIRE TABLE 0 USERS DBAPL2 DRUH TABLE 0 USERS

16 1. One DB Block (4KiB, 8KiB, ) consists of a sequence of OS blocks

17

18 1. Each column stored as tuple (length,data) 2. Trailing NULLs not stored

19 1. PCTFREE=x If free space drops under x%, block is removed from blocks available for INSERTs 2. PCTUSED=y If free space drops below y%, block becomes available for INSERTs

20

21 1. SGA stores all data, that can be shared by all running sessions 1. Database buffer cache 2. Redo log buffer 3. Shared pool 4. Large pool Program Global Area (PGA) stores data belonging to given process

22 1. Default pool stores copies of DB blocks in external memory (disc) 2. Keep pool stores (all) blocks of small frequently used tables 3. Recycle pool stores blocks of large infrequently used tables to avoid consuming lot of space in default pool 4. Blocks of non-default sizes have their own pool

23 1. Circular buffer that stores redolog entries. When necessary (COMMIT, checkpoint, buffer full, ) are written to online redo-log file

24 1. Client processes 1. Runs client code 2. Server processes 1. Runs Oracle code 3. Background Processes 1. Manipulates with data (bottom of the figure) 2. Check the database (right side of the figure)

25 ps ef grep jedenact oracle :14? 00:00:00 oraclejedenact (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) oracle ? 01:02:19 ora_dbw0_jedenact oracle ? 00:46:17 ora_lgwr_jedenact oracle ? 00:29:11 ora_d000_jedenact oracle ? 06:37:07 ora_s000_jedenact oracle ? 01:41:36 ora_s001_jedenact oracle ? 00:10:18 ora_s007_jedenact oracle :31? 00:00:00 ora_w000_jedenact oracle ? 01:30:35 ora_pmon_jedenact oracle ? 00:21:12 ora_mman_jedenact oracle ? 02:34:20 ora_ckpt_jedenact oracle ? 00:38:43 ora_smon_jedenact oracle ? 00:08:16 ora_reco_jedenact oracle ? 01:59:18 ora_mmon_jedenact oracle ? 03:05:12 ora_mmnl_jedenact oracle ? 00:10:50 ora_qmnc_jedenact oracle ? 01:58:20 ora_cjq0_jedenact oracle ? 00:08:30 ora_q000_jedenact oracle ? 00:12:00 ora_q001_jedenact oracle ? 00:25:41 ora_smco_jedenact

26 1. Individual Server processes access shared data in the SGA and private data in PGA

27 1. Each client process has its own server process 1. Optimal for batch processing with intensive process usage (without or with less idle time)

28 1. More clients share one server process through dispatcher process 1. Optimal for less intensive clients with much idle time

29 1. Log Writer Process (LGWR) writes data from the buffer to online redo log file. 2. When file is full, the redo log switch occurs, checkpoint forced 1. All dirty data blocks written to the database files

30

31 1. Row too long for the block stored partially in the block and partially in another block(s). Linked via pointers.

32 1. Row updated so it doesn t fit to the block is migrated to another block. Remains only pointer to keep original ROWID. 2. Two block reads instead of one.

33

34 1. SQL statement parsing 1. Syntax checking 2. Semantic checking 2. Check existence of query plan in Shared Pool 3. If plan doesn t exist, generate as much of available plans as possible and choose the best (with lowest cost) 4. If plan doesn t exist, plan row source execution 5. Execute the query

35 1. Query can be reformulated (IN operator can be replaced by OR and vice versa, ) 2. For each plan is estimated number of processed rows in nodes, number of bytes, number of read blocks, CPU usage, etc. 3. The cost of the plan is computed as the weighted sum according to internal statistics

36 Each execution plan is stored. According to the CURSOR_SHARING settins can be used repeatedly EXACT cursor sharing The plan can be used for the exactly same SQL statement SIMILAR cursor sharing The plan can be used for similar SQL statement with the same structure, but different constant Each constant is replaced by placeholder SELECT * FROM Emp WHERE ID=1 SELECT * FROM Emp WHERE ID=:x1 Values are bound to placeholders in time of execution PROS: less number of statement parsing CONS: optimization without knowledge of exact value may be ineffective in case of non-uniform distribution of values

37 EXPLAIN PLAN FOR select * from Zvire Z natural join Druh D natural join Kategorie K where K.NazKat='Kockovite ; PLAN_TABLE_OUTPUT Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (0) 00:00:01 1 NESTED LOOPS 2 NESTED LOOPS (0) 00:00:01 3 NESTED LOOPS (0) 00:00:01 4 TABLE ACCESS BY INDEX ROWID KATEGORIE (0) 00:00:01 * 5 INDEX UNIQUE SCAN KATEGORIE_U_NAZKAT 1 0 (0) 00:00:01 6 TABLE ACCESS FULL ZVIRE (0) 00:00:01 * 7 INDEX UNIQUE SCAN DRUH_PK 1 0 (0) 00:00:01 * 8 TABLE ACCESS BY INDEX ROWID DRUH (0) 00:00: Predicate Information (identified by operation id): access("k"."nazkat"='kockovite') 7 - access("z"."nazev"="d"."nazev") 8 - filter("d"."idkat"="k"."idkat")

38 B-Tree For columns with high selectivity Bitmap For columns with low selectivity Can be combined using AND, OR to achieve higher selectivity Index organized Tables Clustered index on primary key Data physically ordered by primary key, i.e. rows have no stable physical location in segment / file B*-tree indexes store key value and estimated position

39 create index Zvire_Nazev_Inx on Zvire(Nazev); EXPLAIN PLAN FOR select * from Zvire Z natural join Druh D natural join Kategorie K where K.NazKat='Kockovite ; PLAN_TABLE_OUTPUT Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (0) 00:00:01 1 NESTED LOOPS 2 NESTED LOOPS (0) 00:00:01 3 NESTED LOOPS (0) 00:00:01 4 TABLE ACCESS BY INDEX ROWID KATEGORIE (0) 00:00:01 * 5 INDEX UNIQUE SCAN KATEGORIE_U_NAZKAT 1 0 (0) 00:00:01 6 TABLE ACCESS BY INDEX ROWID DRUH (0) 00:00:01 * 7 INDEX RANGE SCAN DRUH_IDKAT_INX 1 0 (0) 00:00:01 * 8 INDEX RANGE SCAN ZVIRE_NAZEV_INX 1 0 (0) 00:00:01 9 TABLE ACCESS BY INDEX ROWID ZVIRE (0) 00:00: Predicate Information (identified by operation id): access("k"."nazkat"='kockovite') 7 - access("d"."idkat"="k"."idkat") 8 - access("z"."nazev"="d"."nazev")

40

41