Oracle et Microsoft ont élargi leur partenariat pour fournir des services de base de données Oracle exécutés sur Oracle Cloud Infrastructure (OCI), colocalisés dans les data centers Microsoft. Les clients d'Azure peuvent désormais acheter, déployer et utiliser des services de base de données Oracle exécutés sur OCI au sein du portail natif et des API d'Azure, avec une expérience de type OCI dans Azure. Quelques-uns des principaux avantages d'Oracle Database@Azure sont présentés ci-dessous.
Oracle Exadata Database Service, Oracle Autonomous AI Database Serverless, Oracle Base Database Service, Oracle GoldenGate, et Oracle Database Zero Data Loss Autonomous Recovery Service sont actuellement disponibles. Nous annoncerons les ajouts à cet ensemble au fur et à mesure qu'ils seront disponibles.
Reportez-vous au document des descriptions de service (PDF) pour en savoir plus.
La migration vers cette offre est identique à la migration vers OCI étant donné que le service de base de données s'exécute sur OCI. Oracle fournit des stratégies éprouvées de migration de base de données, notamment des solutions de migration automatisée telles qu'Oracle Zero Downtime Migration et de puissants outils tels qu'Oracle Data Guard et Oracle Cloud Infrastructure GoldenGate..
Pour connaître la disponibilité régionale et la feuille de route, reportez-vous à la section relative aux régions Oracle Database@Azure. Nous encourageons les clients à partager leurs exigences relatives à d'autres régions avec leur équipe de compte Oracle ou Microsoft.
Oui, pour les services de conseil. Notez qu'Oracle Database@Azure est vendu directement aux clients via Azure Marketplace et n'est pas disponible à l'achat via une autre société ou un autre canal.
Si vous souhaitez devenir partenaire de services de conseil Oracle et bénéficier d'une désignation d'expertise en services, vous pouvez trouver les dernières informations sur le site Web Oracle PartnerNetwork. Les fournisseurs de services peuvent acheter l'offre directement, mais pas pour le compte des clients.
Oracle Exadata Database Service on Dedicated Infrastructure prend désormais en charge la plateforme Exadata X11M de nouvelle génération.
Le provisionnement d'Oracle AI Database sur Oracle Database@Azure est le même que sur OCI. Il utilise le même flux d'interface utilisateur, les mêmes appels d'API, etc. Par conséquent, toute version de base de données actuellement prise en charge et disponible sur OCI est visible et disponible sur l'infrastructure Oracle Database@Azure.
Étant donné que la base de données est provisionnée et gérée dans OCI, les outils de base de données existants, tels que les sauvegardes et le clonage, seront disponibles.
Oracle Database Autonomous Recovery Service est la solution de sauvegarde recommandée pour les bases de données. Elle s'appuiera sur le MACC d'un client lorsque la sauvegarde sera activée. Les clients peuvent choisir de déployer Oracle Database Autonomous Recovery Service dans une région Azure ou OCI. Oracle Cloud Infrastructure Object Storage est également une autre option de sauvegarde.
Oracle Database@Azure est un déploiement standard, disponible dans Azure VNet. Les outils de gestion Oracle AI Database, tels que Data Pump, peuvent être utilisés pour importer des données dans la base de données à partir de clients de base de données Azure.
La passerelle de routage dynamique (DRG) utilisée pour fournir le lien entre les ressources réseau OCI et Azure est hébergée dans un réseau cloud virtuel de service (VCN) étroitement contrôlé et ne peut pas être mise à jour. Une fois provisionnées, les ressources de cluster de machines virtuelles Exadata sont rattachées à cette DRG. Si vous avez des exigences spécifiques en matière de routage, vous pouvez utiliser des groupes d'appairage locaux pour vous connecter à un autre VCN. Ce VCN appairé localement peut ensuite être attaché à un DRG que vous contrôlez. Cette passerelle de routage dynamique peut être utilisée pour la réplication inter-région (reportez-vous à la question sur la réplication de données pour la reprise après sinistre).
Oracle Database@Azure est axé sur les workloads hautes performances et à faible latence exécutées dans Azure. Si le workload nécessitant une faible latence se trouve dans OCI, nous vous recommandons de déployer Oracle Exadata Database Service on Dedicated Infrastructure dans OCI. Si disponible, nous recommandons d'utiliser Oracle Interconnect for Microsoft Azure pour connecter le service OCI et Oracle Database@Azure en vue de répondre aux besoins de faible latence.
Comme la base de données est créée via OCI, Oracle Cloud Infrastructure Vault est utilisé pour héberger la clé générée par le système ou par le client.
Oui, Oracle Database@Azure prend en charge les déploiements dédiés et partagés. Oracle Exadata Database Service on Dedicated Infrastructure exécuté dans Azure fournit des nœuds de calcul et de stockage Exadata dédiés aux clients, tout comme sur OCI.
Oracle Exadata Database Service sur l'infrastructure Exascale fournit un modèle de service d'infrastructure partagée dans lequel Oracle gère l'ensemble de l'infrastructure physique, éliminant ainsi la nécessité de provisionner des serveurs de base de données et de stockage dédiés. Les bases de données client s'exécutent sur une infrastructure partagée avec des machines virtuelles Exadata Exascale dédiées avec un stockage privé. Les clients conservent le contrôle sur les machines virtuelles de base de données.
Oracle Autonomous AI Database Serverless s'exécute sur une infrastructure Exadata partagée. Avec Autonomous AI Database Serverless, vous n'avez pas besoin de configurer ni d'installer de matériel ni d'installer de logiciel de base de données. Il gère le provisionnement des bases de données, les sauvegardes, l'application de correctifs, les mises à niveau et le redimensionnement des bases de données.
Oui, Oracle Database@Azure prend en charge les environnements à locataire unique et multi-locataires. Oracle Exadata Database Service on Dedicated Infrastructure exécuté dans Azure fournit aux clients des nœuds de calcul et de stockage Exadata dédiés, de la même manière qu'avec une exécution sur OCI.
Non, Oracle Database@Azure n'est pas disponible dans les environnements hautement autorisés FedRAMP.
Oracle Interconnect for Microsoft Azure prend désormais en charge Oracle US Government Cloud. Oracle a récemment annoncé la disponibilité générale des régions Oracle US Gov West (Phoenix) et Azure US Gov Arizona (Phoenix) pour Oracle Interconnect for Microsoft Azure. Les clients communs peuvent utiliser Oracle Interconnect for Microsoft Azure pour migrer facilement leurs workloads vers les environnements Oracle Cloud Infrastructure et Azure FedRAMP High autorisés.
La conformité est une responsabilité partagée entre Oracle et Microsoft. Oracle Database@Azure a été certifié pour les certifications de conformité en vigueur. Pour obtenir des informations détaillées sur les certifications de conformité, consultez les informations de conformité Oracle Database@Azure.
Nous proposons un guide complet pour le déploiement de bases de données Oracle sur la plateforme (Java) de SAP NetWeaver Application Server à l'aide d'Oracle Database@Azure, basé sur Oracle Exadata Cloud Infrastructure X9M avec Oracle Linux 8 sur les nœuds de cluster de machines virtuelles. Bien que la certification SAP officielle soit requise pour les déploiements, vous pouvez facilement demander cette certification à la demande. En attendant, vous pouvez utiliser le guide de déploiement fourni. Si votre organisation souhaite déployer SAP sur Oracle Database@Azure, contactez Oracle Sales pour compléter la demande de certification SAP.
Oracle Exadata Database Service on Dedicated Infrastructure et Oracle Exadata Database Service on Exascale Infrastructure sont tous deux disponibles à l'achat via une offre privée sur le marché Azure, sur devis personnalisé. Tout d'abord, vous travaillez avec Oracle Sales pour négocier les conditions commerciales, qui sont formalisées dans un bon de commande qui est partagé avec vous, et que vous pouvez consulter et accepter. Ensuite, Oracle crée une offre privée et la télécharge sur Azure Marketplace. Vous devez acheter l'offre privée sur Azure Marketplace pour provisionner le service.
Oracle Exadata Database Service sur l'infrastructure Exascale est également disponible sous forme d'offre de paiement à l'utilisation, offrant aux entreprises de toute taille un point d'entrée à faible coût pour exploiter la puissance d'Exadata dans leurs workloads.
Oracle Autonomous AI Database est disponible sous forme d'offre de paiement à l'utilisation, offrant aux développeurs la possibilité de déployer une base de données entièrement gérée en quelques minutes directement à partir d'Azure Marketplace. Le service est également disponible à l'achat via une offre privée sur Azure Marketplace. Pour connaître la tarification, vous devez demander un devis personnalisé. Pour effectuer un achat, contactez votre représentant commercial Oracle. Nos collaborateurs établiront un contrat, proposeront une tarification personnalisée et créeront une offre Azure privée sur Azure Marketplace. Vous devez acheter l'offre privée sur Azure Marketplace pour provisionner le service.
Oracle Base Database Service est disponible à l'achat via une offre privée sur Azure Marketplace, avec une tarification basée sur un devis personnalisé. En outre, une option de paiement à l'utilisation est disponible. Les entreprises de toutes tailles bénéficient ainsi d'un point d'entrée abordable et flexible pour tirer parti de la puissance d'Exadata pour leurs workloads.
Avec les services Oracle sur Oracle Database@Azure, vous pouvez utiliser vos licences Oracle AI Database existantes, y compris les contrats de licence illimités et Oracle Bring Your Own License (BYOL), acheter des licences supplémentaires ou utiliser la consommation Licence incluse.
Oui. Vous pouvez utiliser des licences Oracle AI Database existantes, y compris des contrats de licence illimités (ULA) et Oracle Bring Your Own License (BYOL).
Oui. Les locations peuvent être nouvelles ou existantes. Vous aurez le choix au cours du processus d'intégration. Comme le service Oracle Database@Azure est physiquement présent dans Azure, les environnements Oracle Exadata Database Service on Dedicated Infrastructure existants ne sont pas "déplacés", physiquement ou commercialement. Les nouvelles infrastructures Exadata créées dans Azure seront visibles dans la location OCI existante.
Non. Les clients avec paiement à l'utilisation doivent créer un compte OCI pour Oracle Database@Azure. La liaison à une location existante est disponible uniquement via une offre privée. Pour en savoir plus, visitez le site Lier un compte OCI existant à Oracle Database@Azure.
Oui. L'utilisation d'Oracle Database@Azure permet d'obtenir les mêmes Oracle Support Rewards qu'en utilisant directement OCI.
Oui. Vous pouvez utiliser votre engagement de consommation Microsoft Azure (MACC) pour Oracle Database@Azure. Pour plus d'informations, reportez-vous à Suivi de votre engagement de consommation Microsoft Azure.
Pour chaque instance Exadata Cloud Infrastructure que vous provisionnez, 48 heures de consommation vous sont facturées, puis la facturation est calculée à la seconde après cela. Chaque OCPU que vous provisionnez pour exécution sur l'infrastructure est facturée par la seconde, avec une période d'utilisation minimale d'une minute. Si vous arrêtez le cluster de machines virtuelles Cloud mais ne mettez pas fin à la ressource d'infrastructure Exadata cloud, la facturation se poursuit pour la ressource d'infrastructure.
Pour chaque ressource d'infrastructure Oracle Exadata Database Service on Exascale que vous provisionnez, vous êtes facturé pour l'infrastructure de machine virtuelle et de stockage pendant au moins 48 heures, puis la seconde après. Vous pouvez augmenter la quantité de machines virtuelles et d'infrastructure de stockage disponibles à tout moment. Chaque ECPU que vous provisionnez pour exécution sur le système est facturée à la seconde, avec une période d'utilisation minimale d'une minute.
L'utilisation d'Autonomous AI Database Serverless est facturée en fonction des valeurs de deux paramètres : le calcul et le stockage. Vous sélectionnez des valeurs pour ces paramètres lorsque vous provisionnez ou redimensionnez une instance Autonomous AI Database. Pour plus de détails, reportez-vous à Récapitulatif de la facturation Autonomous AI Database.
La consommation Oracle est mise en correspondance à 1:1 avec votre engagement de consommation Microsoft Azure (MACC).
L'utilisation d'Oracle Base Database Service est facturée en fonction du nombre d'heures d'ECPU consommées et du nombre total de gigaoctets de stockage de volume de blocs consommés.
Le minimum pratique pour acheter Exadata Database Service on Dedicated Infrastructure est le suivant :
La plus petite configuration pour Oracle Exadata Database Service sur l'infrastructure Exascale sur Oracle Database@Azure est deux machines virtuelles avec un total de 16 ECPU, 560 Go de stockage de machine virtuelle et 300 Go de stockage de base de données Exascale partagé.
La configuration la plus petite pour Autonomous AI Database Serverless dépend de la configuration de service que vous utilisez. Pour Oracle Autonomous AI Transaction Processing, il s'agit de deux ECPU avec 20 Go de stockage, et pour Oracle Autonomous AI Lakehouse, de deux ECPU avec 1 To de stockage.
Le minimum pour acheter Oracle Base Database Service sur Oracle Database@Azure est de quatre ECPU et 256 Go de stockage.
Oracle GoldenGate est facturé en fonction du calcul et du stockage que vous provisionnez, sans durée minimale. Vous ne payez que ce que vous utilisez.
Exadata Database Service on Dedicated Infrastructure (X11M) et Exadata Database Service on Exascale Infrastructure disposent d'une période de service minimale de 48 heures. La consommation d'ECPU et d'OCPU peut être réduite à zéro pour arrêter la facturation. Les services Autonomous AI Database (Autonomous AI Database Serverless et Base Database Service) n'ont pas de période de service minimale.
Actuellement, il n'y a pas d'option Free Tier.
Tout trafic OCI inter-région qui engendre normalement des coûts de bande passante réseau sera décompté du MACC du client (par exemple, un client effectuant une reprise après sinistre inter-région utilisant Oracle Database@Azure dans la région un et la région deux devrait s'acquitter de coûts de trafic réseau).
Aucuns frais d'entrée/de sortie supplémentaires ne s'appliquent aux mouvements de données entre OCI et Azure via Multicloud Link dans la même région.
Les applications Oracle suivantes sont désormais prises en charge sur Azure lorsqu'elles sont exécutées sur Oracle Database@Azure :
Pour plus d'informations, reportez-vous aux stratégies d'assistance suivantes :
Oracle et Microsoft ont développé un modèle de support commun pour assurer une réponse et une résolution rapides pour les workloads stratégiques. Les clients créeront toutes les demandes d'assistance technique directement auprès d'Oracle. Oracle contactera le support technique Microsoft si nécessaire.
Oracle et Microsoft se sont associés pour vous offrir une expérience Azure bien intégrée du déploiement, de la gestion et de l'utilisation d'instances Oracle AI Database dans Azure. Pour la plupart des opérations quotidiennes, vous pourrez utiliser les outils Azure natifs.
Oracle Database@Azure sera disponible dans plusieurs zones au sein d'une région Azure et plusieurs régions Azure au sein d'une zone géographique. Les clients peuvent utiliser Oracle Data Guard pour déployer des solutions de reprise après sinistre. Reportez-vous à l'architecture de référence pour déployer une solution de reprise après sinistre à l'aide de Data Guard dans des zones de disponibilité au sein d'une région conforme à la norme Gold d'Oracle Maximum Availability Architecture (MAA). Pour en savoir plus, reportez-vous à Oracle Maximum Availability Architecture for Oracle Database@Azure.
Oracle Database@Azure sera disponible dans plusieurs zones de disponibilité au sein d'une région Azure pour répondre aux exigences de haute disponibilité (HA) et de reprise après sinistre.
Non. Oracle détient le lien, la gestion et le trafic circulant entre le data center Azure et le data center OCI parent. Les réseaux de gestion Azure et OCI ne se croisent pas. Azure ne dispose d'aucune visibilité au-delà du point de terminaison de l'équipement de transfert du partenaire au sein du data center où Oracle se connecte. Et inversement, Oracle ne peut pas voir au-delà de ce même point. La liaison réseau est traitée comme interne à Oracle.
Operator Access Control est disponible pour les clusters de machines virtuelles Oracle Compute Cloud@Customer, Exadata Cloud@Customer et Autonomous Exadata sur les machines virtuelles client déployées sur Oracle Autonomous AI Database on Exadata Cloud@Customer.
La gestion d'Oracle Database@Azure est identique à celle d'Oracle Exadata Database Service sur OCI. Par conséquent, Operator Access Control n'est pas applicable.
Les ressources Oracle Database@Azure provisionnées et gérées via le fournisseur de ressources Oracle AI Database dans Azure peuvent être exploitées et gérées à partir de la console, de l'API, du SDK ou de l'interface de ligne de commande Azure.
L'extension des ressources et des fonctionnalités gérées par le fournisseur de ressources Oracle est à l'étude.
L'infrastructure Oracle Database@Azure est identique à celle d'OCI. Par conséquent, les outils standard de dimensionnement d'Exadata et d'Oracle Database, tels qu'Oracle Cloud Capacity Analytics, peuvent être utilisés.
Le matériel Oracle Database@Azure est déployé dans la zone de disponibilité de la région Azure équivalente au domaine de disponibilité dans OCI. Pour les régions Azure et OCI comportant plusieurs zones et domaines de disponibilité, le matériel Oracle Database@Azure sera déployé dans des zones avec une correspondance de 1:1 vers le domaine de disponibilité OCI.
Le réseau entre le déploiement Oracle Database@Azure dans Azure et son site OCI parent est une fibre noire dédiée, redondante et gérée en interne par Oracle, semblable à l'infrastructure réseau AD-AD OCI. La connexion entre le matériel Oracle Database@Azure sur site et Azure est établie via une connectivité locale par l'intermédiaire d'un matériel réseau redondant direct vers l'infrastructure réseau Azure.
Chaque déploiement Oracle Database@Azure est connecté à un site OCI parent. Ce lien est utilisé pour :
Le réseau entre le parent OCI et l'infrastructure Oracle Database@Azure est considéré comme un réseau régional interne. Par conséquent aucun coût n'est facturé pour le trafic et il n'y a aucune limitation ou ralentissement. La capacité éventuelle et les autres limites imposées au réseau virtuel Azure sont toujours en vigueur (par exemple, la bande passante entre le sous-réseau délégué et Azure Private Link est limitée à 50 Gb/s, ce qui affecte les services tels que l'accès à Azure Blob Storage).
Non, Oracle Interconnect for Azure est un service Oracle autonome que les clients peuvent utiliser lors du déploiement de services cloud Oracle et Azure nécessitant une interconnectivité. Oracle Database@Azure n'utilise pas cette liaison réseau.
L'interconnexion OCI-Azure et Oracle Database@Azure tirent parti de la proximité entre les clouds. Par conséquent, il peut y avoir un chevauchement important dans les futurs déploiements de région.
Si vous souhaitez utiliser d'autres services OCI avec des services Azure, Oracle Interconnect for Azure devra être configuré.
Tout le trafic entre les sites, y compris l'infrastructure Oracle Database@Azure, est chiffré.
Les fichiers de journalisation Oracle Data Guard sont expédiés de la base de données principale vers la base de données de secours via le sous-réseau client par les réseaux gérés par le client sur l'infrastructure OCI.
* Entraîne des coûts de transfert de données sortantes.
Les déploiements Exadata existants restent opérationnels. Toutefois, les clients ne peuvent pas créer, mettre à jour ou supprimer des ressources. Les processus ou procédure reposant sur des services basés sur OCI (par exemple, recherche de clé OCI Vault, sauvegardes de base de données, etc.) échouent.
Les mesures et les ressources de journalisation envoyées d'OCI à Azure Monitor sont retardées, même si le déploiement Exadata est fonctionnel.
Il faut s'attendre à ce que toutes les fonctionnalités du plan de contrôle ne soient plus disponibles.