1. Group Technology and Operations
Deutsche Bank
Traditional relational
databases architecture
Dmitry Remizov
2. Dmitry Remizov
14 August 2014
Deutsche Bank
Я собираюсь рассказать некоторые базовые вещи об архитектуре
традиционных баз данных на примере 2х наиболее ярких
представителей систем этого класса, а именно - Oracle и Microsoft
SQL. Выбор обусловлен тем, что это, во-первых, лидирующие
системы в своих сегментах, во-вторых, они исповедуют весьма
различные базовые идеологии. В основном по историческим
причинам.
Начнем, однако, с того, зачем нужны базы данных вообще. Почему
бы не писать просто в плоские файлы. Действительно есть класс
задач, для которого это вполне релевантный подход (логи и т.п.).
Однако довольно часто нам надо писать что-то консистентно и из
многих потоков одновременно.
И вот этим-то и занимаются реляционные базы данных.
Agenda
3. Dmitry Remizov
14 August 2014
Deutsche Bank
Несмотря на все исторические различия, многие архитектурные
решения оказались весьма сходными. Хотя, конечно, есть и
существенные различия.
Начнем с того, что Oracle «версионник», а MSSQL «блокировочник».
Расшифруем немного этот жаргон:
•«Блокировочник» означает, что «писатель» может заблокировать
«читателей», 2 пишущие сессии должны логически лочить друг
друга, если имеют дело с одной и той же строкой (данными).
•«Версионник» вместо блокировки читателя возвращает клиенту
«предыдущую версию правды». На какой момент это отдельный
вопрос.
Два подхода
4. Dmitry Remizov
14 August 2014
Deutsche Bank
Из чего состоит реляционная база данных:
•Процессы OS
•Структуры в памяти
•Файлы на файловой системе
На следующем слайде мы увидим некоторую обзорную картинку
основных компонентов Oracle и MSQL
Архитектура
5. Dmitry Remizov
14 August 2014
Deutsche Bank
MSSQL
Buffer pool
TLogs
Memory structures and processes
Oracle
Buffer Cache
Online redo logs
MSSQL
Buffer Pool
TLogs
8. Dmitry Remizov
14 August 2014
Deutsche Bank
Oracle MSSQL
Buffer Cache Buffer Pool
Redo log buffer Log cache
Shared Pool Procedural cache
Сравнение основных областей
памяти
9. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
ACID
В незапамятные времена была определена некая модель, которой
должны удовлетворять все реляционные базы данных. Это 4
базовых принципа и по начальным буквам эта модель называется
ACID. Вкратце:
Atomicity – транзакция не может быть завершена частично.
Consistency – база данных консистентна в начале и конце каждой
транзакции
Isolation – транзакция не видит изменения произведенные другой
незавершенной транзакцией
Durability – закоммиченная транзакция «переживает» крах системы
Все реляционные базы в меру своих возможностей пытаются
удовлетворить ACID принципам и соответственно для этого нужны
низкоуровневые механизмы.
10. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Transaction logs
Рассмотрим один из важнейших механизмов обеспечения ACID (а
именно A & D частей) - подсистема transaction log’ов. В MSSQL это
одна подсистема – TLOG + LogWriter, которая обепечивает
возможность commit/rollback (Atomicity) и восстанавливаемость
системы (Durability).
В Oracle немного сложнее - 2 тесно связанных подсистемы REDO
and UNDO. REDO для Durability и UNDO для Atomicity (и еще для
обеспечения много-версионного чтения).
11. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
WAL
Несколько слов зачем вообще нужны логи транзакций.
Современные базы данных - это в основном большие (иногда
распределенные кэши) с конкурентным доступом, и все, что вы
делаете с данными в основном происходит в оперативной памяти
(есть исключения), однако нам надо обеспечить механизм
восстановления данных при крахе системы.
Для этого все изменения в системе пишутся в отдельный лог,
который при commit’е синхронно сохраняется на файловую систему.
И в Oracle и в MSSQL реализован механизм т.н. WAL ( Write ahead
logging), т.е. все данные, которые вы записываете, сначала пишутся
в лог (точнее в лог буфер, который постоянно скидывается на диск)
и только в момент commit’a мы окончательно синхронизируем лог
буфер и лог файлы (на момент коммита). И только после того, как
мы записали лог, мы реально изменяем данные (сначала в памяти,
а потом когда-нибудь на диске).
12. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
MSSQL – transaction log
SQL Server помечает каждую запись в лог файле используя Logical
Sequence Number (LSN). Это монотонно возрастающее число,
более свежие записи имеют выше LSN. Log records связанные с
данной транзакцией пролинкованы в LSN chain. Log records
связаны в обратную цепочку (backword chained) – каждый log record
сохраняет ссылку на предыдущий в той же транзакции. Это
позволяет SQLServer делать rollback применяя каждый log record в
обратном порядке.
Важная концепция «active log». Начало active log’a - это старейший
LSN из всех открытых транзакций. Конец active log’a - это
наивысший записанный LSN в системе.
13. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Rollback and recovery в MSSQL
В случае краха системы MSSQL последовательно накатывает
transaction log и затем откатывает незакоммиченные транзакции.
В случае rollback - использует «Log records связаны в обратную
цепочку (backword chained)» и применяет все log records в обратном
порядке.
14. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
В Oracle все немного сложнее
Любые изменения в блоке данных сразу же генерят инструкции по
их отмене, которые записываются в UNDO. И изменения в дата
блоках и в UNDO сегменте тут же записываются в REDO log.
На самом деле вначале записываются эти инструкции в REDO, а
затем изменения происходят в UNDO и дата блоке.
См. слайд.
15. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Oracle: REDO and UNDO
1. Создаем «change vector» для UNDO record
2. Создаем «change vector» для Data block
3. Комбинируем эти 2 «change vector» в “redo record” и записываем в redo log (buffer).
4. Записываем «undo record» в UNDO block
5. Меняем data block.
16. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Почему в Oracle 2 подсистемы, почему не только
REDO
REDO нужен для обеспечения recoverability
Позволяет записывать только изменения в данных, избавляя от необходимости
синхронно записывать измененные дата блоки. Теоретически мы можем
прокрутить все изменения с момента создания «пустой» базы данных и получить
текущее состояние. Похожие подходы есть во многих (нереляционных в том
числе) базах данных, например KDB.
UNDO нужен для обеспечения согласованности по чтению и rollback’ов
Если бы мы пытались это сделать при помощи REDO, нам бы пришлось
иметь многосвязный REDO log. Сейчас это простой последовательный по времени
лог. Иначе возникла бы необходимость иметь связанность по:
• object_id – обьектам, чтобы обеспечить согласованное чтение;
• SCN – “номер транзакции” для обеспечения rollback.
В MSSQL, так как это изначально «блокировочник», согласованное чтение было не
очень актуально: читатели блокировались писателями, а rollback как раз
обеспечивается пролинковкой внутри TLOG’а (см. Log records связаны в обратную
цепочку (backward chained)).
А в новом режиме snapshot есть подобие UNDO, реализованное в tempDB для
обеспечения согласованного чтения.
16
17. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Типичный “REDO record”
REDO RECORD - Thread:1 RBA: 0x00036f.00000005.008c LEN: 0x00f8 VLD: 0x01
SCN: 0x0000.03ee485a SUBSCN: 1 03/13/2011 17:43:01
CHANGE #1 TYP:0 CLS:36 AFN:2 DBA:0x0080009a SCN:0x0000.03ee485a SEQ: 4 OP:5.1
…
CHANGE #2 TYP:0 CLS: 1 AFN:11 DBA:0x02c0018a SCN:0x0000.03ee485a SEQ: 2 OP:11.5
Видно что типичный REDO состоит из пар инструкций по
изменению UNDO и data block’a.
19. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014 19
Некоторые коды операций (из презентации Julian
Duke)
Row operations generate layer 11 redo
Opcodes include:
Opcode Mnemonic Description
11.2 IRP Insert Single Row
11.3 DRP Delete Single Row
11.4 LKR Lock Row
11.5 URP Update Row
11.6 ORP Chained Row
11.9 CKI Cluster key index
11.10 SKL Set cluster key pointers
11.11 QMI Insert Multiple Rows
11.12 QMD Delete Multiple Rows
20. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014 20
Multi Row Update
RedoStatements
COMMIT 5.4
REDO #3
UNDO #3
11.5
5.1
UNDO #2
REDO #2
5.1
11.5
REDO #1
UNDO #1
HEADER
11.5
5.1
5.2-- T1 contains 3 rows
UPDATE t1 SET c2 = c2 + 1;
COMMIT;
21. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014 21
Global Temporary Tables
RedoStatements
COMMIT 5.4
REDO #3
UNDO #3
11.2
5.1
UNDO #2
REDO #2
5.1
11.2
UNDO #1
HEADER
REDO #1 11.2
5.1
5.2
COMMIT;
-- Statement #1
INSERT INTO t1 VALUES (1);
-- Statement #2
INSERT INTO t1 VALUES (2);
-- Statement #3
INSERT INTO t1 VALUES (3);
22. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Различия Oracle и SQL Server
Oracle:
2 подсистемы: REDO & UNDO
REDO – очень простая, служит для восстановления
после сбоев, i.e. durability.
UNDO – гораздо сложнее, обеспечивает rollback’и,
согласованное чтение, i.e. atomicity, isolation
23. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Как оптимизировать «recovery» или зачем нужен
CheckPoint process
Как было сказано на предыдущем слайде, возможно получить текущее
состояние базы накатывая transaction логи (REDO логи) «с начала
времен», однако это не выглядит разумной стратегией.
И здесь вступает в действие другой процесс - checkpoint (называется
абсолютно одинаково и в Oracle и в MSSQL).
Однако осуществляет сheckpoint в основном DWR0-9 (database writer)
процесс, он записывает все грязные блоки в дата файлы.
Вспомогательный CKPT процесс обновляет заголовки дата файлов и
control file.
Задачей checkpoint процесса является «асинхронная» синхронизация
данных в памяти с данными в дата файлах на диске (в Oracle >10
разнообразных checkpoint процессов и каждый содержит свою цепочку
буферных блоков - checkpoint queue).
25. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Еще немного о checkpoint
Изначально (до 8.0) существовали только так называемые «нормальные» контрольные
точки, задачей которых было записать «грязные блоки» при переключении online redo
log’ов, что ожидаемо приводило к всплеску активности DBWR в момент такого
переключения.
Поэтому было решено размазать эту активность по времени и ввести алгоритм
«инкрементальной контрольной» точки.
•По мере того, как блоки данных в буферном кэше претерпевают изменения и
становятся “грязными”, процесс DBWR формирует очередь (checkpoint queue) из
связанных в упорядоченный по возрастанию low RBA список этих блоков. Low RBA – это
redo-адрес первого изменения блока, сделавшего его “грязным”.
•В какой-то момент времени DBWR определяет, что один из параметров, управляющий
наступлением инкрементальной контрольной точки, превысил свое пороговое значение.
Начинается выполнение инкрементальной контрольной точки. DBWR
вычисляет target RBA – то значение, до которого он будет осуществлять запись блоков
из checkpoint queue. Этим значением не обязательно будет on disk RBA – то значение,
до которого DBWR сможет безопасно записывать “грязные” буфера из буферного кэша,
так как redo-информация, защищающая эти изменения, уже записана процессом LGWR
в журнальные файлы. DBWR выберет в качестве target RBAзначение, которое вернет
после выполнения инкрементальной контрольной точки значение параметра, ее
вызвавшее, в рамки допустимого. Названия(и суть) параметров довольно сильно
менялись от версии к версии.
Подробнее в замечательной статье Сергея Маркеленкова:
http://www.fors.ru/upload/magazine/03/http_texts/russia_chech_point.html
26. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
МИФ 1ый – Oracle, MSSQL, etc. “умный”
Поэтому может оптимизировать операцию типа:
update TSTLOG2 set …, f1=f1, f2=f2 WHERE rownum <100001;
Где «на всякий случай» перечислены все поля, меняли вы их или не
меняли. Простой экперимент покажет, что это неверно как с точки
зрения DBW, так и LGWR процессов.
С логической точки зрения это операция ровным счетом ничего не
делает (update поля само в себя):
SQL>
SQL> update TSTLOG2 set f1=f1 WHERE rownum
<100001;
100000 rows updated.
Elapsed: 00:00:28.22
SQL> commit;
Commit complete.
Elapsed: 00:00:00.55
SQL>
SQL> AlTER SYSTEM CHECKPOINT;
System altered.
Elapsed: 00:00:20.15
SQL>
Видно что UPDATE часть
выполняется довольно долго (и
генерит большое кол-во redo)
NAME VALUE
---------------------------------------------------------------- ----------
redo size 2894048836
CHECKPOINT тоже нашел большое
кол-во «грязных» блоков чтобы
сбросить их на диск.
27. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Некоторые операции, которые также вызывают
checkpoint или почему мой TRUNCATE длился
полчаса.
Некоторые операции для своего правильного выполнения должны
синхронизовать состояние buffer cache c datafiles на диске.
Это DROP/TRUNCATE/и direct path операции, проведем простой
экперимент
SQL> UPDATE tstlog set f1=f1;
100000 rows updated.
SQL> commit;
Commit complete.
SQL> select /*+ PARALLEL (t 4) */count(1) from TSTLOG t;
COUNT(1)
----------
100000
SQL> select event, time_waited/100 from v$session_event where sid =
(select sid from v$mystat where rownum=1)
2 order by time_waited desc;
EVENT TIME_WAITED/100
---------------------------------------------------------------- ---------------
SQL*Net message from client 159.6
enq: KO - fast object checkpoint 7.56
PX Deq: Execute Reply 2.85
resmgr:cpu quantum .02
PX Deq: Parse Reply 0
SQL*Net message to client 0
В 1ой сессии мы сгенерили
достаточно большое кол-во грязных
блоков.
Во 2ой провели параллельный
SELECT, к-рый приводит к direct path
read операции.
Видно что мы более 7 секунд ждали
выполнения контрольной точки (из 10
сек общего времени)
28. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Еще немного о truncate/drop
Воспроизведу рассуждение Таннела Подера.
• Предположим, у нас есть большой буфферный кэш, и мы drop’аем
таблицу A без инициации контрольной точки для «грязных»
буферов.
• Сразу же после этого мы создаем таблицу B, которая
переиспользует только что освобожденное место.
• Через несколько секунд просыпается DBWR, находит «грязные»
буфера и радостно перезаписывает часть содержимого таблицы B.
Конечно, можно было бы предложить чтобы DBRW проверял какие
блоки он скидывает, тот ли это обьект и т.п., но это не слишком
естественно для такого низкоуровнего кода, который работает с
блоками а не обьектами базы данных.
http://blog.tanelpoder.com/2011/07/06/what-is-the-purpose-of-segment-level-checkpoint-
before-droptruncate-of-a-table/
29. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Миф 2: база данных читает/обрабатывает данные
построчно.
На самом деле Oracle и MSSQL обрабатывают данные по блокам:
В MSSQL - 8k блоки
В Oracle 2k,4k,8k.16k,32k блоки (стадартный тоже 8k)
Предположим, что мы решили ускорить наши SELECT’ы и прочитали в SQL
Bible или еще где-нибудь, что для этого надо сжать нашу таблицу. Звучит
разумно:
SQL> CREATE TABLE FFF AS SELECT rownum+10000 id,
2 rpad(mod(rownum,3),311,mod(rownum,3)) f1,
3 rpad(mod(rownum,2),330,mod(rownum,2)) f2 from dual
4 connect by level<10001;
Table created.
SQL> CREATE TABLE CCC COMPRESS BASIC AS SELECT rownum+10000 id,
2 rpad(mod(rownum,3),311,mod(rownum,3)) f1,
3 rpad(mod(rownum,2),330,mod(rownum,2)) f2 from dual
4 connect by level<10001;
Table created.
SQL> begin
2 dbms_stats.gather_table_stats(USER,'CCC');
3 dbms_stats.gather_table_stats(USER,'FFF');
4 end;
5 /
SQL> select table_name, blocks from user_tab_statistics where table_name in ('FFF','CCC');
TABLE BLOCKS
----- ----------
CCC 23
FFF 934
30. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Результаты экперимента
Видим, что данные ужались в 40 раз, ожидаем «взлет» производительности.
Однако произведем замер и увидим, что разница довольно «скромная»
SQL> set arraysize 10
SQL> set autot traceonly
SQL> SELECT * FROM FFF;
10000 rows selected.
Statistics
----------------------------------------------------------
1823 consistent gets
0 physical reads
6698273 bytes sent via SQL*Net to client
11352 bytes received via SQL*Net from client
1001 SQL*Net roundtrips to/from client
10000 rows processed
SQL>
SQL> SELECT * FROM CCC;
10000 rows selected.
Statistics
----------------------------------------------------------
1019 consistent gets
0 physical reads
6638309 bytes sent via SQL*Net to client
11352 bytes received via SQL*Net from client
1001 SQL*Net roundtrips to/from client
10000 rows processed
31. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Анализ:
Вспоминаем, что база данных читает данные поблочно, и только клиент
запрашивает построчно. В JDBC интерфейсе это определяется параметром
defaultRowPrefetch по умолчанию 10, аналог в sqlplus – arraysize.
Попробуем увеличить arraysize/prefetch.
SQL> set arraysize 5000
SQL> set autot traceonly
SQL>
SQL> SELECT * FROM FFF;
10000 rows selected.
Statistics
----------------------------------------------------------
916 consistent gets
6610449 bytes sent via SQL*Net to client
374 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
10000 rows processed
SQL> SELECT * FROM CCC;
10000 rows selected.
Statistics
----------------------------------------------------------
23 consistent gets
6570445 bytes sent via SQL*Net to client
374 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
10000 rows processed
На этот раз разница в количестве
обработанных блоков
приблизительно соответствует
степени сжатия
32. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Внутренняя механика обеспечения row level
locking and “versioning” в Oracle
33. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Детали read consistency/мульти-
версионного чтения
Сессия, читая блок
обнаруживает, что
есть открытый ETL,
она проверяет статус
транзакции (читает
заголовок UNDO
сегмента и видит,
что транзакция
активна.
Это значит, сессия
должна откатить
изменения
сделанные активной
транзакцией до
момента первого
изменения. Она
создает копию блока
и применяет UNDO.
34. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Детали блокировок.
Допустим сессия хочет
поменять строку
проапдейченную первой
транзакцией, эта сессия
видит open ITL, идет
проверяет статус
транзакции в Undo
segment, видит активную
транзакцию и встает в
ожидание на адресе:
usn#.slot#.wrap#
•номер сегмента
•номер слота
•порядковый номер
36. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Relation engine
MSSQL steps
• Query parsing
• Algebrizer – semantic analyses
• The query optimizer
Oracle steps
37. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Виды парсинга в Oracle
• hard parse – наиболее тяжелый, «дорогостоящий» вид парсинга,
нет никакого execution plan’a, и Oracle проходит через все стадии на
предыдущей картинке, включая оптимизацию/построение плана.
•soft parse – второй по стоимости, Oracle все еще должен провести
синтаксический и семантический разбор, провести поиск в Shared
Pool (Library Cache).
•soft-soft parse – наиболее загадочный, похоже работает только
внутри PLSQL (если есть несколько parse call внутри PLSQL то на
3ий раз, парсинг уже не происходит и инкрементится статистика
cursor authentications, зависит от session_cached_cursors)
•no parse – просто держит открытый курсор и выполняет его
несколько раз. (parse count (total) не увеличивается) Возможно в
JDBC либо явно, либо на уровне драйвера. Похоже не зависит от
“session_cached_cursors”.
См. http://docs.oracle.com/cd/E11882_01/java.112/e16548/stmtcach.htm
38. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
На сцену выходит Shared Pool
Это область памяти которая хранит
в том числе и execution plans
Nowadays, with realfree private memory
management, PGA, UGA and Callheaps are
completely separate top-level heaps (allocated
separately from OS using mmap) and UGA is
not physically inside PGA anymore.
39. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Shared Pool management challenge
Управление shared pool существенно отличается от случая buffer
cache в сторону сложности.
Buffer cache - блоки стандартного размера.
Shared pool – блоки не могут быть одного размера (слишком
неээфективно), с другой стороны, находить блок нестандартного
размера нужно достаточно быстро, мы не можем долго искать блок
нужного размера, либо конструировать его на лету.
40. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Shared pool – приблизительная схема
Free list организованы в цепочки блоков разного размера, начиная с 16
байт, затем 20, 24 и т.д.
42. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Как можно помочь shared pool’у
PreparedStatement ps = con.prepareStatement("INSERT INTO FFF VALUES (?,?,?)");
ps.setInt(1, 1);
ps.setString(2, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.setString(3, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.execute();
ps.setInt(1, 1);
ps.setString(2, "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM");
ps.setString(3, "MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM");
ps.execute();
ps.setInt(1, 1);
ps.setString(2, "NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN");
ps.setString(3, "NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN");
ps.execute();
ps.setInt(1, 1);
ps.setString(2, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.setString(3, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.execute();
ps.setInt(1, 1);
ps.setString(2, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.setString(3, "GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG");
ps.execute();
Переиспользуйте открытый курсор, JDBC драйвер может это сделать за вас, но
процесс лучше держать под контролем
43. Dmitry Remizov
14 August 2014
Deutsche Bank
В начале
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 7
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
44. Dmitry Remizov
14 August 2014
Deutsche Bank
1st execution
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
45. Dmitry Remizov
14 August 2014
Deutsche Bank
2nd execution
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
46. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
5-ый execution
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
47. Dmitry Remizov
14 August 2014
Deutsche Bank
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 7
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
NAME VALUE
--------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
NAME VALUE
---------------------------------------------------------------- ----------
parse count (total) 8
parse count (hard) 0
parse count (failures) 0
parse count (describe) 0
Общий результат
48. Dmitry Remizov
14 August 2014
Deutsche Bank
Это довольно запутанный случай из нашей практики.
Однако вероятность столкнутся с ним довольно велика при
использовании Spring framework.
Два случая представленные ниже отличаются по времени
исполнения в 100 раз (обрабатывая точно тот же массив данных).
Так что эффект колоссальный.
Что бывает, когда не заботишься о
Shared pool
49. Dmitry Remizov
14 August 2014
Deutsche Bank
List<Map<String, Object>> batchArgs = new LinkedList<Map<String, Object>>();
for (int i = 1; i < 1000; i++) {
Map<String, Object> map = new HashMap<String, Object>();
map.put("f1", getRandomNumber()); --- see we don’t define data type here explicitrely
map.put("f2", getRandomString());
……………………
map.put("f8", getRandomString());
batchArgs.add(map);
}
simpleJdbcTemplate.batchUpdate("INSERT /* BatchIssueSpring */ INTO YYYTEST
(f1,f2,f3,f4,f5,f6,f7,f8) VALUES (:f1,:f2,:f3,:f4,:f5,:f6,:f7,:f8)", batchArgs.toArray(new Map[0]));
System.out.println("time " + ((double) (System.currentTimeMillis() - startTime))/1000);
A tricky case – “untyped nulls”
time 37.36
50. Dmitry Remizov
14 August 2014
Deutsche Bank
List<MapSqlParameterSource> batchArgs = new LinkedList<MapSqlParameterSource>();
for (int i = 1; i < 1000; i++) {
MapSqlParameterSource source = new MapSqlParameterSource();
source.addValue("f1", getRandomNumber(), Types.NUMERIC);
source.addValue("f2", getRandomString(), Types.VARCHAR);
………………………………………….
source.addValue("f8", getRandomString(), Types.VARCHAR);
batchArgs.add(source);
}
simpleJdbcTemplate.batchUpdate("INSERT INTO YYYTEST
(f1,f2,f3,f4,f5,f6,f7,f8) VALUES (:f1,:f2,:f3,:f4,:f5,:f6,:f7,:f8);
batchArgs.toArray(new SqlParameterSource[0]));
System.out.println("time " + ((double) (System.currentTimeMillis() - startTime))/1000);
A tricky case 2 – let’s define “nulls” types
time 0.39
Moralite:
When something is provided for “free” try to find out the cost
51. Dmitry Remizov
14 August 2014
Deutsche Bank
private static void setNull(PreparedStatement ps, int paramIndex, int sqlType, String typeName)
throws SQLException {
if (sqlType == SqlTypeValue.TYPE_UNKNOWN) {
boolean useSetObject = false;
sqlType = Types.NULL;
try {
DatabaseMetaData dbmd = ps.getConnection().getMetaData();
String databaseProductName = dbmd.getDatabaseProductName();
String jdbcDriverName = dbmd.getDriverName();
if (databaseProductName.startsWith("Informix") ||
jdbcDriverName.startsWith("Microsoft SQL Server")) {
useSetObject = true;
}
else if (databaseProductName.startsWith("DB2") ||
jdbcDriverName.startsWith("jConnect") ||
jdbcDriverName.startsWith("SQLServer")||
jdbcDriverName.startsWith("Apache Derby")) {
sqlType = Types.VARCHAR;
}
}
catch (Throwable ex) {
logger.debug("Could not check database or driver name", ex);
}
if (useSetObject) {
ps.setObject(paramIndex, null);
}
else {
ps.setNull(paramIndex, sqlType);
}
Aroot cause of the issue on Java(Spring) side:
52. Dmitry Remizov
14 August 2014
Deutsche Bank
select sql_id, child_number, bind_mismatch, c.BIND_LENGTH_UPGRADEABLE from
v$sql_shared_cursor c where sql_id ='0ajsk0mu1sakr'
And from the database side
SQL_ID CHILD_NUMBER BIND_MISMATCH BIND_LENGTH_UPGRADEABLE
0ajsk0mu1sakr 0 N N
0ajsk0mu1sakr 1 Y N
0ajsk0mu1sakr 2 N Y
0ajsk0mu1sakr 3 Y N
0ajsk0mu1sakr 4 Y N
0ajsk0mu1sakr 5 N Y
0ajsk0mu1sakr 6 Y Y
0ajsk0mu1sakr 7 Y N
0ajsk0mu1sakr 8 N Y
0ajsk0mu1sakr 9 Y Y
0ajsk0mu1sakr 10 N Y
0ajsk0mu1sakr 11 Y Y
0ajsk0mu1sakr 12 Y Y
0ajsk0mu1sakr 13 Y N
.......................................................................................................
Incredible amount of child cursors: >300 (after 3-4 executions)
It could lead to:
• extreme slowness
• the session death
53. Dmitry Remizov
14 August 2014
Deutsche Bank
Let’s compare ROWS/EXECUTIONS and other metrics:
SELECT y.sql_id,
y.rows_processed,
ROUND (y.rows_processed / NULLIF (y.elapsed_time, 0) * 1000000, 2) AS rows_per_sec,
ROUND (y.rows_processed / NULLIF (y.executions, 0), 2) AS rows_per_exec,
ROUND (y.elapsed_time / 1000000 / NULLIF (y.executions, 0), 2) AS sec_per_exec
FROM v$sql y
WHERE y.sql_id in ('0ajsk0mu1sakr','5twjz0zzm07z0')
ORDER BY y.sql_id desc;
Some SQL metrics for both cases
SQL_ID ROWS_PROCESSED ROWS_PER_SEC ROWS_PER_EXEC SEC_PER_EXEC
-- explicetely defined data type
5twjz0zzm07z0 999 16903.55 999 0.06
-- undefined data types
0ajsk0mu1sakr 54 1026.87 1.04 0
0ajsk0mu1sakr 14 1052.32 1.27 0
0ajsk0mu1sakr 14 1462.45 2 0
0ajsk0mu1sakr 12 859.05 1 0
0ajsk0mu1sakr 21 1513.08 1.91 0
0ajsk0mu1sakr 7 769.74 1.4 0
0ajsk0mu1sakr 19 1498.66 1.9 0
0ajsk0mu1sakr 515 3285.17 2.75 0
………………………………………………………………………………………………………………………………………………………
54. Dmitry Remizov
14 August 2014
Deutsche Bank
Jonathan Lewis: Oracle Core Essentials for DBAs and Developers.
Delaney Kalin: Inside Microsoft SQL Server 2005 The Storage Engine
http://blog.tanelpoder.com/
http://technet.microsoft.com/en-us/library/cc280362(v=sql.105).aspx
http://jonathanlewis.wordpress.com/
Oracle 9i OpSem materials
Литература
55. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Критика традиционных RDBMS
•Latching
•Locking
•Buffer pool
•Recovery
Сьедают до
95% времени
60. Identifier
Deutsche Bank Dmitry Remizov
14 August 2014
Критика критики
На самом деле 95% преувеличение, но процентов 70-80% есть.
В отдельных случаях вы можете отказатся от части сервисов
RDBMS, например, NOLOGGING операции в data warehousing.
Использование субсекционирования, чтобы уменьшить
конкуренцию почти до 0, каждый поток льет в свой отдельный
сегмент и т.д.
