Discussion :

[StringBuilder]

Etre en mesure de restaurer un objet / une table d'un backup, sans remonter toute la base...

En parlant de restauration, autre point qui me semble bien plus simple à mettre en œuvre et qui ne risque pas de remettre en cause l'intégrité des données :

Permettre de modifier la taille cible des fichiers restaurés. Soit à la hausse, soit à la baisse en fonction de la place disponible.

[iberserk]

En parlant de restauration, autre point qui me semble bien plus simple à mettre en œuvre et qui ne risque pas de remettre en cause l'intégrité des données :

Permettre de modifier la taille cible des fichiers restaurés. Soit à la hausse, soit à la baisse en fonction de la place disponible.

En effet particulièrement utile dans le cadre de la mise à disposition des environnement de dev/preprod.

[SQLpro]

Pourquoi ne pas proposer tout cela dans le site dédié de Microsoft : SQL Azure feedback ?
https://feedback.azure.com/forums/908035-sql-server

A +

[mikedavem]

Etre en mesure de restaurer un objet / une table d'un backup, sans remonter toute la base...

Cela manque en effet et c'est quelque chose qui est attendu par la communauté depuis un bon bout de temps ... peut être qu'un jour nous aurons à disposition cette fonctionnalité

Un "vrai" cluster, avec un vrai actif-actif (mais pour ça, il faut gérer les accès concurrents dans des mémoires différentes...)

Pour avoir discuté longuement avec des DBA oracles, c'est une fonctionnalité qui est souvent mise en avant du point de vue technique mais qui est peu utilisée chez les clients. J'ai vu plus d'implémentation dataguard que de RAC au final. RAC est une très bonne fonctionnalité d'un point de vue technologique mais elle coûte extrêmement cher à implémenter et ceci dès qu'on parle d'infrastructure ou de coût en licence .. d'où un retour fréquent vers des solutions moins onéreuses (Dataguard) que j'ai pu constater ces dernières années et qui conviennent finalement aux besoins clients. En plus en fonction du type de transaction ce n'est pas toujours évident même avec TAF ...

De ce que j'ai pu comprendre de Microsoft (pas d'affirmation à 100% ici) c'est qu'ils n'iront pas forcément vers ce genre de fonctionnalités car l'investissement R&D + maintenance serait bien trop important comparé au nombre de clients réellement intéressés ... En gros ce n'est pas un problème de faisabilité technique mais un investissement financier qui ne serait pas rentable ..

++

[SQLpro]

… RAC…

De ce que j'ai pu comprendre de Microsoft (pas d'affirmation à 100% ici) c'est qu'ils n'iront pas forcément vers ce genre de fonctionnalités car l'investissement R&D + maintenance serait bien trop important comparé au nombre de clients réellement intéressés ... En gros ce n'est pas un problème de faisabilité technique mais un investissement financier qui ne serait pas rentable ..

++

En sus de ce que dis David Barbarin, la grande différence entre Oracle et SQL Server est que SQL Server dispose de 7 mécanismes de haut niveau pour la réplication de données (je ne parle pas de la haute dispo, mais de transport de données d'une serveur l'autre avec des filtres dans tous les sens) permettant de concevoir des infrastructures applicatives avec des surfaces d'attaque à plusieurs serveur. Par exemple, fnac.com utilisait 8 serveur SQL en frontaux, chacun ayant quelques données communes (produits) et chacun 1/8 des clients…..
Cela n'est pas le strict équivalent de RAC, mais une fonctionnalité assez proche, et surtout beaucoup moins cher en terme d'accès, développement et maintenance...
La réplication des données n'ayant jamais été le fort d'Oracle (et en plus Golden Gate, c'est horriblement cher !!!)

A +

[Michel.Priori]

Même si certains ont développé des procédure de contournement (https://raresql.com/2011/10/22/how-t...rom-sql-sever/) disposer de la fonctionnalité en natif d'Oracle flashback et de corbeille serait appréciable (et surtout documenté de manière officielle).

[SQLpro]

Même si certains ont développé des procédure de contournement (https://raresql.com/2011/10/22/how-t...rom-sql-sever/) disposer de la fonctionnalité en natif d'Oracle flashback et de corbeille serait appréciable (et surtout documenté de manière officielle).

Il y a aussi des produits commerciaux qui font cela comme Apex Log Explorer…..

A +

[lionelcha21]

Bonjour à tous,

Soyez indulgent, c'est la première fois que j'écris dans un forum .

Voici une petite amélioration qui pourrait nous servir, j'en suis certain.

Explication :

Imaginons que l'on créé une table avec un champ ayant une valeur par défaut (dans la définition de la colonne).

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
CREATE TABLE [MaTable]
(
    [Id] TINYINT NOT NULL
    , [MaColonne] VARCHAR(4000) NOT NULL DEFAULT REPLICATE('T', 4000)
);

--> Lorsque je vais insérer un tuple dans la table en ne mettant pas de valeur dans la colonne "MaColonne", cela va copier la chaîne de caractères précisée par défaut, à savoir 4 000 lettre "T". Ainsi, l'espace mémoire par tuple est très conséquent !!
--> j'imagine une solution où ce ne serait pas la valeur par défaut qui serait enregistrée mais un pointeur vers cette valeur (valeur qui serait donc enregistrée une seule fois au moment de la création de la table).
--> Cependant, si l'utilisateur insert une valeur autre que celle par défaut, elle serait enregistrée classiquement comme avant... Mais au moins, il y aurait un gain en mémoire pour les valeurs par défaut.

Qu'en pensez vous ? Suis-je à côté de la plaque ?

Bien à vous.

Modification de ce message :

Je me rends compte que ce serait impossible pour des valeurs par défaut complexes de type "DEFAULT GETDATE()"...
Ce serait cependant utile pour des chaines de caractères sur des tailles de BDD très volumineuses (plusieurs 10ène - 100ène de Giga)...

De plus, je me doute que la complexité pour mettre en place ce genre de mécanisme est très forte.

[al1_24]

Ce mode de fonctionnement existe déjà dans Teradata, qui propose (Option COMPRESS dans la déclaration d'une colonne) de remplacer NULL ou la valeur par défaut par un bit dans l'entête de la ligne, voire stocker jusqu'à 255 valeurs définies à la création de la table sous la forme d'un seul octet, sans interdire l'utilisation d'autres valeurs que celles de cette liste (à ne pas confondre donc avec le type ENUM d'autres SGBD).
Et, en effet, c'est une économie sur le volume de données mais cela n'a d'intérêt que si ce fonctionnement est inscrit nativement dans le moteur de base de données.

[lionelcha21]

Ce mode de fonctionnement existe déjà dans Teradata

Je vous remercie car je ne connaissais pas le SGBD "Teradata". Cependant, si je ne dis pas de sottise, cela n'a rien à voir avec SQL Server non ?
Cependant, je garde l'info .

C'est une économie sur le volume de données mais cela n'a d'intérêt que si ce fonctionnement est inscrit nativement dans le moteur de base de données.

Oui, cela va de soit .

Merci pour la réponse rapide.

[mikedavem]

Je vous remercie car je ne connaissais pas le SGBD "Teradata". Cependant, si je ne dis pas de sottise, cela n'a rien à voir avec SQL Server non ?
Cependant, je garde l'info .

Effectivement rien à voir avec SQL Server mais la compression est aussi native (PAGE, ROW, COLUMNSTORE) et peut arriver au même type de résultat

Toutefois la fonction REPLICATE fait bien ce qu'on lui dit .. il réplique la donnée et le stockage qui lui est associé. Les techniques d'optimisation via la compression répondent un peu à ce que tu voulais faire
J'utilise beaucoup cette fonction dans des tests ou démos là où cherche justement à provoquer l'occupation de l'espace pour voir certains comportements du moteur

++

[aieeeuuuuu]

Bonjour

Les valeurs par défaut contiennent très souvent une valeur dynamique, notamment la date/heure courante, ce qui rend la chose ingérable (comme vous l'avez fait remarquer)
De plus en cas de changement de la valeur par défaut, il faut alors gérer, comme vous l'avez également proposé, un pointeur, (et non pas simplement stocker la valeur par défaut pour la colonne dans l'en-tête de table). Ce pointeur aura également un cout de stockage, et il est par ailleurs tout à fait possible d'obtenir ce comportement en créant une table pour stocker les valeurs par défaut, et mettre simplement la clef dans la table principale. C'est d'ailleurs ce que je ferai si je devais stocker une valeur avec une telle volumétrie (partitionnement vertical)
Dans le cas ou la colonne est non nullable, il est également possible de la rendre nullable, et de créer une vue pour remplacer les NULL par la valeur par défaut avec un simple COALESCE

[SQLpro]

Même si certains ont développé des procédure de contournement (https://raresql.com/2011/10/22/how-t...rom-sql-sever/) disposer de la fonctionnalité en natif d'Oracle flashback et de corbeille serait appréciable (et surtout documenté de manière officielle).

Et aussi depuis la version 2016 les tables d'historisation normalisées qui sont là pour cela.

A +

[SQLpro]

Ce mode de fonctionnement existe déjà dans Teradata, qui propose (Option COMPRESS dans la déclaration d'une colonne) de remplacer NULL ou la valeur par défaut par un bit dans l'entête de la ligne, voire stocker jusqu'à 255 valeurs définies à la création de la table sous la forme d'un seul octet, sans interdire l'utilisation d'autres valeurs que celles de cette liste (à ne pas confondre donc avec le type ENUM d'autres SGBD).
Et, en effet, c'est une économie sur le volume de données mais cela n'a d'intérêt que si ce fonctionnement est inscrit nativement dans le moteur de base de données.

La compression de type PAGE dans les tables et index correspond exactement à cela dans SQL Server...

A +

[Ikebukuro]

La réplication des données n'ayant jamais été le fort d'Oracle (et en plus Golden Gate, c'est horriblement cher !!!)

Il est vrai que Oracle ne propose pour dupliquer des données que peu d'outils : Copy, Export/Import, Datapump, Streams, Golden Gate, RMAN Duplicate, Dataguard etc etc

[Ikebukuro]

Même si certains ont développé des procédure de contournement (https://raresql.com/2011/10/22/how-t...rom-sql-sever/) disposer de la fonctionnalité en natif d'Oracle flashback et de corbeille serait appréciable (et surtout documenté de manière officielle).

Vous avez pas ça avec SQL Server? Même pas la récupération d'une table droppée par erreur?
La première implémentation de Flashback Oracle doit remonter à 1996 avec Oracle 8.
Attention : la techno Flashback est très diverse, un lien ici qui montre tout ce qui est possible de faire comme retour en arrière.
https://easyteam.fr/tout-ce-que-vous...back-partie-1/

[SQLpro]

Il est vrai que Oracle ne propose pour dupliquer des données que peu d'outils : Copy, Export/Import, Datapump, Streams, Golden Gate, RMAN Duplicate, Dataguard etc etc

Encore une fois, rien à voir : il n'y a guerre que GoldenGate qui soit proche des notions de réplication de données de SQL Server… Un simple exemple : SQL Server permet de répliquer l'exécution d'une procédure stockée…. Ni Copy, ni Export/Import, ni Datapump, ni dataguard ne permet cela…
Dataguard n'état pas une solution de réplication de données, mais de haute dispo (ne pas confondre !)

A +

[Ikebukuro]

Encore une fois, rien à voir : il n'y a guerre que GoldenGate qui soit proche des notions de réplication de données de SQL Server… Un simple exemple : SQL Server permet de répliquer l'exécution d'une procédure stockée…. Ni Copy, ni Export/Import, ni Datapump, ni dataguard ne permet cela…
Dataguard n'état pas une solution de réplication de données, mais de haute dispo (ne pas confondre !)

Pas d'accord, avec Dataguard ma base Stand by est une copie de la base de prod donc on peut parler de copie de données; si la base nominale tombe, on bascule sur la stand by, ce qui est bien la preuve que les mêmes données sont sur les deux bases, mais Dataguard n'est pas conçu à la base pour ça.

Et c'est pour quand un input file .sql pour bcp? Quand j'ai un SELECT qui fait 100 lignes, impossible de le saisir dans la fenêtre cmd...

[SQLpro]

Pas d'accord, avec Dataguard ma base Stand by est une copie de la base de prod donc on peut parler de copie de données; si la base nominale tombe, on bascule sur la stand by, ce qui est bien la preuve que les mêmes données sont sur les deux bases, mais Dataguard n'est pas conçu à la base pour ça.

Donc, c'est bien de la haute dispos car vous répliquez l'intégralité de la base et non pas certaines données de certaines tables pour alimenter une autre base de données dont la structure n'est pas forcément la même...

Et c'est pour quand un input file .sql pour bcp? Quand j'ai un SELECT qui fait 100 lignes, impossible de le saisir dans la fenêtre cmd...

Je ne voit pas ou se situe le problème.... BCP fait de l'INPUT et de l'OUTPUT...
Décrivez-moi ce que vous n'arrivez pas à faire.

A +

[aieeeuuuuu]

Et c'est pour quand un input file .sql pour bcp? Quand j'ai un SELECT qui fait 100 lignes, impossible de le saisir dans la fenêtre cmd...

pour ça, il faut utiliser sqlcmd avec le paramètre -i