На винде я как-то уж очень привык: WSL + rlwrap + sqlplus. Для "админских" целей, траблшутинга и перфоманс тюнинга большего и не надо: более полутора тысяч своих готовых скриптов для sqlplus в гитхабе и все ок… Readline в rlwrap многократно удобнее кривого редактирования в sqlcl. Особенно, в случае длинных и многострочных команд. Да, у sqlcl много удобных новых фич, но его кривой консольный ввод и вывод автодополнения — это ужас какой-то.
в sqlplus это особая команда: выполнить команду после неё, не прерывая изменений текущего буфера. Например, ты ввёл
Select
Sysdate
И забыл имена полей, которые хочешь достать, тогда прямо в следующей строке пишешь, скажем "#desc some_table". Посмотрел столбцы и пишешь дальше.
Да, функции — это убийцы производительности, если их неправильно готовить. А в случае, если это ещё и легко заменить простым составным выражением, то уж лучше добавить виртуальное поле и на нем уже создать индекс.
Oracle очень и очень гибок, у него огромное количество разнообразных параметров и настроек на всех уровнях всех подсистем, намного больше чем у MS SQL Server, DB2, Postgres и MySQL вместе взятых, что позволяет его подстроить так как необходимо конкретной системе. Естественно, что это требует хорошего знания как самого Oracle так и смежных систем. Это же не какой-нибудь SQLite. Не хотите ничего "помнить" — пользуйтесь excel или csv файликами.
все это нужно «всего лишь» для совместимости, которая, возможна нужна не многим.
Большое количество очень крупных клиентов с очень давних времен на Oracle с крайне важными данными, поэтому вопросы надежности и совместимости это наиболее важные вопросы. По этой причине очень-очень многие обновляются на новые версии очень неохотно и только после того как новые версии становятся достаточно стабильными. Даже платят огромные суммы за Extended support. Процесс накатки скриптов для Oracle тоже уже давным давно в серьезных системах отлажен и включает все необходимые настройки и параметры. Посмотрите, например, на огромные документы от SAP.
существующие строки не будут затронуты. И для того чтобы и их сделать такими же, требуется перестройка таблицы…
Что это за бред в первом пункте? Что конкретно в существующих строках хотели менять? По вашему каждое varchar2 поле каждой строки хранит свой nls_length_semantics?!
INIT.ORA
Вот прямо в INIT.ORA?!
есть множество зарегистрированных багов
Багов вообще множество в чем угодно, если ссылаетесь на что-то, то уж будьте любезны приводить хотя бы пару примеров.
доходит до того что при выставленом параметре nls_length_semantics=CHAR, например, невозможно проимпортировать дамп
Ой ли?!
все равно необходима перезагрузка экземпляра чтобы импорт заработал
Datapump это в принципе не нужно, тк он экспортирует описание вместе с nls_length_semantics столбцов источника и соответственно вставляет его при создании. Это вызывало определённые проблемы при экспорте столбцов, которые были определены с BYTE с однобайтовых баз в уникодные(те строки при конвертации из однобайтовых в уникод становились длиннее) и тогда используют стандартное решение с импортом в два этапа: сначала metadata only, затем alter нужных столбцов и затем уже импорт данных
Конечно, ставлю плюс за такой энтузиазм и кучу потраченного времени на саму статью.
Но… в общем-то, это все общеизвестно: и подход, и методика и такие куцые выводы. В оракле вообще гораздо важнее знать внутренние механизмы, и уже зная их можно заниматься не только тюнингом параметров, но и вообще траблшутингом как производительности, так и ошибок и багов. И, если уж заниматься таким копанием, то лучше брать боевые версии EE или SE, прикрутить systemtap, и покопать, например, насколько и в какие именно внутренние функции замедлились или ускорились после апгрейда 12.2 -> 18, 18 -> 19
Вклад магии Exadata в производительность базы данных не высок — не превышает 5 %, а база данных «экзадатится» плохо.
Ну в общем-то так и есть, если не учитывать криво посчитанный процент:
1 млн ожиданий у смартскана и в сумме всего ~1200сек — пусть даже соффлоудилось идеальные 90%, то это всего будет лишь в ~10 раз больше (плюс-минус из-за погрешности в переходе к cell multiblock/singleblock block read + увеличение объема пересылки + в худшем случае — построчные фильтры) — итого ну пусть даже в 20 раз больше — 24к сек — совсем пустяки.
IO действительно мало, а прочие два ожидания (cell single block/multiblock physical read) собственно и не оффлоудятся. В крайних случаях, это, конечно, может привести к тяжелым проблемам, например, если кол-во сессий в этой системе маленькое и они просто кучу данных молотят 100% времени, затыкаясь в притык по SLA — в таком случае — да, небольшое замедление может привести к проблемам, но в прочих реально многопользовательских системах с таким перекосом в CPU (непонятно еще как оно распределено было и что в бэкграунде творилось), будет лишь незначительное замедление IO, но никак не упрется в его лимиты. Если из этих 70% DBTime лишь микрозапросы по кэшам, PL/SQL да прочие числомолотилки — то smartscan/не смартскан — что слону дробина
Не очень понял причем тут AWR… Просто нужные статистики другие и смотреть их можно прямо в том же AWR, например:
col END_INTERVAL_TIME for a20
col stat_name for a64
break on END_INTERVAL_TIME
select
to_char(ss.END_INTERVAL_TIME,'yyyy-mm-dd hh24:mi') END_INTERVAL_TIME
,st.stat_name
,st.value
from dba_hist_snapshot ss
,dba_hist_stat_name sn
,dba_hist_sysstat st
where
ss.END_INTERVAL_TIME between systimestamp-interval '24' hour
and systimestamp-interval '23' hour
and ss.dbid = (select dbid from v$database)
and sn.dbid = (select dbid from v$database)
and st.dbid = (select dbid from v$database)
and (st.snap_id,st.dbid,st.instance_number) in (
(ss.snap_id,ss.dbid,ss.instance_number)
)
and st.stat_id=sn.stat_id
and sn.stat_name like 'cell%'
and (sn.stat_name in (
'cell session smart scan efficiency'
,'cell physical IO bytes saved by storage index'
,'cell physical IO bytes eligible for predicate offload'
,'cell physical IO interconnect bytes returned by smart scan'
,'cell IO uncompressed bytes'
)
or
sn.stat_name like 'cell blocks processed%'
)
/
Вы работаете только с локальным каким-то бизнесом без интернализации и сложных финансовых проводок? Дело в том, что sysdate/systimestamp — не бизнесовые даты. На самом деле, очень много различных тонкостей бывает, начиная со смены таймзоны (летнее/зимнее/отмена летнего/миграция/расширение в другой регион и тд) и заканчивая отложенных или будущих операций. Sysdate/systimestamp пойдут для обычного логгинга или другого не особенно завязанного на время функционала, но не для бизнес операций, как например, тот же опердень в банкинге. Своя кастомная функция позволяет это все строго формализовать в одном месте.
Вообще обычно правильнее использовать в своём коде свою кастомную функцию вместо sysdate/current_xxx. Это наиболее распространённый, простой и гибкий подход.
Индексы и констрейнты на таблице логов?! Если эта штука для постоянного логгирования, то её нужно сделать максимально быстрой и легковесной. А для трассировки pl/sql все-таки в оракле есть иерархический профайлер…
Да что вы говорите… Более предсказуема? Кому? И давно вы анализировали код PostgreSql? Достаточен ли ваш уровень чтобы анализировать его код? А сколько вообще разработчиков, работающей с СУБД с достаточным уровнем c/c++? Как вы считаете, что быстрее и удобнее и правильнее: прочитать гайд, документацию или исходный код СУБД?
Зы. Что-то своих статей не пишите с анализом кода pg, а только переводите чужие в которых нет ни одного куска кода...
Зыы. Может уже остановитесь со своей маркетинговой чушью?
На винде я как-то уж очень привык: WSL + rlwrap + sqlplus. Для "админских" целей, траблшутинга и перфоманс тюнинга большего и не надо: более полутора тысяч своих готовых скриптов для sqlplus в гитхабе и все ок… Readline в rlwrap многократно удобнее кривого редактирования в sqlcl. Особенно, в случае длинных и многострочных команд. Да, у sqlcl много удобных новых фич, но его кривой консольный ввод и вывод автодополнения — это ужас какой-то.
Select
Sysdate
И забыл имена полей, которые хочешь достать, тогда прямо в следующей строке пишешь, скажем "#desc some_table". Посмотрел столбцы и пишешь дальше.
Да, функции — это убийцы производительности, если их неправильно готовить. А в случае, если это ещё и легко заменить простым составным выражением, то уж лучше добавить виртуальное поле и на нем уже создать индекс.
Oracle очень и очень гибок, у него огромное количество разнообразных параметров и настроек на всех уровнях всех подсистем, намного больше чем у MS SQL Server, DB2, Postgres и MySQL вместе взятых, что позволяет его подстроить так как необходимо конкретной системе. Естественно, что это требует хорошего знания как самого Oracle так и смежных систем. Это же не какой-нибудь SQLite. Не хотите ничего "помнить" — пользуйтесь excel или csv файликами.
Большое количество очень крупных клиентов с очень давних времен на Oracle с крайне важными данными, поэтому вопросы надежности и совместимости это наиболее важные вопросы. По этой причине очень-очень многие обновляются на новые версии очень неохотно и только после того как новые версии становятся достаточно стабильными. Даже платят огромные суммы за Extended support. Процесс накатки скриптов для Oracle тоже уже давным давно в серьезных системах отлажен и включает все необходимые настройки и параметры. Посмотрите, например, на огромные документы от SAP.
Что это за бред в первом пункте? Что конкретно в существующих строках хотели менять? По вашему каждое varchar2 поле каждой строки хранит свой nls_length_semantics?!
Вот прямо в INIT.ORA?!
Багов вообще множество в чем угодно, если ссылаетесь на что-то, то уж будьте любезны приводить хотя бы пару примеров.
Ой ли?!
Да ну?!
Datapump это в принципе не нужно, тк он экспортирует описание вместе с nls_length_semantics столбцов источника и соответственно вставляет его при создании. Это вызывало определённые проблемы при экспорте столбцов, которые были определены с BYTE с однобайтовых баз в уникодные(те строки при конвертации из однобайтовых в уникод становились длиннее) и тогда используют стандартное решение с импортом в два этапа: сначала metadata only, затем alter нужных столбцов и затем уже импорт данных
Да, в целом, если сильно упростить, то любой тюнинг — это практически всегда компромисс между кучей факторов.
Конечно, ставлю плюс за такой энтузиазм и кучу потраченного времени на саму статью.
Но… в общем-то, это все общеизвестно: и подход, и методика и такие куцые выводы. В оракле вообще гораздо важнее знать внутренние механизмы, и уже зная их можно заниматься не только тюнингом параметров, но и вообще траблшутингом как производительности, так и ошибок и багов. И, если уж заниматься таким копанием, то лучше брать боевые версии EE или SE, прикрутить systemtap, и покопать, например, насколько и в какие именно внутренние функции замедлились или ускорились после апгрейда 12.2 -> 18, 18 -> 19
Ну в общем-то так и есть, если не учитывать криво посчитанный процент:
1 млн ожиданий у смартскана и в сумме всего ~1200сек — пусть даже соффлоудилось идеальные 90%, то это всего будет лишь в ~10 раз больше (плюс-минус из-за погрешности в переходе к cell multiblock/singleblock block read + увеличение объема пересылки + в худшем случае — построчные фильтры) — итого ну пусть даже в 20 раз больше — 24к сек — совсем пустяки.
IO действительно мало, а прочие два ожидания (cell single block/multiblock physical read) собственно и не оффлоудятся. В крайних случаях, это, конечно, может привести к тяжелым проблемам, например, если кол-во сессий в этой системе маленькое и они просто кучу данных молотят 100% времени, затыкаясь в притык по SLA — в таком случае — да, небольшое замедление может привести к проблемам, но в прочих реально многопользовательских системах с таким перекосом в CPU (непонятно еще как оно распределено было и что в бэкграунде творилось), будет лишь незначительное замедление IO, но никак не упрется в его лимиты. Если из этих 70% DBTime лишь микрозапросы по кэшам, PL/SQL да прочие числомолотилки — то smartscan/не смартскан — что слону дробина
Вполне нормальный документ для этого: Smart scan: Find the statistics related to cell offload (Doc ID 1438173.1)
Не очень понял причем тут AWR… Просто нужные статистики другие и смотреть их можно прямо в том же AWR, например:
Не знаю как насчёт MS SQL Server, но в оракле они появились ещё в 8i, а это 1999 год
Спасибо, собственно, так и думал, что сейчас все ведущие rdbms это умеют, поэтому совет с переписыванием и удивил.
PostgreSql не умеет переписывать "x in (select..." <-> "exists (...) "?
Вы работаете только с локальным каким-то бизнесом без интернализации и сложных финансовых проводок? Дело в том, что sysdate/systimestamp — не бизнесовые даты. На самом деле, очень много различных тонкостей бывает, начиная со смены таймзоны (летнее/зимнее/отмена летнего/миграция/расширение в другой регион и тд) и заканчивая отложенных или будущих операций. Sysdate/systimestamp пойдут для обычного логгинга или другого не особенно завязанного на время функционала, но не для бизнес операций, как например, тот же опердень в банкинге. Своя кастомная функция позволяет это все строго формализовать в одном месте.
Вообще обычно правильнее использовать в своём коде свою кастомную функцию вместо sysdate/current_xxx. Это наиболее распространённый, простой и гибкий подход.
А почему не просто установить параметр fixed_date?
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/refrn/FIXED_DATE.html#GUID-2AE0D45E-C4EB-4A12-87F0-69F7CFF1CB30
Индексы и констрейнты на таблице логов?! Если эта штука для постоянного логгирования, то её нужно сделать максимально быстрой и легковесной. А для трассировки pl/sql все-таки в оракле есть иерархический профайлер…
Да что вы говорите… Более предсказуема? Кому? И давно вы анализировали код PostgreSql? Достаточен ли ваш уровень чтобы анализировать его код? А сколько вообще разработчиков, работающей с СУБД с достаточным уровнем c/c++? Как вы считаете, что быстрее и удобнее и правильнее: прочитать гайд, документацию или исходный код СУБД?
Зы. Что-то своих статей не пишите с анализом кода pg, а только переводите чужие в которых нет ни одного куска кода...
Зыы. Может уже остановитесь со своей маркетинговой чушью?