一次vm虚拟机时间倒流而导致的oracle数据库启动故障
一次vm 虚拟机时间倒流而导致的oracle 数据库启动故障 本文是原创文章，若转载请注明出处： http://blog.csdn.net/msdnchina/article/details/38782163 直接上数据库的alert日志： Fri Apr 25 22:00:54 2014 -----注意该时间Archived Log entry 1766 added f
一次vm 虚拟机时间倒流而导致的oracle 数据库启动故障
本文是原创文章，若转载请注明出处：
http://blog.csdn.net/msdnchina/article/details/38782163
直接上数据库的alert日志：
Fri Apr 25 22:00:54 2014 <-----注意该时间
Archived Log entry 1766 added for thread 1 sequence 1770 ID 0x4e0785c3 dest 1:
Sun Sep 02 23:04:52 2012 <-----注意该时间
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 32 KB
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB
RECOMMENDATION:
Total System Global Area size is 4226 MB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 2113 (page size 2048 KB, total size 4226 MB) system wide to
get 100% of the System Global Area allocated with large pages
2. Large pages are automatically locked into physical memory.
Increase the per process memlock (soft) limit to at least 4234 MB to lock
100% System Global Area's large pages into physical memory
********************************************************************
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 4
CELL communication is configured to use 0 interface(s):
CELL IP affinity details:
NUMA status: non-NUMA system
cellaffinity.ora status: N/A
CELL communication will use 1 IP group(s):
Grp 0:
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =51
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /opt/oracle/product/11g/dbname_1
System name: Linux
Node name: oracle
Release: 2.6.18-371.el5
Version: #1 SMP Thu Sep 5 21:21:44 EDT 2013
Machine: x86_64
VM name: VMWare Version: 6
Using parameter settings in server-side spfile /opt/oracle/product/11g/dbname_1/dbs/spfileorcl.ora
System parameters with non-default values:
processes = 300
sessions = 472
nls_language = "SIMPLIFIED CHINESE"
nls_territory = "CHINA"
sga_target = 4224M
control_files = "/oracledata/orcl/control01.ctl"
control_files = "/opt/oracle/fast_recovery_area/orcl/control02.ctl"
control_files = "/oracledata/orcl/control03.ctl"
control_files = "/oracledata/orcl/control04.ctl"
control_files = "/oracledata/orcl/control05.ctl"
db_block_size = 8192
compatible = "11.2.0.4.0"
log_archive_format = "%t_%s_%r.dbf"
db_files = 2000
db_recovery_file_dest = "/opt/oracle/fast_recovery_area"
db_recovery_file_dest_size= 40G
undo_tablespace = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain = ""
dispatchers = "(PROTOCOL=TCP) (SERVICE=orclXDB)"
audit_file_dest = "/opt/oracle/admin/orcl/adump"
audit_trail = "DB"
db_name = "orcl"
open_cursors = 300
pga_aggregate_target = 1403M
deferred_segment_creation= FALSE
diagnostic_dest = "/opt/oracle"
Sun Sep 02 23:04:53 2012
PMON started with pid=2, OS id=4452
Sun Sep 02 23:04:53 2012
PSP0 started with pid=3, OS id=4454
Sun Sep 02 23:04:54 2012
VKTM started with pid=4, OS id=4456 at elevated priority
Sun Sep 02 23:04:54 2012
GEN0 started with pid=5, OS id=4460
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Sun Sep 02 23:04:54 2012
DIAG started with pid=6, OS id=4462
Sun Sep 02 23:04:54 2012
DBRM started with pid=7, OS id=4464
Sun Sep 02 23:04:54 2012
DIA0 started with pid=8, OS id=4466
Sun Sep 02 23:04:54 2012
MMAN started with pid=9, OS id=4468
Sun Sep 02 23:04:54 2012
DBW0 started with pid=10, OS id=4470
Sun Sep 02 23:04:54 2012
LGWR started with pid=11, OS id=4472
Sun Sep 02 23:04:54 2012
CKPT started with pid=12, OS id=4474
Sun Sep 02 23:04:54 2012
SMON started with pid=13, OS id=4476
Sun Sep 02 23:04:54 2012
RECO started with pid=14, OS id=4478
Sun Sep 02 23:04:55 2012
MMON started with pid=15, OS id=4480
Sun Sep 02 23:04:55 2012
MMNL started with pid=16, OS id=4482
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /opt/oracle
Sun Sep 02 23:04:55 2012
ALTER DATABASE MOUNT
Successful mount of redo thread 1, with mount id 1320728727
Database mounted in Exclusive Mode
Lost write protection disabled
Completed: ALTER DATABASE MOUNT
Sun Sep 02 23:04:59 2012
ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Started redo scan
Completed redo scan
read 69 KB redo, 66 data blocks need recovery
Started redo application at
Thread 1: logseq 1771, block 16853
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1771 Reading mem 0
Mem# 0: /oracledata/orcl/redo01.log
Completed redo application of 0.04MB
Completed crash recovery at
Thread 1: logseq 1771, block 16992, scn 13030631482598
66 data blocks read, 66 data blocks written, 69 redo k-bytes read
************************************************************
Warning: The SCN headroom for this database is only -652 hours!
************************************************************
Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4492.trc (incident=43353):
ORA-00600: internal error code, arguments: [kcm_headroom_warn_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /opt/oracle/diag/rdbms/orcl/orcl/incident/incdir_43353/orcl_ora_4492_i43353.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_4492.trc:
ORA-00600: internal error code, arguments: [kcm_headroom_warn_1], [], [], [], [], [], [], [], [], [], [], []
ORA-600 signalled during: ALTER DATABASE OPEN...
Dumping diagnostic data in directory=[cdmp_20120902230501], requested by (instance=1, osid=4492), summary=[incident=43353].
Sun Sep 02 23:05:58 2012
Sweep [inc][43353]: completed
Sweep [inc2][43353]: completed
Sun Sep 02 23:19:58 2012
db_recovery_file_dest_size of 40960 MB is 29.05% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Sun Sep 02 23:38:25 2012
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
1359
52
Combien de temps les journaux de la base de données Oracle seront-ils conservés ?
May 10, 2024 am 03:27 AM
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.
De quelle quantité de mémoire Oracle a-t-il besoin ?
May 10, 2024 am 04:12 AM
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.
Exigences de configuration matérielle du serveur de base de données Oracle
May 10, 2024 am 04:00 AM
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.
Quelle quantité de mémoire est nécessaire pour utiliser la base de données Oracle
May 10, 2024 am 03:42 AM
La quantité de mémoire requise pour une base de données Oracle dépend de la taille de la base de données, du type de charge de travail et du nombre d'utilisateurs simultanés. Recommandations générales : petites bases de données : 16 à 32 Go, bases de données moyennes : 32 à 64 Go, grandes bases de données : 64 Go ou plus. D'autres facteurs à prendre en compte incluent la version de la base de données, les options d'optimisation de la mémoire, la virtualisation et les meilleures pratiques (surveiller l'utilisation de la mémoire, ajuster les allocations).
Les tâches planifiées Oracle exécutent l'étape de création une fois par jour
May 10, 2024 am 03:03 AM
Pour créer une tâche planifiée dans Oracle qui s'exécute une fois par jour, vous devez effectuer les trois étapes suivantes : Créer une tâche. Ajoutez un sous-travail au travail et définissez son expression de planification sur "INTERVAL 1 DAY". Activez le travail.
iOS 18 ajoute une nouvelle fonction d'album 'Récupéré' pour récupérer les photos perdues ou endommagées
Jul 18, 2024 am 05:48 AM
Les dernières versions d'Apple des systèmes iOS18, iPadOS18 et macOS Sequoia ont ajouté une fonctionnalité importante à l'application Photos, conçue pour aider les utilisateurs à récupérer facilement des photos et des vidéos perdues ou endommagées pour diverses raisons. La nouvelle fonctionnalité introduit un album appelé "Récupéré" dans la section Outils de l'application Photos qui apparaîtra automatiquement lorsqu'un utilisateur a des photos ou des vidéos sur son appareil qui ne font pas partie de sa photothèque. L'émergence de l'album « Récupéré » offre une solution aux photos et vidéos perdues en raison d'une corruption de la base de données, d'une application d'appareil photo qui n'enregistre pas correctement dans la photothèque ou d'une application tierce gérant la photothèque. Les utilisateurs n'ont besoin que de quelques étapes simples
Tutoriel détaillé sur l'établissement d'une connexion à une base de données à l'aide de MySQLi en PHP
Jun 04, 2024 pm 01:42 PM
Comment utiliser MySQLi pour établir une connexion à une base de données en PHP : Inclure l'extension MySQLi (require_once) Créer une fonction de connexion (functionconnect_to_db) Appeler la fonction de connexion ($conn=connect_to_db()) Exécuter une requête ($result=$conn->query()) Fermer connexion ( $conn->close())
Comment gérer les erreurs de connexion à la base de données en PHP
Jun 05, 2024 pm 02:16 PM
Pour gérer les erreurs de connexion à la base de données en PHP, vous pouvez utiliser les étapes suivantes : Utilisez mysqli_connect_errno() pour obtenir le code d'erreur. Utilisez mysqli_connect_error() pour obtenir le message d'erreur. En capturant et en enregistrant ces messages d'erreur, les problèmes de connexion à la base de données peuvent être facilement identifiés et résolus, garantissant ainsi le bon fonctionnement de votre application.
