<<- Long term hopeful, short term worried
As I said in my blog post a couple of days ago, I’m very concerned about the new variant of SARS-CoV-2 that has been spreading through the UK and is now being found in countries all over the world. My main concern is that this could be what pushes our health services beyond the limit of what they can stretch to and, as a result deaths will jump up – and not just from Covid-19.
.
This was initially posted to CERN Database blog on Wednesday, 12 September 2018 where it seems to be lost. Here is a copy thanks to web.archive.org
I create a table for the demo. The CTAS gathers statistics (12c online statistics gathering) with one row and then I insert more rows:
10:33:56 SQL> create table DEMO as select rownum n from dual;
Table DEMO created.
10:33:56 SQL> insert into DEMO select rownum n from xmltable('1 to 41');
41 rows inserted.
10:33:56 SQL> commit;
Commit complete.
The estimations are stale: estimates 1 row (E-Rows) but 42 actual rows (A-Rows)
This blog is about the oracle database wait event ‘reliable message’. It should be noted that normally, this should not be a prominent wait, and if it does so, the most logical cause would be something that is not working as it should, either by oversubscribing something or simply because of a bug.
The reliable message note on My Oracle Support provides a good description:
https://support.oracle.com/epmos/faces/DocContentDisplay?_afrLoop=34595019638128&id=69088.1&_afrWindowMode=0&_adf.ctrl-state=15ief27plw_97
New Variant & impact on NHS->>
<<- Start of Original Post beginning in March
After quite a break, I’ve decided to return to converting my notes & thoughts on Covid-19 and SARS-CoV-2 into blog posts again, but I’m going to do so in a slightly different format. Why am I returning to blogging on the topic? Well, people do still keep asking me what is going on and I’ve mostly been answering on Twitter or Facebook (or in person on the rare occasions I meet people!), but I don’t feel Twitter and Facebook are particularly good forums for explaining things. And writing it down in a way I feel someone with a little bit of scientific understanding can understand helps me understand and, more importantly, makes me check the scientific output to try and make sure I am right.
Hopefully I got your interest by the weird name of this blogpost. This blogpost is about sensible usage of an Oracle database. Probably, there are a lot of blog posts like this, but I need to get this off my chest.
A quote any starwars fan would recognise is ‘I sense a disturbance in the force’. I do, and I have felt it for a long time. This disturbance is the usage of the number of connections for a database. Because of my profession, this is the oracle database, but this really applies to the server-side of any client/server server processor running on at least (but probably not limited to) intel Xeon processors.
The disturbance is the oversubscription or sometimes even excessive oversubscription of database connections from application servers, or any other means of database processes that acts as clients. This means this does not exclude parallel query processes, in other words: this applies to parallel query processes too.
There are times when an upgrade makes a big difference to performance because an enhancement to the optimizer code path changes the costing of a plan that was always possible, but badly costed. I noticed an example of this while testing the code in the email I mentioned in last month’s posting on the “Incremental Sort” that Postgres 13 can do. Here’s a model to create some data and demonstrate the principle – the code is a modified (reduced) version of the code published by Phil Florent describing the feature.
This issue has shown up in multiple customer applications with CockroachDB. This typically occurs in an environment that has a small amount of data that fits into a single range within CockroachDB. Often micro-services that poll data for dashboards or workflow applications can drive up usage with a small of data.
After working with customers for about 18 months now, I am starting a blog series to write up the common issues seen while running CockroachDB. Diagnosis and treatment of issues when running on distributed database architectures like CockroachDB, closely mirror the process used in the medical community.
There are observed symptoms which leads to a diagnosis and finally a treatment to resolve the condition. Good troubleshooting methodology can help frame the problem which leads to better overall outcomes. This process is outlined below:
Here’s a little puzzle – and if you don’t see the answer almost immediately you did need to read this note. The question comes from a thread on the Oracle Groundbreakers’ Forum –
“Why I am getting 0020 instead of 2020 for below query?”
select to_char(to_date(sysdate,'dd-mm-yyyy'),'iyyy') from dual.
Instead of sysdate if I give date like ‘5-dec-2020’ it’s giving correct. Any ideas why iso value for sysdate year is coming as 0020?
Recent comments
3 years 3 days ago
3 years 12 weeks ago
3 years 17 weeks ago
3 years 17 weeks ago
3 years 22 weeks ago
3 years 43 weeks ago
4 years 11 weeks ago
4 years 41 weeks ago
5 years 25 weeks ago
5 years 26 weeks ago