oracle 重要的等待事件
buffer busy waits等待事件 orcale的等待事件列表可以从v$event_name中查看完整的等待事件列表 buffer busy waits Wait occurs when a session attempts to access a block in memory, is denied and must wait until the buffer becomes available. This ev
buffer busy waits等待事件
orcale的等待事件列表可以从v$event_name中查看完整的等待事件列表
buffer busy waits
Wait occurs when a session attempts to access a block in memory, is denied and must wait until the buffer becomes available. This event happens because a buffer is either being read into the buffer cache by another session (and the session is waiting for that read to complete) or the buffer is in the buffer cache, but in a incompatible mode (that is, some other session is changing the buffer).
--当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时。
--当一个会话视图修改一个数据块,但这个数据块正在被另一个会话修改时。
Solutions
Buffer busy waits often occur in the following cases:
- Inefficient SQL statements read more blocks than necessary. If there are many sessions running these statements, they will attempt to read the same blocks and possibly wait on this event.
- If the FREELISTS parameter for a table is too low, multiple sessions that are attempting to insert rows in the same table and end up waiting for freelists. This problem shows up as contention for the segment header of the table.
- Multiple sessions are attempting to change an index block (possibly do to an insert).
- The INITRANS parameters is too low for a segment. Any DML operation that needs to go into the block needs to lock an Interested Transaction List (ITL). If INITRANS parameter is set too low, then there will be less number of ITLs allocated originally. Oracle can only allocate more ITLs if there is space in PCTFREE area of the block. If, however, there is no space to increase the ITL, the transactions that cannot lock ITLs will have to wait until the previous transactions have completed operations on the block. The waiter will register ‘buffer busy wait’ for the block.
find the table or indexes waited for. Once the database object is known, consider the following causes of contention and their solutions.
Waits on Data blocks
Data blocks are the blocks that actually hold the row data in a table or index.
Problem: Multiple sessions are requesting a block that is either not in cache or in an incompatible mode.
Solution 1: Tune inefficient queries. Inefficient queries read too many blocks into the buffer cache. These queries could flush out blocks that may be useful for other sessions in the buffer cache. By tuning queries, the number of blocks that need to be read into the cache is reduced, reducing aging out of the existing “good” blocks in the cache.
Solution 2: Delete some of the hot rows and insert them back into the table. Most of the time, the rows will be place in a different block. The DBA may need to adjust pctfree and/or pctused to ensure the rows are placed into a different block.
Solution 3: Cache the table or keep the table in the KEEP POOL. When multiple sessions are requesting the blocks that reside in the disk, it takes too much time for a session to read it into the buffer cache. Other session(s) that need the same block will register ‘buffer busy wait’. If the block is already in buffer cache, however, this possibility is eliminated. Another alternative is to increase the buffer cache size. A larger buffer cache means less I/O from disk. This reduces situations where one session is reading a block from the disk subsystem and other sessions are waiting for the block.
Solution 4: Look for ways to reduce the number of low cardinality indexes. A low cardinality index is an index on a column(s) with a relatively low number of unique values such as a U. S. state column that has only fifty unique values. Low cardinality indexes could result in excessive block reads. Concurrent DML operations on low cardinality columns could also cause contention on a few index blocks.
Waits on Segment Header blocks
Each segment has one segment header block.
Problem: At times, this block can be a point of contention which manifests itself as a buffer busy wait. This occurs especially when multiple sessions are attempting to insert into or delete from the same table.
Solution 1: When sessions insert rows into a block, the block must be taken out of the freelist if the PCTFREE threshold reached. When sessions delete rows from a block, the block will be put back in the freelist if PCTUSED threshold is reached. If there are a lot of blocks coming out of the freelist or going into it, all those sessions have to make that update in the freelist map in the segment header. This can cause contention for the segment header block which manifests itself as ‘buffer busy wait’. One solution to this problem is to create multiple freelists. This will allow different insert streams to use different freelists and thus update different freelist maps. This reduces contention on the segment header block. You should also look into optimizing the PCTUSED/PCTFREE parameters so that the blocks don’t go in and out of the freelists frequently.
Solution 2: Increase the size of the extents. If extents are too small, Oracle must constantly allocate new extents causing contention in the extent map
Solution 3: Increase the undocumented database parameter, _bump_highwater_mark_count, from the default of 5. Updating the high water mark on the table can become a bottleneck.
Expanded Definition
Wait until a buffer becomes available. This event happens because a buffer is either being read into the buffer cache by another session (and the session is waiting for that read to complete) or the buffer is in the buffer cache, but in a incompatible mode (that is, some other session is changing the buffer).

Outils d'IA chauds

Undresser.AI Undress
Application basée sur l'IA pour créer des photos de nu réalistes

AI Clothes Remover
Outil d'IA en ligne pour supprimer les vêtements des photos.

Undress AI Tool
Images de déshabillage gratuites

Clothoff.io
Dissolvant de vêtements AI

AI Hentai Generator
Générez AI Hentai gratuitement.

Article chaud

Outils chauds

Bloc-notes++7.3.1
Éditeur de code facile à utiliser et gratuit

SublimeText3 version chinoise
Version chinoise, très simple à utiliser

Envoyer Studio 13.0.1
Puissant environnement de développement intégré PHP

Dreamweaver CS6
Outils de développement Web visuel

SublimeText3 version Mac
Logiciel d'édition de code au niveau de Dieu (SublimeText3)

Sujets chauds

La durée de conservation des journaux de la base de données Oracle dépend du type de journal et de la configuration, notamment : Redo logs : déterminé par la taille maximale configurée avec le paramètre "LOG_ARCHIVE_DEST". Redo logs archivés : Déterminé par la taille maximale configurée par le paramètre "DB_RECOVERY_FILE_DEST_SIZE". Redo logs en ligne : non archivés, perdus au redémarrage de la base de données et la durée de conservation est cohérente avec la durée d'exécution de l'instance. Journal d'audit : Configuré par le paramètre "AUDIT_TRAIL", conservé 30 jours par défaut.

La fonction dans Oracle pour calculer le nombre de jours entre deux dates est DATEDIFF(). L'utilisation spécifique est la suivante : Spécifiez l'unité d'intervalle de temps : intervalle (tel que jour, mois, année) Spécifiez deux valeurs de date : date1 et date2DATEDIFF(interval, date1, date2) Renvoie la différence en jours

La séquence de démarrage de la base de données Oracle est la suivante : 1. Vérifiez les conditions préalables ; 2. Démarrez l'écouteur ; 3. Démarrez l'instance de base de données ; 4. Attendez que la base de données s'ouvre ; 6. Vérifiez l'état de la base de données ; . Activez le service (si nécessaire) ; 8. Testez la connexion.

Le type de données INTERVAL dans Oracle est utilisé pour représenter les intervalles de temps. La syntaxe est INTERVAL <precision> <unit> Vous pouvez utiliser des opérations d'addition, de soustraction, de multiplication et de division pour utiliser INTERVAL, ce qui convient aux scénarios tels que le stockage de données temporelles et. calculer les différences de dates.

La quantité de mémoire requise par Oracle dépend de la taille de la base de données, du niveau d'activité et du niveau de performances requis : pour le stockage des tampons de données, des tampons d'index, l'exécution d'instructions SQL et la gestion du cache du dictionnaire de données. Le montant exact dépend de la taille de la base de données, du niveau d'activité et du niveau de performances requis. Les meilleures pratiques incluent la définition de la taille SGA appropriée, le dimensionnement des composants SGA, l'utilisation d'AMM et la surveillance de l'utilisation de la mémoire.

Pour trouver le nombre d'occurrences d'un caractère dans Oracle, effectuez les étapes suivantes : Obtenez la longueur totale d'une chaîne ; Obtenez la longueur de la sous-chaîne dans laquelle un caractère apparaît. Comptez le nombre d'occurrences d'un caractère en soustrayant la longueur de la sous-chaîne ; de la longueur totale.

Exigences de configuration matérielle du serveur de base de données Oracle : Processeur : multicœur, avec une fréquence principale d'au moins 2,5 GHz Pour les grandes bases de données, 32 cœurs ou plus sont recommandés. Mémoire : au moins 8 Go pour les petites bases de données, 16 à 64 Go pour les tailles moyennes, jusqu'à 512 Go ou plus pour les grandes bases de données ou les charges de travail lourdes. Stockage : disques SSD ou NVMe, matrices RAID pour la redondance et les performances. Réseau : réseau haut débit (10GbE ou supérieur), carte réseau dédiée, réseau à faible latence. Autres : alimentation stable, composants redondants, système d'exploitation et logiciels compatibles, dissipation thermique et système de refroidissement.

La méthode de remplacement de chaînes dans Oracle consiste à utiliser la fonction REPLACE La syntaxe de cette fonction est : REPLACE(string, search_string, replace_string). Étapes d'utilisation : 1. Identifiez la sous-chaîne à remplacer ; 2. Déterminez la nouvelle chaîne pour remplacer la sous-chaîne ; 3. Utilisez la fonction REPLACE pour remplacer. L'utilisation avancée inclut : les remplacements multiples, le respect de la casse, le remplacement des caractères spéciaux, etc.
