Insane DBA...

I’m thrilled to announce that I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content.

Step by step guide for securing your PostgreSQL Database Environment I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. In today's world, keeping data secure is absolutely crucial. As companies depend more and more on databases to handle all sorts of sensitive information, making sure those databases are locked down tight is a top priority. Ensuring the overall security of PostgreSQL is a multifaceted task that involves implementing various measures to protect the database from potential threats. Many measures may be taken in every layer of the database environment. I will explain some in detail and summarize others in one sentence. Lets start with the database itself. Secure PostgreSQL Database: 1. Authentication and Authorization : Use RBAC (role based access control),

100's of times faster Spatial operators and functions I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. Last week, I tried to diagnose an application problem which mostly consisted of queries related to spatial operators. When I delved into the issue, I discovered that the SPATIAL_VECTOR_ACCELERATION parameter was set to false on my mission-critical databases, despite the spatial component being used effectively. Although many bloggers had written about it, I was not aware of this parameter. So I wanted to draw everyone's attention to this parameter.   According to the Vector Performance Acceleration in Oracle Spatial and Graph (Doc ID 1506885.1) , In Oracle Database versions 12c and above, significant enhancements have been made to improve vector operations through

Upgrade Your PostgreSQL Database: Major Steps and Minor Touches I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. In this blog post, I will show how a complete PostgreSQL environment major update can be done. Minor upgrades are not a tough task; they are no different from a standard Linux package upgrade. As my production environment serves in an airgapped-environment, I will complete all the major upgrades with no internet connection. I've downloaded all the required whl and .rpm packages before the upgrade. Before starting, a short description of major and minor PostgreSQL upgrades is provided below: Major Upgrade: Upgrading PostgreSQL to a new major version, such as moving from 10 to 11 or 12 to 13. Major upgrades bring significa

Ansible to Rule Them All I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. In the previous post " Oracle Grid Software Patching by using Ansible Playbooks" , I mentioned how Ansible orchestration can be used to make Oracle Grid Software Patching a cleaner and simpler process. Now I will also patch database software using Ansible Playbooks. In this post,  I will use the blt01 host as the ansible host. The target environment is a two-node RAC database (gns01, gns02). I will patch the grid software to 19.22 using the out-of-place methodology with no downtime.  Although there are lots of useful blog posts about how you may use Ansible for automating tasks, there is not much about complete Oracle database software patching.  Ansible is simply installed by running "y

Ansible is a friend in need and a friend indeed for DBAs. I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. In this blog post, I will mention about Redhat Ansible and show how you can patch your grid infrastructure by using it. Ansible is an open source, command-line IT automation software application written in Python. It can configure systems, deploy software, and orchestrate advanced workflows to support application deployment, system updates, and more. Ansible's main strengths are simplicity and ease of use. It is a little bit similar to dcli commands in Exadata environments, but much more powerful as you may run playbooks which consist of different tasks. Ansible stands out from other configuration management tools because it doesn't need agents installed on target host

GOOD NEWS is, It will kick in soon. I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. Last week, when I was investigating a performance issue, I observed that an identical query resulted in different execution plans in TOAD and sqlplus. According to " Doc ID 1671642.1 How To Diagnose Why an Identical Query Has Different Plans (and Performance) in Different Environments ", there may be different factors in plan selection. Although not all, some of them are as follows: Statistics   * Base Object Statistics   * System Statistics   * Dynamic Statistics (OPTIMIZER_DYNAMIC_SAMPLING)   * Statistics Feedback (_OPTIMIZER_USE_FEEDBACK) Physical Differences   * Physical and Logical Layout of the Database     * Different volume and distribution of data     * Different block sizes (D

I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. INTRO   In one of our critical OLTP database, we faced " Latch: cache buffer chains " wait event issue(a long running query) on a commonly used page. Long running query was called inside a PL/SQL package function. To alleviate the situation, first we changed the function to a deterministic function and rewrite the query's function call into a scalar subquery allows Oracle to use scalar subquery caching to optimize the number of function calls. As these cautions could not cure the issue and segment access statistics were not even, we changed table partitioning strategy from list partitioned to hash-partitioned. For the problematic query issue was solved, but a batch job which completes in 5 minutes before, started to

I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. Previously on my blog post ( Sometimes a histogram existence may mislead to a suboptimal plan ), I analyzed a poorly performing query in detail and detected that sometimes a histogram existence may mislead to a suboptimal plan. I have listed some possible solutions.  But what i applied as a solution was to emulate a partial/filtered index in Oracle.   I know partial indexes concept from Postgresql database, it is also available on MS SQL and some others.  What is Partial Index? ... A partial index is an index built over a subset of a table; the subset is defined by a conditional expression (called the predicate of the partial index). The index contains entries only for those table rows that satisfy the predicate. Partial indexes

Manipulating table statistics for the statement period I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. On my blog post " Who makes the decisions? I thought it was Optimizer ", I used parallel hint to force a direct path read. This time I will try to make use of table_stats hint to force a direct path read. There is not much documentation about the usage of this hint. Roger Macnicol's blog post ( Correct syntax for the table_stats hint  ) offers up some useful information about it. These are the variables that play a role in direct path read decision.  STT stands for small table threshold = _db_block_buffers * 0.02 =  3875820 * 0.02 = 77516 MTT stands for medium table threshold = _small_table_threshold * 5 = 77516 * 5 = 387580 VLOT stands for Very Large Object Thres

The reason behind is NLS_SETTINGS I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. I generally use Stew Ashton's below query to summarize reasons why cursors are not shared.  In one of our production database, the amount of child cursor count related to "LANGUAGE_MISMATCH" attracted my attention and I tried to make clear the reason behind. According to the  Database Hang With 'cursor: mutex X' Contention Due To High Version Count Under LANGUAGE_MISMATCH (Doc ID 2542447.1) , whenever there are different NLS settings that get changed in different combinations in every execution, it creates new child cursors and the version count increases with LANGUAGE_MISMATCH. Exactly the same queries and PL/SQL packages are called from different applications . Differ

Some decisions are actually not taken by the optimizer. I’ve moved my blog from https://insanedba.blogspot.com to https://dincosman.com Please update your bookmarks and follow/subscribe at the new address for all the latest updates and content. More up-to-date content of this post may be available there. We started to experience a performance problem with an SQL query which we cannot change the software code and tried to find a solution in solely the database layer.  SQL query was a sophisticated one, but the problem can be summarized with the short one below. Here is the plan output. Products table was a large table exceeding 50 Gb size and query's execution time was 180 - 200 seconds.  Query was searching in PRODUCTS table for the HTML_CONTENT with not null records, but for all rows,  HTML_CONTENT column values were null, and as this column is not indexed, the query was performing a full table scan