When a new release of software product arrives, users usually wait for some time (some years!) until the release "settles" and the major bugs in the new release are fixed. Testing of new release/version is time and resource consuming, so customers are waiting in order to minimize their problems after upgrade to new release/version.
Such an users often ask the question - is it time to move to a new release? Is new release is “good enough” ?
It is difficult to measure the stability of new release. So, the user’s question is somewhat philosophical …
You can think of different measures. For example, you can look to follow other users - have they switched to a new release or not? Or, you can simply wait for 2 years in the hope that this is a long enough period.
As my own measure, I use the number of bugs fixed in the quarterly patchset. The background logic behind this number: at first, after a new version is released, very few users start using it. Therefore, the number of patches in a quarterly patch is pretty small. Gradually, the activity of users grows, and the number of identified bugs grows, so the number of patches in the patchset also increases. This is the growth stage of experimental use. But gradually the software product become to a such stage when all major bugs have already been fixed and the number of patches in the patchset decreases. This point can be considered as the maturity of a software product.
Usually, after the quarterly patchset have been released I usually estimate "by eye" whether there are more or fewer a number of patches in this quarterly patchset as compare to the previous quarter. But now I decided to calculate exact numbers for 19c release.
Когда выходит новая версия какого-то программного продукта, то пользователи обычно ждут некоторое время пока эта версия "отстоится" и в новой версии будут исправлены основные баги, чтобы минимизировать свои трудозатраты после перехода на новый релиз/версию.
Поэтому пользователи часто задают вопрос - настало ли время переходить на новый релиз? Достаточно ли он отлажен к настоящему времени, чтобы на него переходить ?
Сложно придумать свободную от недостатков меру, по которой можно было бы судить - а достаточно ли отлажен какой-то релиз? Как вообще оценить отлаженность программного продукта, по каким критериям? - воопрос в чём-то философский ...
В качестве своей собственной меры я использую количество багов, которые устранены в квартальном пачсете.
Логика здесь такая: вначале, после выхода нового релиза, мало кто из пользователей начинает его сразу использовать. Поэтому количество патчей в квартальном пачсете как правило небольшое. Постепенно активность пользователей растёт, и следом растёт количество выявленных проблем, поэтому количество патчей в пачсете тоже увеличивается.
Это стадия роста и экспериментального использования пользователями программного продукта.
Но постепенно программный продукт достигает такого состояния, когда все основные баги уже исправлены и количество патчей в пачсете уменьшается.
Такую точку перегиба можно считать началом зрелости программного продукта.
Поэтому после выхода каждого квартального пачсета я обычно прикидываю "на глазок" больше или меньше стало патчей в данном квартальном пачсете по сравнению с предыдущим кварталом.
Рассмотрим ноту "Database 19 Release Updates and Revisions Bugs Fixed Lists (Doc ID 2523220.1)". Из неё получаем следующую статистику:
Oct-20 Jan-21 Apr-21 Jul-21
19.9 19.10 19.11 19.12
Advance Queuing 4 6 10 6
ASM 10 31 22 26
Buffer Cache Management 8 14 19 12
Generic 77 161 217 114
High Availability 31 72 124 56
Diag 1 2 1 1
Heterogenous Services 0 3 1 1
JVM 0 0 0 0
Multitenant 6 23 22 8
Net 0 0 4 0
OLAP 0 1 0 1
LOB 1 1 4 2
Security 7 11 15 3
Security Service 2 2 6 3
TableSpace management 16 31 39 22
Storage Server Service 13 6 5 2
Streams 1 10 4 2
Transaction Mgmt 9 10 20 8
Universal Storage Mgmt 0 1 1 0
Utilities 1 10 10 3
Virtual OS 12 32 37 21
PL/SQL 4 4 14 5
Manageability 1 14 12 7
XML Utilities 1 1 4 3
XML database 3 19 25 17
Miscellaneous 29 47 114 60
ИТОГО: 237 512 730 383
+216% +43% -48%
512/237=2,16 730/512=1,43 383/731=0,52
The numbers show that the April 2021 patchset (19.11) became an inflection point, after which the number of bug fixes dropped significantly.
Статистика показывает, что апрельский пачсет 2021 года (19.11) стал точкой перегиба, после которой количество исправленных багов значительно снизилось.
Также в 19.12 добавлены новые возможности:
спасибо, Юра, за статистику
ReplyDeleteболее всего в версии 19 опечалило то, что потребовалось 11 патчсетов для выхода на более-менее стабильную версию - процесс как-то необычайно затятут или тестирование хромает, в прежних "больших" версиях хватало 4-6 патчсетов,
тебе не кажется?
Данная статистика не претендует на истину в последней инстанции. Много багов будет заметно только на очень больших базах, которые используют много новых возможностей 19с. А те, кто использовал возможности 18с-12с-11с... - у них код работает также как работал.
ReplyDeleteНачиная с октября 2020 пошли миграции на 19с. Также прошли несколько успешных тестирований. И особых проблем мы не заметили, всё работало нормально. Были проблемы на стендбае с MIRA (multi-instance redo apply). Но это новая функциональность и кое-где требовалась отладка. Были выпущены патчи, которые затем вошли в 19.11.
В общем, не каждому программному продукту требуются все возможности СУБД Оракл. А новые возможности начинают использоваться спустя некоторое время после миграции.
Поэтому зачастую всё хорошо.
Главное - протестировать работу приложения на новой версии/релизе. А это редко кто делает. И не всегда тщательно.
This comment has been removed by the author.
ReplyDelete"А те, кто использовал возможности 18с-12с-11с... - у них код работает также как работал"
ReplyDelete- не совсем соответствует нашим наблюдениям, код, конечно же, работает также, но:
1. поведение оптимизатора/планы запросов местами значительно изменились
2. бд работает иначе в части ожиданий, кластерных блокировок и т.д.
Собственно, в этом и состоит проблема обновления нагруженных бд и кол-во багов явно подтверждает кол-во проблем, большая часть которых относится не к новым, а к старым возможностям Oracle, к сожалению