none
Sauvegarde anciennes données avec une planification RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour,

    Ne connaissant pas très bien les nouvelles versions de SQL Server (2014) je ne sais pas si ce que je souhaite est possible :

    Problème : J'ai une base de données qui grossit (~ 1 To) mais pour des raisons strictement internes je ne dois avoir dans la base de données QUE les données 'utiles' (~ 15 jours) le "reste" devant "aller ailleurs" mais rapidement accessible si nécessaire.

    A mon niveau de connaissance, je peux créer une sauvegarde automatique de la base entière vers une seconde base de données, puis supprimer les données plus anciennes que x jours dans la base "live".

    Ceci étant j'aurai aimé quelque chose de plus "propre" qui ne "déplacerait" QUE les données devenues 'inutiles'. Et que la procédure puisse être planifiée. Ceci permettrait de minimiser les transferts entre les 2 bases (2 servers différents qui, à terme, pourraient être sur 2 sites distincts)

    Sachant qu'il existe des solutions SQL "toutes prêtes" je me demandais si l'une d'elle pourrait m'aider en tout ou partie ?

    (always on, replica, etc...)

    Merci d'avance. Et désolé si cela semble redondant avec une autre question... Ne sachant pas vraiment ce que je recherche je n'ai pas su trouver de réponse à mon besoin.

    lundi 10 juillet 2017 14:22
    |

Réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    J'ai la sensation que la réponse se trouve dans le partitionnement.

    1. Vous partitionnez votre grosse base sur une clé de type date sur une granularité jour ou semaine (que j'appelle : Base_Source)
    2. Si votre base source est en recovery FULL vous pourrez réaliser les opérations suivantes pour rafraîchir le 2nd environnement :

    1. Backup de la partition de la base source que vous voulez migrer
    2. Restaurer juste le filegroup et donc la partition
    3. Réaliser l'opération de donner sur la base source (dans l'idéal via table de staging, switch de partition et drop de la table)
    4. Merge de partition
    5. Drop du filegroup qui n'est plus utilisé$

    Cette opération nécessite comme prérequis :

    • D'avoir restauré en mode partiel la base source sur le 2nd envirionnement
    • D'avoir la base en recovery full (si simple dans ce cas il ne sera pas possible de restaurer petit à petit sur le 2nd environnement tout en laissant les données accessible)

    Je pense que cette méthode pourrait marché, je ne l'ai pas détaillé complétement mais l'approche est là.


    • Marqué comme réponse MuadhDhib lundi 24 juillet 2017 08:42
    mercredi 19 juillet 2017 15:43
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour ,

    Si vous avez la possibilité de migrer votre serveur à la version SQL Server 2016, étudiez l'apport de la fonctionnalité Stretch database

    https://docs.microsoft.com/fr-fr/sql/sql-server/stretch-database/stretch-database.

    ça peut répondre à votre besoin avec le minimum d'effort administratif.

    par contre faite attention aux limites de la fonctionnalité

    https://docs.microsoft.com/fr-fr/sql/sql-server/stretch-database/limitations-for-stretch-database

    AlwaysOn ou la réplication ne peuvent pas répondre à votre besoin.

    Cordialement

     

     

    J.K

    • Marqué comme réponse MuadhDhib lundi 24 juillet 2017 08:42
    mercredi 19 juillet 2017 16:08
    |

Toutes les réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour

    J'ai la sensation que la réponse se trouve dans le partitionnement.

    1. Vous partitionnez votre grosse base sur une clé de type date sur une granularité jour ou semaine (que j'appelle : Base_Source)
    2. Si votre base source est en recovery FULL vous pourrez réaliser les opérations suivantes pour rafraîchir le 2nd environnement :

    1. Backup de la partition de la base source que vous voulez migrer
    2. Restaurer juste le filegroup et donc la partition
    3. Réaliser l'opération de donner sur la base source (dans l'idéal via table de staging, switch de partition et drop de la table)
    4. Merge de partition
    5. Drop du filegroup qui n'est plus utilisé$

    Cette opération nécessite comme prérequis :

    • D'avoir restauré en mode partiel la base source sur le 2nd envirionnement
    • D'avoir la base en recovery full (si simple dans ce cas il ne sera pas possible de restaurer petit à petit sur le 2nd environnement tout en laissant les données accessible)

    Je pense que cette méthode pourrait marché, je ne l'ai pas détaillé complétement mais l'approche est là.


    • Marqué comme réponse MuadhDhib lundi 24 juillet 2017 08:42
    mercredi 19 juillet 2017 15:43
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour ,

    Si vous avez la possibilité de migrer votre serveur à la version SQL Server 2016, étudiez l'apport de la fonctionnalité Stretch database

    https://docs.microsoft.com/fr-fr/sql/sql-server/stretch-database/stretch-database.

    ça peut répondre à votre besoin avec le minimum d'effort administratif.

    par contre faite attention aux limites de la fonctionnalité

    https://docs.microsoft.com/fr-fr/sql/sql-server/stretch-database/limitations-for-stretch-database

    AlwaysOn ou la réplication ne peuvent pas répondre à votre besoin.

    Cordialement

     

     

    J.K

    • Marqué comme réponse MuadhDhib lundi 24 juillet 2017 08:42
    mercredi 19 juillet 2017 16:08
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir

    Il ne me semble pas qu'avec les stretch database qu'on puisse exporter une partie de la base sur une 2nd instance, hors il me semble que c'est l'objectif ici (ou alors j'ai mal compris le problème de base).
    Stretch database permet de migrer vos données dans le cloud mais dans la même instance et le moteur SQL gère de lui-même s'il est nécessaire d'aller lire/écrire dans le cloud et/ou sur votre serveur.

    mercredi 19 juillet 2017 20:56
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir

    C'est exacte et les données dites accessible à froid restent visible pour l'application et il n'y a pas d'effort administratif spécifique pour répondre au besoin.

    Le besoin comme il est décrit dans le paragraphe Problème, consiste à garder 15 jours de données chaudes et le reste devient des données froides , donc une Stretch database peut répondre au besoin.

    Le partitionnement et comme vous l'avez présenter peut répondre au besoin par contre ceci impliquera des tâches de split ,  sauvegarde de groupes de fichier et restauration sur l'autre serveur et des merge de partitions.... et il ne faut pas oublier qu'on aura besoin de l'édition Enterprise.

    J.K

    mercredi 19 juillet 2017 22:15
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter
    Bonjour Grégory et merci pour votre réponse.

    Je ne connais pas bien le principe de partitionnement mais je vais y regarder de plus près.

    Merci beaucoup pour l'idée ;)
    lundi 24 juillet 2017 08:35
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour Jaouher,

    Je ne sais pas si je peux utiliser le Cloud (à voir) mais l'idée reste intéressante et je vais voir si je peux l'exploiter.

    Merci pour votre aide.

    lundi 24 juillet 2017 08:41
    |