Database Technologies...!

What is MySQL int max value? MySQL int max value is 2147483647 when signed and of 4294967295 when unsigned. Although rare, there are situations where auto increment columns does reach MySQL int 11 max value specially when signed. Comparison of MySQL int data types and there max values MySQL provide five int data types, TINYINT - 1 byte - max 127 signed and 255 unsigned  SMALLINT  - 2 bytes - max 32767 signed and 65535 unsigned  MEDIUMINT - 3 bytes - max 8388607 signed and 16777215 unsigned  INT (11) - 4 bytes - max 2147483647 signed and 4294967295 unsigned BIGINT - 8 bytes - max 2 63 - 1 and 2 64 - 1 unsigned First three int types can be used when the highest value is predictable, else it is always safe to go for MySQL int 11 or bigint. Bigint does provide huge limit advantage over int 11 , compromising the fixed storage space usage of  2 times (8 bytes compared to 4 bytes) which can cause access overheads as well. Script to identify auto increment columns reaching MySQL max int va

Background When troubleshooting  any database performance issue, we need to understand that it can happen in two possible sequence, 1. Additional large utilization (load) on database server causing the delay in normal database operation. Which can be from newly added application component, query that is running abnormally (e.g plan change),  new parallel execution etc.. 2. A change or suboptimal operation on underlying hardware/software layer that causes the default load of the database to take more time than it usually does. Here database system is not the culprit but the victim. It is trying its best to perform as it used to, but a bottleneck in different layer that is not in the control of database is causing the delay. Example Below is a demonstration using iostat command in Solaris environment running Oracle database, which shows the metric differences while database system is experiencing performance delays. In both situation the result is the same, distorted db performance wher

ORA-16433 is an error returned when a database cannot be opened. This can be a result of multiple conditions including, The inconsistency of the database Physical corruption Loss of dependent files or access issues etc.. More often than not the solution is to recover from available backups, but there can be situations where backups are not available, specially on UAT or Test setups. Although not the ideal scenario, in this type of situation you might want to open the databases even with inconsistency.  In Comes --> _ALLOW_RESETLOGS_CORRUPTION First, if you are in a position to use _ALLOW_RESETLOGS_CORRUPTION=TRUE, that means it has to be a critical moment, and when you come across more ora- errors while you are trying to reopen the databsae, that can be annoying. Note - _ALLOW_RESETLOGS_CORRUPTION=TRUE must only be used after Oracle support confirmation as a last resort. Also make sure to take cold backup before proceeding. Basic steps to be followed to resolve ORA 16433 after