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 :)