Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Alors pour ceux qui ont des doutes sur les performances de SQL sur des grosses tables, un exemple sur une base où je passais par hasard ce matin. Je n'ai changé que les noms de table/schema

    La table fait 3.5 Tera, contient 400 millions de lignes:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
    SQL> select num_rows,blocks from dba_tables where owner='XXX' and table_name='OP';
     
     
      NUM_ROWS     BLOCKS
    ---------- ----------
     398327400  236418039
     
     
    Elapsed: 00:00:00.01
     
     
    SQL> select blocks,bytes/1024/1024/1024/1024 TB from dba_segments where owner='XXX' and segment_name='OP';
     
     
        BLOCKS         TB
    ---------- ----------
     238309992  3.5510956
    Un requête courante fait un accès par index comme celui-ci:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
     
    SQL> select sum(length(data_segment)) from "XXX"."OP" where DECODE("REFERENCE",'0',"ENTITY","REFERENCE") between '000931151470664' and '000931181978026';
     
     
    SUM(LENGTH(DATA_SEGMENT))
    -------------------------
    8854698
     
     
    Elapsed: 00:00:04.03
    Donc 4 secondes. Et voici le plan d'exécution avec les statistiques d'exécution:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
     
    SQL> select * from table(dbms_xplan.display_cursor(format=>'allstats last'));
     
     
    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------------------------------------------------------------------
    SQL_ID  cg9fkkb28t3xs, child number 0
    -------------------------------------
    select sum(length(data_segment)) from "XXX"."OP" where
    DECODE("REFERENCE",'0',"ENTITY","REFERENCE") between '000931151470664'
    and '000931181978026'
     
     
    Plan hash value: 2490914298
     
     
    -------------------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                     | Name                       | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
    -------------------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT              |                            |      1 |        |      1 |00:00:04.02 |     610 |    608 |
    |   1 |  RESULT CACHE                 | 4zy76myzu25zg9f8v75dy3awb0 |      1 |        |      1 |00:00:04.02 |     610 |    608 |
    |   2 |   SORT AGGREGATE              |                            |      1 |      1 |      1 |00:00:04.01 |     610 |    608 |
    |   3 |    TABLE ACCESS BY INDEX ROWID| OP                         |      1 |      6 |    604 |00:00:04.01 |     610 |    608 |
    |*  4 |     INDEX RANGE SCAN          | AK1_OP                     |      1 |      6 |    604 |00:00:00.01 |       6 |      4 |
    -------------------------------------------------------------------------------------------------------------------------------
    C'est bien un accès à la table, par index. Seulement quelques pages lues (quelques pages d'index puis une page par ligne). Toutes lues sur disque ici. L'index B-Tree a une hauteur de 3 branches ici. Avec 300 milliard de lignes, il aurait peut-être une hauteur de 4 ou 5 -> juste une ou de page de plus à lire -> impact négligeable sur le temps d'exécution.

    Et encore, on n'est pas en parallel query ici, il n'y a aucun partitionnement, aucune compression. On pourrait aller beaucoup plus loin. Et on est dans le cas le pire: rien encache (autant de 'Reads' que de Buffers') et lignes dispersées dans des blocs différents (Buffers=A-rows). C'est une appli qui a plus de 15 ans, utilisée tous les jours et qui tourne sans aucune administration à part rajouter des datafiles, sur un vieux serveur!

    Cordialement,
    Franck.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  2. #22
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    18 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 18 321
    Points : 42 824
    Points
    42 824

    Par défaut

    Pour continuer dans le sens de Franck Pachot, mais sur du SQL Server, différents extraits d'un audit réalisé sur un ensemble de très grosses bases (plusieurs dizaines de To) :

    Procédure ...Exploitation.dbo.Set_Titre_Diffusion_Pour_...

    ... cette procédure doit être optimisée pour accélérer encore le traitement global du rapprochement.
    En effet, elle est appelée de façon itérative par la procédure de rapprochement. Malheureusement, dans le temps imparti, je ne suis pas allé très loin car la création d'index sur la table ScamExImport.dbo.H_SEQUENCE_DIFFUSION_OEUVRE_LINK a pris plus d'une heure : cette table contient près de 200 millions de lignes, un peu dur à traiter pour mon PC.

    En créant les deux index suivants, on obtient un bon gain, en passant de plus de 60 secondes et des millions d'IO à 700 millisecondes.
    ...

    En récrivant un peu l'expression du premier SELECT de cette procédure, comme suit :
    ...

    nous sommes alors à 40 ms.


    Dans cette partie de l'audit nous sommes avec des tables de plusieurs centaines de million de lignes...

    Bref 200 millions de lignes, 700 ms...

    Autre extrait du même rapport d'audit :

    ... on voit clairement dans le plan d'exécution réel (en pièce jointe) un écart d'estimation de cardinalités énorme sur la table #TMP_LISTE_TITRES:
    - un premier estimé à 3 555 lignes, en réalité 42 333 128 sur 12 836 boucles
    - un deuxième qui amplifie le premier écart, avec toujours 3555 lignes estimées vs. 3 146 806 488 en 954 156 boucles

    En effet l'exécution des jointures par boucles imbriquées pour 3555 lignes aurait été efficace.
    Mais cet algorithme ne l'est plus lorsque le nombre de lignes à traiter devient plus élevé.

    L'écart d'estimation est du à l'expression du filtre de la première CTE, nommée TMP_LISTE_TITRES_CTE :

    AND NOT ( @b_est_radio = 1 AND TLT.D_DATE_HEURE_DIFFUSEUR >= '01/01/2009' )

    Nous avons tenté une première reformulation en écrivant :

    AND (@b_est_radio = 0 OR TLT.D_DATE_HEURE_DIFFUSEUR < '2009101')
    AND (@b_est_radio <> 1 OR TLT.D_DATE_HEURE_DIFFUSEUR < '01/01/2009')


    Mais comme bien souvent, le OR pose problème. Un remède habituel est d’exploser le OR en UNION, ce qui nous donne :


    SELECT d_date_heure_diffuseur, fk_sequence_diffusion, f_Id_Rnd_File, id_titre_repartiteur, fk_Oeuvre_Repartiteur, fk_Oeuvre_Diffuseur
    FROM #TMP_LISTE_TITRES TLT
    WHERE TLT.F_ID_RND_FILE = 29549
    AND @b_est_radio = 0
    UNION
    SELECT d_date_heure_diffuseur, fk_sequence_diffusion, f_Id_Rnd_File, id_titre_repartiteur, fk_Oeuvre_Repartiteur, fk_Oeuvre_Diffuseur
    FROM #TMP_LISTE_TITRES TLT
    WHERE TLT.F_ID_RND_FILE = 29549
    AND TLT.D_DATE_HEURE_DIFFUSEUR < '20090101'

    On passe alors de l'empreinte suivante :

    Table 'Liste_SDOD'. Scan count 0, logical reads 27739, physical reads 18, read-ahead reads 70
    Table 'D_OEUVRE'. Scan count 0, logical reads 26805
    Table 'Worktable'. Scan count 3, logical reads 13918, physical reads 0, read-ahead reads 5190
    Table 'Workfile'. Scan count 0, logical reads 0
    Table 'R_DIFFUSEUR'. Scan count 1, logical reads 4
    Table 'D_SEQUENCE_DIFFUSION'. Scan count 0, logical reads 6739106, physical reads 49, read-ahead reads 24
    Table '#TMP_LISTE_TITRES__000000000029'. Scan count 966994, logical reads 23207856
    (3298 row(s) affected)
    SQL Server parse and compile time : CPU time = 408500 ms, elapsed time = 413230 ms.

    A celle-ci :

    Table 'Liste_SDOD'. Scan count 0, logical reads 26599
    Table 'D_OEUVRE'. Scan count 0, logical reads 26805
    Table 'Worktable'. Scan count 3, logical reads 13918
    Table 'Workfile'. Scan count 0, logical reads 0
    Table 'R_DIFFUSEUR'. Scan count 1, logical reads 4
    Table 'D_SEQUENCE_DIFFUSION'. Scan count 0, logical reads 81639
    Table '#TMP_LISTE_TITRES__000000000029'. Scan count 8, logical reads 192

    SQL Server parse and compile time : CPU time = 203 ms, elapsed time = 687 ms.


    Notez juste le nombre de ligne : 3 146 806 488
    Vous avez bien lu... 3 milliards 146 millions de ligne dans une table... temps de traitement 687 ms...

    Bref lorsqu'un développeur me parle de NoSQL comme étant beaucoup plus rapide, je me marre !!!

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #23
    Membre habitué
    Homme Profil pro
    Ergonome
    Inscrit en
    octobre 2016
    Messages
    63
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ergonome
    Secteur : Arts - Culture

    Informations forums :
    Inscription : octobre 2016
    Messages : 63
    Points : 127
    Points
    127

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    Pour continuer dans le sens de Franck Pachot, mais sur du SQL Server, différents extraits d'un audit réalisé sur un ensemble de très grosses bases (plusieurs dizaines de To) :
    Notez juste le nombre de ligne : 3 146 806 488
    Vous avez bien lu... 3 milliards 146 millions de ligne dans une table... temps de traitement 687 ms...

    Bref lorsqu'un développeur me parle de NoSQL comme étant beaucoup plus rapide, je me marre !!!

    A +
    Notez que je ne cherche absolument pas à offenser. Cet article parle de pratiques commerciales contestées. Bien sûr que nous sommes tous concernés par les perfs mais ce n'est pas le sujet de fond.

    La question soulevée par cet article est "Peut-on se débarrasser d'un éditeur de SGBD qui a compris que vous ne pouvez pas facilement remplacer son produit parce que vous avez beaucoup développé dessus ?"

    La réponse à cette question est complexe et votre approche ne plaide pas pour l'adoption d'une technologie quelconque. D'autant que pour pertinente qu'elle soit , votre démonstration est un gros test unitaire qui ne prouve pas un comportement en charge et je vais développer ces point.

    Les 300 milliards de lignes dont j'ai parlé ne sont qu'un exemple de ce qui risque d'arriver quand un développement a sous-évalué la volumétrie (cas fréquent). On apprécie que le serveur "tienne la charge" mais ce n'est certainement pas un exemple à suivre pour autant. Bien sûr qu'il aurait mieux valu faire en sorte que la table n'atteigne jamais ce nombre mais à l'époque du développement, cela n'avait pas été anticipé. On ne pouvait pas prévoir cette évolution.

    Maintenant, s'il n'y a pas d'autre moyen, il faudra développer une solution alternative. Mais si votre SGBD a doublé son prix entretemps, vous n'êtes pas très chaud pour accroître votre dépendance à son égard.

    Ce n'est pas le nombre millisecondes ou de lignes que je retiens de votre échange. C'est plutôt l'arrogance avec laquelle vous assénez un test tellement complexe que personne ne va le reproduire (sans compter tous ceux qui ne le comprennent pas).

    Je suis un projet pour un très grand compte qui ne relève pas du back-office mais plutôt d'un process industriel où on stocke des valeurs et des mesures (floats) et où le volume dépasse souvent le milliard de lignes.
    Un concurrent propose une solution basée sur le SGBD que vous défendez et perd régulièrement tous les appels d'offre. Je sais pourquoi je remporte à chaque fois. Le client est très regardant sur la dépendance aux éditeurs. C'est même une partie importante de son métier. C'est pourquoi je me suis permis d'intervenir sur ce thread. En termes de perfs, je n'obtiens jamais vos chiffres mais je me débrouille pas mal avec des tables temporaires. C'est pourquoi j'ai cité le problème des indexes partiels.

    En tous cas. Je n'ai pas changé d'appréciation sur SQL Server suite à cette discussion. Il est sans doute le plus rapide mais... comme avec les autres grands éditeurs, vous l'adoptez comme une religion et ne pouvez plus rien faire d'autre que de défendre votre choix par la suite. Dommage pour les développements qui ne correspondront jamais à ce profil.
    Attention à Fred - Roman - Prophétie spatiale - action intrépide.

  4. #24
    Chroniqueur Actualités

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2018
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2018
    Messages : 249
    Points : 8 986
    Points
    8 986

    Par défaut Le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle

    Le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle
    Dans des efforts de la société de se séparer des produits Oracle

    Amazon, leader du commerce électronique à l’échelle mondiale et l’un des géants de l’acronyme GAFAM (Google, Apple, Facebook, Amazon et Microsoft), qui au départ était spécialisé dans la distribution des produits divers en ligne, est aujourd’hui l’un des leaders du marché du cloud computing, à cause de ses prouesses en la matière. Depuis quelques années, la société a fait savoir que d’ici 2020, elle se séparerait des produits Oracle pour faire migrer ses bases de données Oracle vers sa propre technologie de bases de données.

    Ce processus de migration des données d’Amazon vers sa technologie en nuage est en très bonne voie, c’est ce que nous apprend un article de Bloomberg publié le vendredi dernier selon lequel Amazon aurait franchi une nouvelle étape dans l'élimination des logiciels d'Oracle qui ont longtemps aidé le géant du commerce électronique à gérer ses activités de vente au détail. En effet, le secteur de consommation de la société a désactivé son entrepôt de données Oracle après avoir migré les données du secteur vers son infrastructure en nuage.

    Nom : Ora01.jpg
Affichages : 3532
Taille : 17,3 Ko

    En effet, Amazon est devenu un concurrent de taille de son fournisseur Oracle depuis que la société s’est lancée dans le développement de nombreux produits concurrents tels que Redshift, Aurora et DynamoDB.

    Cependant, les raisons d’abandon des produits d’Oracle par Amazon qui s’était toujours satisfait dans l’utilisation des produits Oracle sont de deux ordres. La première raison, Amazon considère que la technologie de base de données de son fournisseur n’est plus capable d’évoluer pour suivre l’élargissement des produits et services que la société offre à sa clientèle. La seconde raison s’explique par les frais de licence exorbitants qu’impose Oracle à ses clients et la technique de vente agressive adoptée par le spécialiste en base de données sur site.

    L’annonce des nouveaux progrès d’Amazon dans ses efforts d’abandonner définitivement l’utilisation des SGBD et des services d’Oracle a été faite, vendredi dernier, par Andy Jassy, directeur général d'Amazon Web Services, selon Bloomberg. Il a, par ailleurs, profiter de l’occasion pour répondre à la moquerie du président exécutif et directeur de la technologie d’Oracle Corporation, Larry Ellison, qui avait, le mois dernier, ridiculisé le géant du commerce électronique d’utiliser les bases de données Oracle pour suivre les transactions et stocker des informations, alors qu’il vend des logiciels concurrents.

    « Dans le dernier épisode de « uh huh, keep talkin’ Larry, », le secteur de consommation d'Amazon a désactivé son entrepôt de données Oracle le 1er novembre et est passé à Redshift », a écrit Jassy dans un tweet. D'ici fin 2018, Amazon cessera d'utiliser 88 % de ses bases de données Oracle, y compris 97 % de ses bases de données stratégiques, a-t-il ajouté.

    Nom : And001.png
Affichages : 3632
Taille : 70,8 Ko

    Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle. Cependant, le processus de migration des données vers la technologie d’Amazon lancé le mois dernier ne s’est pas déroulé de façon régulière au départ. En effet, selon un article de CNBC, publié le 23 octobre, le premier jour du démarrage du processus de migration, alors que l’entreprise rencontrait déjà des soucis majeurs liés au site web qui ralentissaient les ventes, elle a dû également faire face à un problème technique dans l’un des plus grands entrepôts de l’Ohio, qui a entrainé des milliers de retards de livraison.

    Amazon n’est pas le seul client d’oracle qui a décidé d’abandonner les produits du fournisseur Oracle. SAP SE, fournisseur de bases de données et d'applications tente aussi de se séparer d'Oracle, après avoir acquis plusieurs sociétés qui utilisent des produits Oracle. SAP SE est par ailleurs en train de faire migrer ses filiales vers son propre logiciel.

    La société d'exploration pétrolière et gazière Halliburton, le fabricant de jouets Mattel et le fournisseur d'électricité Edison Southern California, ont également rejeté, en mai dernier, les offres de services cloud proposées par Oracle.

    Source : Bloomberg

    Et vous ?

    Qu’en pensez-vous ?
    Oracle arrivera-t-il à récupérer les clients perdus ou à se faire de nouveaux grâce à son service cloud public ?

    Voir aussi

    Amazon envisage d'abandonner complètement les SGBD et services d'Oracle d'ici 2020, Oracle serait incapable de répondre à ses besoins de performance
    Un problème technique affecte un entrepôt d'Amazon, suite à la migration de bases de données Oracle, vers sa propre technologie de base de données
    Selon Larry Ellison, les nouvelles technologies cloud d'Oracle ont vingt ans d'avance sur celles d'Amazon, partagez-vous cet avis ?
    Oracle renforce son offre Cloud avec 24 nouveaux services, pour mieux concurrencer AWS
    Les techniques de vente agressives d'Oracle s'avèrent contre-productives, elles ont tendance à chasser certains clients
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  5. #25
    Membre régulier
    Profil pro
    Inscrit en
    novembre 2005
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France, Seine et Marne (Île de France)

    Informations forums :
    Inscription : novembre 2005
    Messages : 105
    Points : 122
    Points
    122

    Par défaut

    Le moment de vérité sera lors du black friday ... soit cela tient et Oracle est mort, soit ça craque et Bezos a l' air fin . C 'est quitte ou double.

  6. #26
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 700
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 700
    Points : 13 835
    Points
    13 835

    Par défaut

    Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle.
    étant donné qu'on n'est jamais mieux servi que par soi-même ça évite à Amazon de dépenser des milliions dans des licences Oracle

    Remarquez certains "gros machins" comme par exemple l'administration française ou des grosses entreprises devraient prendre l'exemple
    Et en rentrant dans un magasin de meubles, Protagoras se dit : "l'Homme est la juste mesure des chaises"

  7. #27
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 013
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 013
    Points : 31 731
    Points
    31 731
    Billets dans le blog
    5

    Par défaut

    Remarquez certains "gros machins" comme par exemple l'administration française ou des grosses entreprises devraient prendre l'exemple
    Il est fortement question que l'ERP dédié à l'enseignement supérieur que nous utilisons abandonne Oracle au profit de PostgreSQL... à cause du coût des licences.
    La décision et le début de la migration devrait intervenir en 2019. Mais ce n'est pas un petit chantier.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  8. #28
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 918
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 918
    Points : 8 957
    Points
    8 957
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    La clause WHERE des index est supportée dans la plupart des SGBDR. La compression des index aussi dans les grands SGBDR (Oracle, SQL Server...). Seul SQL Server propose en sus la possibilité de faire des index couvrants via la clause INCLUDE
    Pour info, DB2 for Z/OS le propose aussi.
    Il me semble depuis la V11

    EDIT : non c'est depuis la V10

  9. #29
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    Pour info, DB2 for Z/OS le propose aussi.
    Il me semble depuis la V11

    EDIT : non c'est depuis la V10
    L'important, ce n'est pas les fonctionalités implémentées, mais les solutions à des problèmes. Oracle n'a pas d'index couvrant, mais n'en a probablement pas besoin car d'autres fonctionnalités répondent au mêmes besoins (compression prefixe dans les branches, Index Only access path,...)
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  10. #30
    Chroniqueur Actualités

    Homme Profil pro
    Consultant informatique
    Inscrit en
    avril 2018
    Messages
    249
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2018
    Messages : 249
    Points : 8 986
    Points
    8 986

    Par défaut Amazon aura supprimé toutes les bases de données Oracle d'ici la fin 2019, déclare le chef AWS

    D’ici fin 2019, Amazon aura complètement abandonné les bases de données d’Oracle
    Selon le PDG d’Amazon Web Services

    Commencée il y a 4 à 5 ans, la migration d’Amazon vers ses propres infrastructures continue et serait en voie de se terminer. Selon CNBC, la transition serait complètement achevée d’ici fin 2019 en ce qui concerne les bases de données, d’après les déclarations du PDG d’Amazon Web Services, Andy Jassy. En août dernier, Amazon a annoncé qu’il envisageait d'abandonner complètement les SGBD et services d'Oracle d'ici 2020. En effet, l’émergence d'Amazon en tant que fournisseur majeur de technologie de centre de données a transformé un grand nombre de ses fournisseurs de longue date, y compris Oracle, en rivaux redoutables.

    Certaines raisons ont emmené Amazon à vouloir abandonner les produits Oracles et à migrer vers ses propres produits concurrents. En effet, selon le géant du commerce de détail en ligne, la technologie de base de données de son fournisseur n’est plus capable d’évoluer pour suivre l’élargissement des produits et services qu’Amazon offre à sa clientèle.

    Amazon doit cette performance à l'expansion d'Amazon Web Services qui lui a, par ailleurs, permis de surclasser Alphabet en début d’année pour devenir la deuxième entreprise cotée en bourse la plus importante au monde. Au second trimestre de cette année, AWS a enregistré une croissance de 49 % et en septembre dernier, Amazon a franchi le cap des 1000 milliards de dollars en capitalisation boursière, un mois après que le géant Apple ait réalisé cet exploit, alors que les résultats d’Oracle stagnent et les actions continuent de chuter.

    Aussi, Amazon abandonne les produits Oracle, comme d’autres entreprises l’ont fait, à cause des frais de licence exorbitants qu’impose Oracle à ses clients et la technique de vente agressive adoptée par le fournisseur.

    Nom : AJ.jpg
Affichages : 3565
Taille : 24,3 Ko

    Amazon a décidé de basculer vers ses propres infrastructures maintenant qu’il est un acteur majeur du cloud computing et de laisser tomber les services d’Oracle. Il a développé également des produits concurrents, notamment Redshift, Aurora et DynamoDB. En début novembre, le secteur de consommation d’Amazon a désactivé son entrepôt de données Oracle après avoir migré les données du secteur vers son infrastructure en nuage, notamment vers Redshift.

    Amazon a réitéré sa volonté d’abandonner les produits Oracle, selon un article de CNBC du mercredi dernier. Selon le PDG d’Amazon Web Services, la migration se passe plutôt bien du côté des bases de données. D’ici la fin de cette année, la quasi-totalité des bases de données d'Amazon qui fonctionnaient sur Oracle seront plutôt sur une base de données Amazon, selon Jassy. « Nous avons pratiquement terminé d'abandonner Oracle du côté de la base de données », a déclaré Jassy mercredi à Jon Fortt de CNBC, lors d'une interview. « Et je pense que fin 2019 ou mi-2019, nous aurons terminé. », a-t-il ajouté.

    Cette migration est à la base d’une certaine hostilité entre le géant mondial du commerce électronique de détail et le leader des bases de données sur site. La guerre des mots a commencé avec le lancement d’Aurora, le service de base de données relationnelle d’Amazon ainsi qu’un outil permettant aux entreprises de déplacer des bases de données vers le cloud qui visent le marché d’Oracle et qui attitreraient déjà certains de ses clients.

    Mais cela n’empêche pas Amazon de continuer à réduire sa dépendance d’Oracle pour ses besoins en données et d’utiliser plutôt ses propres services. 88 % des bases de données Amazon qui fonctionnaient sur Oracle le seront sur Amazon DynamoDB ou Amazon Aurora d’ici janvier, a déclaré Jassy. 97 % des « bases de données stratégiques » fonctionneraient sur DynamoDB ou Aurora d'ici la fin de l'année, a-t-il ajouté.

    Le mouvement d’abandon des produits et services d’Oracle s’étend à plusieurs autres entreprises. Le fournisseur de bases de données et d’applications, SAP SE, est en train de faire migrer progressivement ses données vers ses propres infrastructures.

    La société d'exploration pétrolière et gazière Halliburton, le fabricant de jouets Mattel et le fournisseur d'électricité Edison Southern California, ont également rejeté, en mai dernier, les offres de services cloud proposées par Oracle.

    Source : CNBC

    Et vous ?

    Qu’en pensez-vous ?
    Pensez-vous qu’Amazon pourra tenir ce calendrier de migration ?

    Voir aussi

    Un problème technique affecte un entrepôt d'Amazon, suite à la migration de bases de données Oracle, vers sa propre technologie de base de données
    MariaDB rachète la technologie de base de données distribuée Clustrix, pour concurrencer Oracle RAC
    Oracle Autonomous Transaction Processing : Oracle renforce sa base de données cloud autonome, avec un nouveau service de traitement transactionnel
    Revenus cloud : les actionnaires d'Oracle lui reprochent d'avoir livré des communiqués trompeurs, un recours collectif se prépare contre la société
    Amazon publie une préversion de Corretto, une distribution gratuite d'OpenJDK, qui devrait devenir la distribution par défaut sur Amazon Linux 2
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  11. #31
    Membre éclairé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    378
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 378
    Points : 749
    Points
    749

    Par défaut

    Petite guguerre d'egos entre eux, c'est de la comm legitime, ils se trouvent concurrents.
    Est-ce que pour autant ca poussera un client oracle lambda a passer a dynamodb ou autre, pas certain; car les memes problemes de couts, hebergement etc restent probables (on l'a vecu sur tentative de passage vers sqlserver).
    On est toujours chez oracle, ca rassure nos clients plutot que de mettre des BDD autres (mongodb ou autre).
    Sur des projets a plusieurs millions, les licences sont une paille (comme pour les vendeurs de voitures ou de canapés, les reductions appliquées (80% pour nos projets)) (et la garantie de faire migrer des données 10-20 ans apres est reelle puisqu'on l'a vecu sur plusieurs dizaines de projets sans se poser de questions tout en tirant partie des nouvelles fonctionnalités/gains de perfs).

  12. #32
    Modérateur
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    mars 2004
    Messages
    4 689
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : mars 2004
    Messages : 4 689
    Points : 11 668
    Points
    11 668
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par Stan Adkens Voir le message
    Oracle a réitéré sa volonté d’abandonner les produits Oracle
    Enfin !!! Il serait temps

    # Dans la Création, tout est permis mais tout n'est pas utile...

  13. #33
    Expert confirmé
    Avatar de pachot
    Homme Profil pro
    DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Inscrit en
    novembre 2007
    Messages
    1 640
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Suisse

    Informations professionnelles :
    Activité : DBA au CERN (Genève), Oracle ACE Director, OCM 12c, Oak Table
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2007
    Messages : 1 640
    Points : 5 780
    Points
    5 780
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par kilroyFR Voir le message
    (et la garantie de faire migrer des données 10-20 ans apres est reelle puisqu'on l'a vecu sur plusieurs dizaines de projets sans se poser de questions tout en tirant partie des nouvelles fonctionnalités/gains de perfs).
    Oui. Et vers n'importe quelle platforme, Cloud ou on-premises. Passer sur des solutions propiétaires AWS impose de rester sur le cloud.
    Franck Pachot - DBA au CERN - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  14. #34
    Membre éclairé
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    août 2014
    Messages
    378
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : août 2014
    Messages : 378
    Points : 749
    Points
    749

    Par défaut

    Citation Envoyé par pachot Voir le message
    Passer sur des solutions propiétaires AWS impose de rester sur le cloud.
    Oui (petite parenthese) vecu a titre personnel dans une association (internationale) a laquelle j'appartiens.
    On est passé d'une solution avec hebergement classique (serveurs chez BigDaddy) a plusieurs centaines de $ a l'année a une solution complete toute hebergée dans AWS a 10 000 $ sur 3 ans.
    Maintenant on est ferré chez eux et finalement toutes les technos et autres elements technos mis en avant sur lequel nos admins ont bavé ne sont pas exploités (faut de temps et d'investissement perso pour s'y former).
    Ca nous coute un bras par an et pour le moment on est dans une fuite en avant. Une gabegie financiere tout ca pour s'etre fait berné par des potentiels besoins (qu'on n'avait pas et qu'on n'aura jamais). Tous les ans les membres de l'assoc (plusieurs 10aine de milliers de membres heureusement se cotisent pour financer le monstre).
    Plus aucun autonomie; on maitrisait tout, on ne maitrise plus rien. Amazon ne vaut pas mieux que les autres.

Discussions similaires

  1. Microsoft dévoile les preview des logiciels Oracle sur Windows Azure
    Par Hinault Romaric dans le forum Microsoft Azure
    Réponses: 2
    Dernier message: 17/03/2014, 09h20
  2. Réponses: 2
    Dernier message: 21/08/2009, 14h41
  3. Impossible de télécharger des logiciels Oracle
    Par awalter1 dans le forum Installation
    Réponses: 7
    Dernier message: 20/09/2008, 09h18
  4. Oracle Forms6i Gestion des messages Oracle
    Par macyas dans le forum Forms
    Réponses: 9
    Dernier message: 31/01/2008, 17h58
  5. Des logiciels pour l'analyse des fichiers log
    Par maya dans le forum Réseau
    Réponses: 3
    Dernier message: 14/04/2007, 23h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo