Oracle 双机/RAC/Dataguard的区别
Data Guard 是Oracle的远程复制技术,它有物理和逻辑之分,但是总的来说,它需要在异地有一套独立的系统,这是两套硬件配置可以不
Data Guard 是Oracle的远程复制技术,它有物理和逻辑之分,但是总的来说,它需要在异地有一套独立的系统,这是两套硬件配置可以不同的系统,但是这两套系统的软件结构保持一致,包括软件的版本,目录存储结构,以及数据的同步(其实也不是实时同步的),这两套系统之间只要网络是通的就可以了,是一种异地容灾的解决方案。而对于RAC,则是本地的高可用集群,每个节点用来分担不用或相同的应用,以解决运算效率低下,单节点故障这样的问题,它是几台硬件相同或不相同的服务器,加一个SAN(共享的存储区域)来构成的。
Data Guard由两个多两个以上的独立的数据库构成,他们各自有各自的存储,Oracle负责他们之间的切换和数据同步
双机热备由两台计算机和一个共享存储设备构成,通过第三方软件(HA Rose等)实现切换,,不需要做数据同步
建议应用RAC+Dataguard ,RAC保证可用性,Dataguard在RAC组独立磁盘上和另外一台主机上,保证可靠性。
双机就是人们所说的双机热备,数据库放在共享设备上,同一时刻只能有一台主机接管,另一台待用,这种方式只能保护实例,不能保护db,而且备机长期处于闲置,对资源是一种极大的浪费!
如果原本是双机,建议转换为RAC
规划好应用,DML操作从一个节点跑,查询操作从另一个节点跑,通常不需要太多调优就可以利用闲置的另外一台机器了
RAC服务器共用一套存储,同时提供服务,没有主备之分.宕一个其它的可以继续服务.
双机热备,共用一套存储,一个提供服务一个备份,主机宕了切换到备份服务器提供服务.
data guard 完全两套系统,存储是单独的,用日志同步.
RAC: 实例层冗余
DG :数据库层冗余
热备:仅仅只是数据冗余
个人理解:
RAC :实例冗余,而且还可以做到数据库的loadbalance。
DG :多份数据,所以能做到数据冗余,但是只有主节点提供服务。
热备:与RAC最大的差异可能就是RAC有多个实例,一个数据库。而热备只是一个实例,一个数据库。所以做不了并发和loadbalance。
Oracle RAC只是做Oracle的应用,rose,legato还可以做其它的
HA:是High Availability 的首字母组合,翻译过来,可以叫做高可用,或高可用性,高可用(环境)。我觉得应该说HA是一个观念而不是一项或一系列具体技术,就象网格一样。作过系统方案就知道了,评价系统的性能当中就有一项高可用。广义的高可用涉及到系统的各个方面,简单来说,让系统不会中断 运行,就是高可用。包括软件的高可用,硬件的高可用,网络的高可用等等。具体实现的方案包括操作系统的集群,数据库的集群,硬件的冗余,网络的冗余等等。做HA方面的软件,有IBM的HACMP(很多常用AIX的人,常说的HA就指HACMP,乱啊)、SUN的Sun Cluster、HP的MC/SG等。
在2000年以前,大家谈HA,大部分时候说的是操作系统一级的双机热备,主流产品当时有IBM HACMP4.1,HP的MC/SG啥版本忘了,sun的系统很多人不用VCS,用的是一个叫dataware的东西。现在很多人眼中的HA也还是这样。时至今日,HA包括的东西可就多了,先不说其他方面,单就数据库,单就Oracle,与HA相关的产品先后有:高级复制(AdvanceRepication)、OPS/RAC(Real Application Cluster)、数据卫士(Data Guard)、oracle流(Oracle Streams)、分区(Oracle Partition)这样数款产品。照这么说,RAC只是HA这个概念下的一个具体产品而已!目前为止,只有RAC和分区是Oracle要收取licence的,其他的,只要给经验丰富的第三方实施方付一定的规划/设计及部署费用就可以了;当然,也可以自己照着文档依葫芦画瓢,但是这样弄出的环境是否能达到高可用就难说了。事实上,大部分人所说的HA,还是狭义上的HA,也就是OS一级的双机热备。
RAC:是real application cluster的简称,它是在多个主机上运行一个数据库的技术,即是一个db多个instance。它的好处是 可以由多个性能较差的机器构建出一个整体性能很好的集群,并且实现了负载均衡,那么当一个节点出现故障时,其上的服务会自动转到另外的节点去执行,用户甚 至感觉不到什么。

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)

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 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.

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

Oracle peut lire les fichiers dbf en suivant les étapes suivantes : créer une table externe et référencer le fichier dbf ; interroger la table externe pour récupérer les données dans la table Oracle ;

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

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.

Les besoins en mémoire d'Oracle Database dépendent des facteurs suivants : taille de la base de données, nombre d'utilisateurs actifs, requêtes simultanées, fonctionnalités activées et configuration matérielle du système. Les étapes permettant de déterminer les besoins en mémoire incluent la détermination de la taille de la base de données, l'estimation du nombre d'utilisateurs actifs, la compréhension des requêtes simultanées, la prise en compte des fonctionnalités activées et l'examen de la configuration matérielle du système.
