16.6.23

Increasing Redo Log Size in Oracle Database: A Step-by-Step Guide

 In Oracle Database, the redo log plays a crucial role in ensuring data integrity and recovery. It records all changes made to the database, providing a means for recovery in the event of a failure. In high-transaction environments, it may be necessary to increase the redo log size to accommodate the workload and optimize performance. This step-by-step guide will walk you through the process of increasing the redo log size in Oracle Database.


Step 1: Check the Current Redo Log Configuration

Start by querying the V$LOG view to gather information about the current redo log groups. This will provide details such as group number, thread number, status, members, and sizes. Use the following SQL statement:


SELECT GROUP#, THREAD#, ARCHIVED, STATUS, MEMBER, BYTES/1024/1024 AS SIZE_MB

FROM V$LOG;


Step 2: Determine the Desired Redo Log Size

Consider the workload and requirements of your system to determine an appropriate redo log size. Calculate a size that can accommodate the expected volume of redo generation and provide sufficient space for the redo logs.


Step 3: Determine the Number of Additional Redo Log Groups

Having multiple redo log groups improves performance and availability. Decide on the number of additional groups you want to add based on your specific needs.


Step 4: Choose Locations and Names for Redo Log Files

Identify suitable locations and names for the redo log files. Ensure that the paths have enough space to accommodate the increased redo log sizes.


Step 5: Connect to the Database as a SYSDBA or SYSOPER User

Use an account with SYSDBA or SYSOPER privileges to connect to the Oracle Database.


Step 6: Add New Redo Log Groups

Execute the ALTER DATABASE statement to add new redo log groups. Specify the group number, paths for the redo log files, and desired size for each file. Here's an example:


ALTER DATABASE

ADD LOGFILE GROUP <group_number> ('path_to_redo_log_file_1', 'path_to_redo_log_file_2')

SIZE <redo_log_size> [G|M];


Replace <group_number> with the appropriate group number for the new redo log group. Set the paths for the redo log files using 'path_to_redo_log_file_1' and 'path_to_redo_log_file_2'. Specify the desired size for each file using <redo_log_size>, indicating the size in gigabytes (G) or megabytes (M).


Repeat this ALTER DATABASE statement for each additional redo log group you want to add.


Step 7: Drop Unused Redo Log Groups (If Necessary)

If you have any unused redo log groups, you can drop them using the ALTER DATABASE DROP LOGFILE GROUP statement. Specify the group number of the redo log group you want to drop. Repeat this statement for each unused redo log group you wish to remove.


Step 8: Verify the Redo Log Configuration

After adding the new redo log groups and dropping unused ones, verify the changes by querying the V$LOG view again. Confirm that the new redo log groups have been added and the sizes have been updated accordingly.


Step 9: Perform a Database Backup

To include the changes made to the redo log configuration, perform a backup of your database. This ensures a valid recovery point in case of any issues.


Conclusion:

Increasing the redo log size in Oracle Database can help optimize performance in high-transaction environments. By following the steps outlined in this guide, you can effectively add new redo log groups and adjust their sizes to meet your system's workload requirements. Remember to plan and test any changes carefully and consult with a database administrator or expert familiar with your specific database system to ensure proper configuration and optimization.


8.6.23

ORA-01578 : bloc de données ORACLE corrompu

 "ORA-01578: bloc de données ORACLE corrompu" Ce n'est pas un message d'erreur courant, cela signifie que nous ne le recevons/voyons pas très souvent. La corruption des blocs de données est un problème sérieux et il est crucial de le résoudre rapidement. Effectuez toujours des sauvegardes régulières et assurez-vous de l'intégrité de votre base de données pour minimiser le risque de corruption des données.

"ORA-01578 : Bloc de données ORACLE corrompu" sur INDEX


Si cela se produit sur INDEX, cela signifie que vous avez de la chance :) pour résoudre ce problème, il suffit de supprimer/recréer l'index pour résoudre le problème.




Disons que ce n'est pas INDEX, ce qui est effrayant mais vous avez principalement deux options


Restaurez la sauvegarde pour éviter de perdre des données.

Vous n'avez pas de sauvegarde ou la restauration ne fonctionne pas ou vous voulez simplement extraire autant de données que possible.




  Comme mentionné, "ORA-01578 : bloc de données ORACLE corrompu" n'est pas un problème courant mais très grave qui concerne également votre stockage. Voici les 8 solutions possibles pour "ORA-01578 : bloc de données ORACLE corrompu"


Restore depuis une sauvergarde

Utiliser le conseiller de récupération de données

Exécutez l'utilitaire DBVERIFY

Utiliser l'utilitaire RMAN

Vérifier le disque et le stockage

Vérifier les bogues logiciels

Effectuer une récupération au niveau du bloc

Engager le support Oracle

Restore depuis une sauvergarde


    Si vous disposez d'une sauvegarde valide et récente de la base de données, vous pouvez restaurer le bloc de données corrompu à partir de la sauvegarde. Cela nécessite d'effectuer une récupération ponctuelle ou une restauration complète de la base de données.


Utiliser le conseiller de récupération de données


    Oracle fournit l'outil Data Recovery Advisor (DRA) pour diagnostiquer et réparer les problèmes de corruption des blocs de données. Vous pouvez utiliser le DRA pour analyser la corruption et générer des recommandations de réparation. Suivez les instructions fournies par le DRA pour réparer le bloc de données corrompu.


Exécutez l'utilitaire DBVERIFY


    L'utilitaire DBVERIFY est un outil Oracle intégré utilisé pour vérifier l'intégrité logique et physique des blocs de données. Exécutez DBVERIFY sur les fichiers de données concernés pour identifier les blocs corrompus. Si possible, restaurez les blocs corrompus à partir d'une sauvegarde ou recréez-les à l'aide de la commande RECOVER.


  Utiliser l'utilitaire RMAN


    Si vous utilisez Oracle Recovery Manager (RMAN), vous pouvez utiliser sa fonction de récupération de support de bloc pour réparer les blocs de données corrompus. RMAN peut restaurer les blocs corrompus à partir d'une sauvegarde ou effectuer une récupération de bloc à l'aide de journaux redo en ligne.


Vérifier le disque et le stockage


    Vérifiez que le disque ou le système de stockage sur lequel réside le bloc de données corrompu fonctionne correctement. Vérifiez les pannes matérielles, les erreurs de disque ou les problèmes de stockage qui pourraient avoir causé la corruption. Corrigez tout problème sous-jacent avant de tenter de réparer le bloc de données.


Vérifier les bogues logiciels


    Consultez le site Web de support Oracle, la base de données de bogues ou les forums de la communauté pour vérifier si le problème de corruption est un bogue connu. Des correctifs ou des solutions de contournement spécifiques peuvent être disponibles pour résoudre le problème.


Effectuer une récupération au niveau du bloc


    Dans certains cas, il peut être nécessaire d'effectuer une récupération au niveau du bloc. Cela implique l'utilisation de RMAN pour restaurer et récupérer des blocs de données individuels à partir d'une sauvegarde. Soyez prudent lorsque vous effectuez une récupération au niveau du bloc, car cela peut être complexe et nécessiter des conseils d'experts.


Engager le support Oracle


    Si aucune des solutions ci-dessus ne résout le problème, il est recommandé de contacter le support Oracle pour obtenir de l'aide. Fournissez-leur les détails de l'erreur, les fichiers de trace associés et toute information de diagnostic pertinente pour analyse.


 


Notez que la corruption des blocs de données est un problème sérieux et qu'il est crucial de le résoudre rapidement. Effectuez toujours des sauvegardes régulières et assurez-vous de l'intégrité de votre base de données pour minimiser le risque de corruption des données. Si vous voulez en ajouter, veuillez commenter.




Voici quelques solutions et études réalisées par oracle support.




Bogue 7381632 - ORA-1578 Les blocs corrompus gratuits peuvent ne pas être reformatés lorsque Flashback est activé (Doc ID 7381632.8)

La réinitialisation du contenu échoue avec « java.sql.SQLException : ORA-01578 : bloc de données ORACLE corrompu » (Doc ID 2119387.1)

Échec des collectes de données avec ORA-01578 : Erreur de bloc de données ORACLE corrompu (Doc ID 2752761.1)

ORA-1578 / ORA-26040 Blocs corrompus par NOLOGGING - Explication et solution de l'erreur (Doc ID 794505.1)

Utiliser RMAN pour formater un bloc de données corrompu qui ne fait partie d'aucun objet (Doc ID 1459778.1)

Méthodes ORA-1578 pour ignorer la corruption de blocs (Doc ID 2199133.1)

ORA-01578: ORACLE data block corrupted

 “ORA-01578: ORACLE data block corrupted” This is not a common error message means we don’t receive/see this very often.  Data block corruption is a serious issue, and it is crucial to address it promptly. Always perform regular backups and ensure the integrity of your database to minimize the risk of data corruption.


"ORA-01578: ORACLE data block corrupted" on  INDEX

If it occurs on INDEX that means you are lucky :) to fix this simply dropping/recreating the index will solve the issue.


Let's say it's not INDEX, Which is scary but then you have mainly two options

  1. Restore the backup to avoid losing data.
  2. You don't have a backup or the restore is not working or you just want to extract as much data as possible. 


 As mentioned "ORA-01578: ORACLE data block corrupted" is not common but very serious issue which mostly relates to your storage as well. Here are the possible 8 solutions for "ORA-01578: ORACLE data block corrupted"

  1. Restore from Backup
  2. Use Data Recovery Advisor
  3. Run DBVERIFY Utility
  4. Use RMAN Utility
  5. Check Disk and Storage
  6. Check for Software Bugs
  7. Perform Block-Level Recovery
  8. Engage Oracle Support

Restore from Backup

   If you have a valid and recent backup of the database, you can restore the corrupted data block from the backup. This requires performing a point-in-time recovery or a complete database restore.

Use Data Recovery Advisor

   Oracle provides the Data Recovery Advisor (DRA) tool to diagnose and repair data block corruption issues. You can use the DRA to analyze the corruption and generate repair recommendations. Follow the instructions provided by the DRA to repair the corrupted data block.

Run DBVERIFY Utility

   The DBVERIFY utility is a built-in Oracle tool used to check the logical and physical integrity of data blocks. Run DBVERIFY against the affected data files to identify the corrupt blocks. If possible, restore the corrupted blocks from a backup or recreate them using the RECOVER command.

 Use RMAN Utility

   If you are using Oracle Recovery Manager (RMAN), you can use its block media recovery feature to repair the corrupted data blocks. RMAN can restore the corrupted blocks from a backup or perform block recovery using online redo logs.

Check Disk and Storage

   Verify that the disk or storage system where the corrupted data block resides is functioning correctly. Check for any hardware failures, disk errors, or storage issues that might have caused the corruption. Correct any underlying problems before attempting to repair the data block.

Check for Software Bugs

   Consult the Oracle Support website, bug database, or community forums to check if the corruption issue is a known bug. There might be specific patches or workarounds available to address the problem.

Perform Block-Level Recovery

   In some cases, it might be necessary to perform a block-level recovery. This involves using RMAN to restore and recover individual data blocks from a backup. Exercise caution when performing block-level recovery as it can be complex and may require expert guidance.

Engage Oracle Support

   If none of the above solutions resolve the issue, it is recommended to contact Oracle Support for further assistance. Provide them with the error details, associated trace files, and any relevant diagnostic information for analysis.

 

Note that data block corruption is a serious issue, and it is crucial to address it promptly. Always perform regular backups and ensure the integrity of your database to minimize the risk of data corruption. If you want to add more please comment. 


Here are a few solutions and studies by oracle support.


  • Bug 7381632 - ORA-1578 Free corrupt blocks may not be reformatted when Flashback is enabled (Doc ID 7381632.8)
  • Content Reset fails with "java.sql.SQLException: ORA-01578: ORACLE data block corrupted " (Doc ID 2119387.1)
  • Data Collections failing with ORA-01578: ORACLE data block corrupted error (Doc ID 2752761.1)
  • ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING - Error explanation and solution (Doc ID 794505.1)
  • Use RMAN to format corrupt data block which is not part of any object (Doc ID 1459778.1)
  • ORA-1578 Methods to Skip Block Corruption (Doc ID 2199133.1)


6.6.23

ORA-00942 : La table ou la vue n'existe pas

Une solution simple pour "ORA-00942 : la table ou la vue n'existe pas" consiste à vérifier que le nom de la table ou de la vue est correct et existe dans la base de données. Vérifiez s'il y a des fautes d'orthographe ou des privilèges manquants.


Mais si après avoir vérifié ci-dessus, vous rencontrez toujours l'erreur "ORA-00942 : la table ou la vue n'existe pas". Voici les solutions possibles : -


Vérifier le nom de l'objet

Qualifiez le nom de l'objet

Vérifier les privilèges

Actualiser la vue matérialisée ou les synonymes

Vérifiez le lien de la base de données

Re-compiler les objets invalides

Vérifier la propriété du schéma

Vérifier la corbeille

Vérifier les synonymes

Vérifier l'existence de l'objet

1. Vérifiez le nom de l'objet

Vérifiez que le nom de la table ou de la vue est correct et correspond à la sensibilité à la casse définie dans la base de données. Assurez-vous qu'il n'y a pas d'erreurs typographiques ou de fautes d'orthographe car il s'agit d'une erreur très courante pour "ORA-00942 : la table ou la vue n'existe pas".


2. Qualifiez le nom de l'objet

  Si l'objet se trouve dans un schéma différent, veillez à préfixer le nom de l'objet avec le nom de schéma approprié suivi d'un point (par exemple, SCHEMA_NAME.TABLE_NAME). Ceci est particulièrement important si vous accédez à des tables/vues sur plusieurs schémas et que la plupart des cas sont à l'origine de "ORA-00942 : la table ou la vue n'existe pas".


3. Vérifier les privilèges

Vérifiez que l'utilisateur dispose des privilèges nécessaires pour accéder à la table ou à la vue. L'utilisateur doit avoir au moins le privilège SELECT sur l'objet ou les rôles nécessaires attribués et la plupart des cas sont la raison de "ORA-00942 : la table ou la vue n'existe pas".


4. Actualiser la vue matérialisée ou les synonymes

Si l'erreur est liée à une vue matérialisée ou à un synonyme, essayez d'actualiser la vue matérialisée ou de recréer le synonyme pour vous assurer qu'ils sont à jour et pointent vers l'objet correct et la plupart des cas sont la raison de "ORA-00942 : la table ou la vue ne n'existe pas".


5. Vérifiez le lien de la base de données

  Si l'objet se trouve dans une autre base de données accessible via un lien de base de données, vérifiez que le lien de base de données est correctement défini et fonctionnel. ORA-00942 : La table ou la vue n'existe pas


6. Re-compiler les objets invalides

Si l'erreur se produit après une mise à niveau récente de la base de données ou une modification d'objet, il se peut qu'il y ait des objets non valides dans la base de données. Exécutez la commande suivante en tant qu'utilisateur privilégié pour recompiler tous les objets non valides : ALTER DATABASE COMPILE.


7. Vérifier la propriété du schéma

  Assurez-vous que l'objet appartient au schéma attendu. S'il a été accidentellement supprimé ou si le schéma a été renommé, l'erreur peut se produire. Vérifiez l'existence de l'objet dans le schéma correct.


8. Vérifiez la corbeille

Si la table ou la vue a été supprimée récemment, elle se trouve peut-être dans la corbeille. Vous pouvez essayer de le restaurer à partir de la corbeille à l'aide de la commande FLASHBACK TABLE ou FLASHBACK DROP. ORA-00942 : La table ou la vue n'existe pas


9. Vérifiez les synonymes

Si l'objet est accessible via un synonyme, vérifiez que le synonyme existe et pointe vers l'objet correct. Si nécessaire, supprimez et recréez le synonyme.


10. Vérifier l'existence de l'objet

Si aucune des solutions ci-dessus ne fonctionne, il est possible que l'objet ait été supprimé par erreur. Vérifiez auprès d'autres utilisateurs ou administrateurs de base de données pour confirmer si l'objet existe toujours.


Nous avons essayé de lister toutes les solutions possibles pour "ORA-00942 : la table ou la vue n'existe pas". Si nous avons manqué quelque chose, veuillez commenter.


Si aucune de ces solutions ne résout le problème, il est recommandé de contacter votre support Oracle pour obtenir une assistance supplémentaire, en lui fournissant les détails spécifiques de l'erreur et la configuration de votre base de données.

ORA-00942: 表或视图不存在

“ORA-00942:表或视图不存在”的简单解决方案是验证表或视图名称是否正确且存在于数据库中。 检查是否有任何拼写错误或缺少权限。


但是,如果经过上述检查后您仍然面临错误“ORA-00942:表或视图不存在”。 以下是可能的解决方案:-


检查对象名称

限定对象名称

检查权限

刷新物化视图或同义词

检查数据库链接

重新编译无效对象

验证架构所有权

检查回收站

检查同义词

检查对象是否存在

1.检查对象名称

验证表或视图名称是否正确并匹配数据库中定义的区分大小写。 确保没有印刷错误或拼写错误,因为这是“ORA-00942:表或视图不存在”的常见错误。


2.限定对象名称

  如果对象在不同的架构中,请确保在对象名称前加上适当的架构名称,后跟一个点(例如,SCHEMA_NAME.TABLE_NAME)。 如果您跨多个模式访问表/视图,并且大多数情况是“ORA-00942:表或视图不存在”的原因,这一点尤其重要。


3.查看权限

确认用户具有访问表或视图的必要权限。 用户至少应具有对象的 SELECT 权限或分配的必要角色,大多数情况下是“ORA-00942:表或视图不存在”的原因。


4.刷新物化视图或同义词

如果错误与物化视图或同义词有关,请尝试刷新物化视图或重新创建同义词以确保它们是最新的并指向正确的对象,大多数情况下是“ORA-00942:表或视图不正确”的原因 不存在”。


5.检查数据库链接

  如果对象位于通过数据库链接访问的不同数据库中,请验证数据库链接是否已正确定义和运行。 ORA-00942: 表或视图不存在


6.重新编译无效对象

如果错误发生在最近的数据库升级或对象修改之后,则数据库中可能存在无效对象。 以特权用户身份运行以下命令以重新编译所有无效对象:ALTER DATABASE COMPILE。


7.验证模式所有权

  确保该对象归预期架构所有。 如果它被意外删除或模式已被重命名,则可能会发生错误。 验证对象是否存在于正确的架构中。


8.检查回收站

如果表或视图最近被删除,它可能会出现在回收站中。 您可以尝试使用 FLASHBACK TABLE 或 FLASHBACK DROP 命令从回收站恢复它。 ORA-00942: 表或视图不存在


9.检查同义词

如果通过同义词访问对象,请验证同义词是否存在并指向正确的对象。 如有必要,删除并重新创建同义词。


10.检查对象是否存在

如果上述解决方案均无效,则可能是该对象被错误地丢弃了。 与其他数据库用户或管理员仔细检查以确认该对象是否仍然存在。


我们试图列出“ORA-00942:表或视图不存在”的所有可能解决方案。 如果我们遗漏了什么,请发表评论。


如果这些解决方案都不能解决问题,建议联系您的 Oracle 支持以获得进一步的帮助,向他们提供错误的具体细节和您的数据库配置。 

ORA-00942: Table or view does not exist

 A simple Solution for "ORA-00942: Table or view does not exist" is to  Verify that the table or view name is correct and exists in the database. Check for any spelling errors or missing privileges.

But if after checking above you still face error "ORA-00942: Table or view does not exist". Here are possible solutions:-

  1. Check the object name
  2. Qualify the object name
  3. Check privileges
  4. Refresh materialized view or synonyms
  5. Check the database link
  6. Re-compile invalid objects
  7. Verify schema ownership
  8. Check recycle bin
  9. Check synonyms
  10. Check object existence 

1. Check the object name

Verify that the table or view name is correct and matches the case sensitivity defined in the database. Ensure that there are no typographical errors or misspellings as this is a very common mistake for "ORA-00942: Table or view does not exist".

2. Qualify the object name

 If the object is in a different schema, make sure to prefix the object name with the appropriate schema name followed by a dot (e.g., SCHEMA_NAME.TABLE_NAME). This is especially important if you are accessing tables/views across multiple schemas and most cases are the reason for "ORA-00942: Table or view does not exist".

3. Check privileges

Confirm that the user has the necessary privileges to access the table or view. The user should have at least the SELECT privilege on the object or the necessary roles assigned and most cases are the reason for "ORA-00942: Table or view does not exist".

4. Refresh materialized view or synonyms

If the error is related to a materialized view or synonym, try refreshing the materialized view or recreating the synonym to ensure they are up to date and pointing to the correct object and most cases are the reason for "ORA-00942: Table or view does not exist".

5. Check the database link

 If the object is located in a different database accessed through a database link, verify that the database link is properly defined and functional. ORA-00942: Table or view does not exist

6. Re-compile invalid objects 

If the error occurs after a recent database upgrade or object modification, there may be invalid objects in the database. Run the following command as a privileged user to recompile all invalid objects: ALTER DATABASE COMPILE.

7.  Verify schema ownership

 Ensure that the object is owned by the expected schema. If it has been accidentally dropped or the schema has been renamed, the error may occur. Verify the object's existence in the correct schema.

8. Check recycle bin

If the table or view has been dropped recently, it might be present in the recycle bin. You can try restoring it from the recycle bin using the FLASHBACK TABLE or FLASHBACK DROP command. ORA-00942: Table or view does not exist

9. Check synonyms 

If the object is accessed through a synonym, verify that the synonym exists and points to the correct object. If necessary, drop and recreate the synonym.

10. Check object existence 

If none of the above solutions work, it's possible that the object has been mistakenly dropped. Double-check with other database users or administrators to confirm if the object still exists.

We tried to list all possible solutions for "ORA-00942: Table or view does not exist". If we missed anything, Please comment.

If none of these solutions resolve the issue, it's recommended to contact your Oracle Support for further assistance, providing them with the specific details of the error and your database configuration.

7.3.23

how to select nextval from sequence?

How to select the next value from the sequence?

select xxxx.nextval from dual;

where XXXX is your sequence name. 

NEXTVAL is a function used in oracle to get the next value of the sequence.

No current value exists for the sequence until the Oracle NEXVAL function has been called at least once. 


A sequence is a database object, Which helps in generating a unique value(integer). 

One sequence can serve multiple users to generate a unique value.

Sequences can be used to generate primary key values automatically as well.


Check This

2.3.23

Which two actions would reduce the job's elapsed time?

Which two actions would reduce the job's elapsed time?

 A. Increasing the priority of the job class to which the job belongs
B. Increasing the job's relative priority within the Job class to which it belongs
C. Increasing the resource allocation for the consumer group mapped to the scheduler job's job class
within the plan mapped to the scheduler window
D. Moving the job to an existing higher-priority scheduler window with the same schedule and duration
E. Increasing the value of the JOB_QUEUE_PROCESSES parameter
F. Increasing the priority of the scheduler window to which the job belongs


Correct Answer: BC


Explanation: B: Job priorities are used only to prioritize among jobs in the same class.
Note: Group jobs for prioritization
Within the same job class, you can assign priority values of 1-5 to individual jobs so that if two jobs in the
class are scheduled to start at the same time, the one with the higher priority takes precedence. This
ensures that you do not have a less important job preventing the timely completion of a more important one.
C: Set resource allocation for member jobs
Job classes provide the link between the Database Resource Manager and the Scheduler, because each
job class can specify a resource consumer group as an attribute. Member jobs then belong to the specified
consumer group and are assigned resources according to settings in the current resource plan.


16.1.22

How many sessions are allowed on the Oracle database?

 How many sessions are allowed on the Oracle database?


The theoretical real number of maximum sessions depends on the horsepower of your server.

You determine the runtime maximum number of sessions with the SESSIONS parameter, which derives the PROCESSES parameter.


SQL> show parameter sessions


To see the existing maximum number of sessions, try this query:


select current_utilization, limit_value from gv$resource_limit where resource_name='sessions';




Try this to show info about both:

    select resource_name, current_utilization, max_utilization, limit_value 
    from v$resource_limit 
    where resource_name in ('sessions', 'processes');



1.1.22

ORA-00240 control file enqueue held for more than XXX seconds


ORA-00240 control file enqueue held for more than XXX seconds


Description: control file enqueue held for more than string seconds

Cause 1:-

 The current process did not release the control file enqueue within the maximum allowed time.

Cause 2:-

 This issue was  investigated in unpublished Bug  by oracle 7570453 - [3 RAC NODE] ORA-00240          WHEN STARTUP AFTER UPGRADE TO 10.2.0.4.0 which was closed as Not a Bug. The                    Developers confirmed that this is just a warning to let the DBA know that a CF enqueue is being held for more than 120 seconds.

This is not an error, and error will occur if a CF enqueue is held for more than 900 seconds (15 minutes) and this is not the case here. 

The message occurs when there are many datafiles in the database and  DBWriter  is taking too much time to release the CF enqueue due to having to open these  datafiles.

Action: 1. Reissue any commands that failed and contact Oracle Support Services with the incident information.

   2.  The recommendation will be to reduce this time by reducing the number of database files you have. It is more recommended having less but bigger datafiles  instead of smaller but lots of datafiles.

We aware to check alert log for sure. 

  how to Take care of Oracle Audit 


  What are Oracle 10days rule??



Bug 20639511  ORA-00240: CONTROL FILE ENQUEUE HELD FOR MORE THAN 120 SECONDS


Description

RELEASE NOTES:
 
 The bug is know to cause issues while deleting large number of files from ASM dectory
 
Rediscovery Notes
 
 Server Process of asmcmd rm command with -rf option holds enqueues for long time.
 
Workaround
 
  Kill the ongoing asmcmd rm command with -rf option and delete files one by one


Flex: ORA-00240: Control File Enqueue Held for More Than 120 Seconds (Doc ID 2434297.1)


Cause - This is due to Bug 25445289 (FLEX: ORA-00240: CONTROL FILE ENQUEUE HELD FOR MORE THAN 120 SECONDS) and the bug 25445289 is closed as duplicate of Bug 25368979 
(FLEX: ASM STALLS IN ALTER DISKGROUP ALL MOUNT, ONLY 1 OF 3 COMPLETE IN 30 MIN)


Solution:- Bug 25368979 fixed in 18.1. Apply interim patch 25368979, if available for your platform and Oracle version.
If no patch exists for your version, please contact Oracle Support for a backport request. 

Source:- Oracle

Below by ChatGPT

The error message "ORA-00240 control file enqueue held for more than XXX seconds" in Oracle indicates that a process is waiting for a control file enqueue lock for an extended period of time. This can occur due to various reasons, such as high system load, contention, or issues with the control file itself. Here are some possible solutions to address this error:

  1. Check system load: Monitor the system load and resource usage. If the system is heavily loaded, you may need to reduce the workload or allocate more resources to alleviate the contention.

  2. Investigate contention: Identify if there are any other processes or transactions that might be causing contention for the control file enqueue lock. You can use Oracle's dynamic performance views, such as V$SESSION and V$LOCK, to identify the blocking sessions and take appropriate actions to resolve the contention.

  3. Verify control file accessibility: Ensure that the control file is accessible and not corrupted. Check the file permissions, disk space, and integrity of the control file. If necessary, restore a backup of the control file or recreate it.

  4. Increase resources: If the system consistently experiences high contention for the control file enqueue, consider increasing the number of control files in the Oracle database configuration. Having multiple control files can help distribute the load and reduce contention.

  5. Optimize database performance: Review the database performance and identify any potential bottlenecks or resource-intensive operations. Optimizing queries, tuning database parameters, and implementing appropriate indexing strategies can help improve overall performance and reduce contention.

  6. Restart the database: In some cases, restarting the database can help resolve temporary contention issues. However, ensure that all necessary precautions are taken, such as ensuring a clean shutdown and performing a thorough analysis of the underlying cause before resorting to a restart.

  7. Seek expert assistance: If the issue persists or you are unsure about the appropriate actions to take, consider involving a database administrator or Oracle support for further analysis and resolution.

It's important to note that the specific solution may vary depending on the underlying cause of the contention. Analyzing the system logs, and performance metrics, and consulting with experienced Oracle professionals can help in identifying and resolving the issue effectively. 


14.9.21

How to Design a Good Oracle RAC Set-up on a QA Server for Developers?

How to Design a Good Oracle RAC Set-up on a QA Server for Developers?


Please help on this. Please suggest how to do achieve this in low cost?


5.8.21

What is Oracle RAC and 5 Key Points to remember about Oracle RAC

What is Oracle RAC

Oracle RAC stands for Real Application clusters which is a high availability solution from Oracle. It is one of the best solutions till now in all database technologies from Oracle. Oracle RAC using shared everything architecture. In Oracle RAC, All nodes(instances) access the same data and perform read/write operations. Basically, Oracle RAC achieves zero downtime. If one Node(instance)  in Oracle RAC got crashed in Oracle RAC it will switch transactions to another Node(instance). The main beauty of Oracle RAC is you can add and remove nodes(instance) on your needs so you can scale up/down. Oracle RAC works with clustering which has advantages and gives you to avoid a single point of failure. 

More on Oracle RAC

source:- oracle


5 Key Points to remember for Oracle RAC:- 

1. Oracle RAC, achieve better performance and high availability as compare to other present solution in the market.

2. Oracle RAC, scale up/down feature helps to control the cost. You can easily add and remove nodes from RAC environment In a high load situation you can add one or more nodes and when no load can delete the node. This management is very easy. 

3. Oracle RAC, Works well with data consistency as all nodes updates data separately and users still see real-time data.

4. Oracle RAC, Easy to manage to patch as all node(instance) is independent on resources. 

5. Oracle RAC, When one node(instance) got crashed all connection moves to the next available node(instance). Please note that only select statements move. 
 

Let us know your thoughts in the comment section. Keep sharing :)

WARNING:COULD NOT LOWER THE ASYNCH I/O LIMIT TO 160 FOR SQL DIRECT I/O

WARNING: COULD NOT LOWER THE ASYNCH I/O LIMIT TO 160 FOR SQL DIRECT I/O


We faced this error in our 10.2.0.2 client-side database server trace logs. Users were not able to access the application and even they could not start the related services on the application server. 


When we checked the DB server we found that there was no space left on ORACLE_HOME.  Further checking leads us to huge trace files generated and we talking about 20GB. So for a temporary fix, we deleted few largest trace files and some old trace files, as well as the most important thing, is to maintain the state of the application up and running. After this application was back on track. 

 A little history:-  

This server was restored from the crash and localit247.com missed to implement the log purging for this new DB server. So we needed to the RCA. 

Below is information shared with the application Team:- 

Faced Issue: Users were not able to access the application and cannot start the related services.
Root Cause: No space left for drive causing the server to halt. Oracle tracing logs under DB_INSTANCE > udump folder were the culprit of storage consumption.
Temporary fix: Deleted few largest files. 

We checked for "WARNING:COULD NOT LOWER THE ASYNCH I/O LIMIT TO 160 FOR SQL DIRECT I/O" and found that it's because of the bug. The best way to check that is on the oracle support website. We keep checking on another famous site like uatdb.com 
and few good blogs for "WARNING:COULD NOT LOWER THE ASYNCH I/O LIMIT TO 160 FOR SQL DIRECT I/O". 

There are two solutions provided by oracle on the support website for this bug:- 

1. Upgrade to 11.2.0.2 or higher                                          
2. Apply 10.2.0.5.2 PSU where the fix for Bug 9772888  has been included. 

You need to open a service request with oracle on oracle support if not able to find any patch as per your platform or you may implement temporary by creating a batch script to delete all *.trc files older than 15-30days under UDUMP folder for 10G database. 

In our case, we are already in the progress to move the database to Oracle 19C. So we choose to implement a batch script to delete the trace file. 

Hope this helps you in handling “WARNING:COULD NOT LOWER THE ASYNCH I/O LIMIT TO 160 FOR SQL DIRECT I/O”.  Keep sharing.. 

21.7.21

How to Stop and Disable Firewall on CentOS 8

How to Stop and Disable Firewall on CentOS 8

Most of the time this task is done by system admins but if you work in a small organization like me(God helps you) :) then you need to do many system admin tasks by yourself.


I am writing this blog because recently faced issue similar issue when we moved one of the 19C databases to Azure cloud. After setting up the database application team was not able to reach the database. I did some checking and found that the Linux admin missed disabling the firewall on the DB server. So I decided to stop the firewall on DB server by myself.  


Sharing steps with you all, so may help you on "How to Stop and to Disable Firewall on CentOS 8"


There may be many methods but I used firewall-cmd to stop the firewall.


Man Page DESCRIPTION for firewall-cmd

NAME

       firewall-cmd - firewalld command line client

SYNOPSIS
       firewall-cmd [OPTIONS...]

DESCRIPTION

       firewall-cmd is the command-line client of the firewall daemon. It provides an interface to manage the runtime and permanent configurations.

       The runtime configuration in firewalld is separated from the permanent configuration. This means that things can
       get changed in the runtime or permanent configuration


Note: You need the root user or any user to have SUDO to do this change.

Steps to top and Disable Firewall on CentOS 8:- 

1. Check the Status of the firewall using Firewalld

[root@TEST-D01 ~]# firewall-cmd --state
                                     running
   
2.  Stop firewall using Firewalld

[root@TEST-D01 ~]# systemctl stop firewalld

3. Check the Status of firewall using Firewalld

[root@TEST-D01 ~]# firewall-cmd --state
not running

Keep Sharing :)


13.7.21

How to Change the Timezone in Linux

How to Change the Timezone in Linux

Easy steps to change timezone on "CentOS Stream release 8"

It's very simple to change the timezone of Linux machines. Sometimes as DBA you need to change the timezone on cloud environments when you handling multiple sites on the cloud.

Just follow the below steps to "Change the Timezone in Linux" :-

1) login with root or any sudo user to your machine and check current timezone. 
   [root@TEST-D01 ~]# timedatectl
                                       Local time: Tue 2021-07-13 03:40:06 EEST
                                       Universal time: Tue 2021-07-13 00:40:06 UTC
                                         RTC time: Tue 2021-07-13 00:40:06
                                        Time zone: Europe/Kiev (EEST, +0300)
                                     System clock synchronized: no
                                      NTP service: n/a
                              RTC in local TZ: no

My Current timezone is "Europe/Kiev (EEST, +0300)". 

So Let's change the timezone to Asia. 

2) You can get the list of all timezones in Asia by "timedatectl list-timezones |grep Asia" 
                    [root@TEST-D01 ~]# timedatectl list-timezones |grep Asia
                        Asia/Aden
                        Asia/Almaty
                        Asia/Amman
                        Asia/Anadyr
                        Asia/Aqtau
                        Asia/Aqtobe
                        Asia/Ashgabat
                        Asia/Atyrau
                        Asia/Baghdad
                        Asia/Bahrain
                        Asia/Baku
                        Asia/Bangkok
                        Asia/Barnaul
                        Asia/Beirut
                        Asia/Bishkek
                        Asia/Brunei
                        Asia/Chita
                        Asia/Choibalsan
                        Asia/Colombo
                        Asia/Damascus
                        Asia/Dhaka
                        Asia/Dili
                        Asia/Dubai
                        Asia/Dushanbe
                        Asia/Famagusta
                        Asia/Gaza
                        Asia/Hebron
                        Asia/Ho_Chi_Minh
                        Asia/Hong_Kong
                        Asia/Hovd
                        Asia/Irkutsk
                        Asia/Jakarta
                        Asia/Jayapura
                        Asia/Jerusalem
                        Asia/Kabul
                        Asia/Kamchatka
                        Asia/Karachi
                        Asia/Kathmandu
                        Asia/Khandyga
                        Asia/Kolkata
                        Asia/Krasnoyarsk
                        Asia/Kuala_Lumpur
                        Asia/Kuching
                        Asia/Kuwait
                        Asia/Macau
                        Asia/Magadan
                        Asia/Makassar
                        Asia/Manila
                        Asia/Muscat
                        Asia/Nicosia
                        Asia/Novokuznetsk
                        Asia/Novosibirsk
                        Asia/Omsk
                        Asia/Oral
                        Asia/Phnom_Penh
                        Asia/Pontianak
                        Asia/Pyongyang
                        Asia/Qatar
                        Asia/Qostanay
                        Asia/Qyzylorda
                        Asia/Riyadh
                        Asia/Sakhalin
                        Asia/Samarkand
                        Asia/Seoul
                        Asia/Shanghai
                        Asia/Singapore
                        Asia/Srednekolymsk
                        Asia/Taipei
                        Asia/Tashkent
                        Asia/Tbilisi
                        Asia/Tehran
                        Asia/Thimphu
                        Asia/Tokyo
                        Asia/Tomsk
                        Asia/Ulaanbaatar
                        Asia/Urumqi
                        Asia/Ust-Nera
                        Asia/Vientiane
                        Asia/Vladivostok
                        Asia/Yakutsk
                        Asia/Yangon
                        Asia/Yekaterinburg
                        Asia/Yerevan

Now We have the list of all timezones in Asia. Let's set it e.g. to Asia/Qatar.

3. To change the timezone from Europe/Kiev to Asia/Qatar. just run 

[root@TEST-D01 ~]# timedatectl set-timezone Asia/Qatar
[root@TEST-D01 ~]# timedatectl
               Local time: Tue 2021-07-13 04:02:48 +03
           Universal time: Tue 2021-07-13 01:02:48 UTC
                 RTC time: Tue 2021-07-13 01:02:49
                Time zone: Asia/Qatar (+03, +0300)
System clock synchronized: no
              NTP service: n/a
          RTC in local TZ: no

30.11.20

ORA-00907: missing right parenthesis ! while creating view

ORA-00907: missing right parenthesis 

"ORA-00907: missing right parenthesis" can happen if you really missing it in your SQL, But if that is the case you will not search on google.com :).

One of Our oracle SQL developers reported that while creating a view on one of the oracle database were facing "ORA-00907: missing right parenthesis". We started troubleshooting and found that it's a bug from the oracle in 12.2 databases.  The solution is just to apply the patch or change the view of the code. 


CREATE OR REPLACE FORCE VIEW "TEST_V" ("TEST_COL1", "TEST_COL2") AS

SELECT

  -----

FROM TEST_T A WHERE TEST_COL1 IS NOT NULL

GROUP BY

  -----

  REGEXP_REPLACE(LISTAGG(TEST_COL1,';' ON OVERFLOW TRUNCATE) WITHIN GROUP (ORDER BY TEST_COL1),'([^;]+)(;\1)*(;|$)', '\1\3') AS TEST,

                                        *

ERROR at line 12:

ORA-00907: missing right parenthesis 


This view we were able to create in 12.1 but not in 12.2  so we in the last asked developers to change the view. That is how we handle "ORA-00907: missing right parenthesis" issue.  If you are facing the same issue and are not able to find any clue, just try to create it on the older version. The actual information regarding the bug is not available yet but we update soon we will find it. 

Oracle Means company, not database :) Keep sharing...

26.11.20

Oracle Fail Safe Compatibility with 19c

 Is oracle fail Safe is not compatible with the windows 2019?

The answer is yes. 

Below is the compatibility Matrix.:- 


Note that version 4.1.0 is already on extended support. 

Also, check "Oracle Fail Safe is deprecated with Oracle Database 19c".


Oracle Mean company, not database :)

2.11.20

ORA-65114: space usage in container is too high

I was creating tablespace in a newly created PDB and  was facing  " ORA-65114: space usage in the container is too high "

ORA-65114: space usage in the container is too high 

So it happens when you created PDB with a storage option less than you need. Below is the example, I used to create PDB:

create pluggable database TEST admin user admin identified by "oracle" default tablespace USERS

 datafile '/u02/oradata/TEST/pdb1_users01.dbf' size 250m autoextend on

 storage (maxsize 1g max_shared_temp_size 1g)

 file_name_convert=('/u02/oradata/TEST/datafile/','/u02/oradata/TEST/TEST');


Want to know drawback of oracle ?  check this


This mean oracle will not go beyond 1G. As I used MAX to 1G and below is the error. 

Below is the error:- 

SQL> CREATE TABLESPACE "TEST" LOGGING DATAFILE '/u02/oradata/TEST.DBF' SIZE 750M AUTOEXTEND ON NEXT 8M MAXSIZE 2048M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

CREATE TABLESPACE "TEST" LOGGING DATAFILE '/u02/oradata/TEST.DBF' SIZE 750M AUTOEXTEND ON NEXT 8M MAXSIZE 2048M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

*

ERROR at line 1:

ORA-65114: space usage in container is too high 


Solution:-  

Just increase the storage limit of the pluggable database. Run the following SQL in the current PDB to limit the size of all datafiles of that PDB:

 SQL> ALTER PLUGGABLE DATABASE STORAGE UNLIMITED;

Pluggable database altered.

OR if you want a limited SIZE, You can still define the size. 

SQL> alter pluggable database storage (MAXSIZE 120G);



Note:- If not defined storage option by default of  MAX_PDB_STORAGE is no limit.


How to check the max size of PLUGGABLE DATABASE STORAGE?


To check value in current PDB, Conenct to PDB and run below :

select PROPERTY_VALUE FROM database_properties WHERE property_name = 'MAX_PDB_STORAGE';



To check value in current CDB for all PDB'S, Conenct to CDB and run below :

select PROPERTY_NAME,PROPERTY_VALUE,DESCRIPTION,CON_ID FROM cdb_properties WHERE property_name = 'MAX_PDB_STORAGE';


Oracle Mean company, not database :)

If it helps. Please comment and let us know :)