Discussion :

[new_wave]

Bonjour,

Pouvez vous me dire dans quel cas remplacer un jeu de sauvegarde existant peut s'avérer utile.

Deuxième point : les deux options : "enable check sum" et "verify after backup " permettent de vérifier qu'une sauvegarde est lisible .

Quel est le principe de cette vérification ?

Pour confirmation :

Dans la requete de selection de la vue database_principals
select name , type
from sys.database_principals WHERE
type in ('S', 'U');

Le champ type représente le type d'utilisateur de niveau base de données : pour ce qui est du type S, cela représente un utilisateur SQL avec une connexion SQL , le type U=un utilisateur Sql qui se connecte avec connexion windows .

Pour finir je lis dans un cours d'administartion de BDD Sql Server

Tous les membres du role db_owner Tous les membres de ce groupe vont créer des objets dont le propriétaire est dbo.
Il s’agit du propriétaire par défaut de tous les objets et il n’est pas nécessaire de le préciser pour manipuler ses objets.

Soit un utilisateur SQl Paul, auquel j'octroi le rôle db_owner.
D'après ce que je comprends, Cet utilisateur ne sera pas propriétaires de ses objets .Est ce donc l'utilisateur dbo qui le sera??


Merci beaucoup de votre aide sur tous ces points .

Bien cordialement.

new_wave

[mikedavem]

Bonjour,
Pouvez vous me dire dans quel cas remplacer un jeu de sauvegarde existant peut s'avérer utile.

Je pense que cela est surtout valable pour des anciens médias de sauvegarde comme les cassettes où on devait écraser pour récupérer de la place.
Je trouve que maintenant cela n'a plus tellement de sens de faire cela. Par défaut, SQL Server ajoute un backup au média mais je trouve pas non plus que ce soit une solution idéale pour les raisons suivantes:

• On peut se retrouver à avoir un média de grande très grande taille et le fait d'accumuler les sauvegardes dans un seul média peut engendrer un risque opérationnel si celui-ci venait à être endommager
• Complexité supplémentaire pour la restauration car il faut jouer avec le paramètre WITH FILE = x pour identifier la bonne sauvegarde à restaurer à l'intérieur du média.

La plupart des outils du marché / solutions open source ou scripts DBA que j'ai pu voir utilisent un système d'horodatage qui rend le média unique avec une seule sauvegarde.
Après c'est une question de choix comme et de préférence comme on dit

Deuxième point : les deux options : "enable check sum" et "verify after backup " permettent de vérifier qu'une sauvegarde est lisible .
Quel est le principe de cette vérification ?

C'est un principe amélioré de vérification qui est arrivé avec SQL Server 2008 de mémoire. A la base la processus était basique avec une simple vérification de conformité du média aux spécifications Microsoft Tape Format (MTF).

Avec les options BACKUP WITH CHECKSUM / RESTORE VERIFYONLY WIT CHECKSUM, le checksum de chaque page de données est lu et vérifié depuis ou en écrivant sur le média de sauvegarde. Si un octet change (ex: corruption du média), la commande de backup ou de vérification pourront le détecter et générer une erreur le cas échéant. Cela suppose en prérequis d'avoir activer l'option de vérification CHECKSUM au niveau de la base de données au préalable.

++

[mikedavem]

Bonjour,
Pour confirmation :

Dans la requete de selection de la vue database_principals
select name , type
from sys.database_principals WHERE
type in ('S', 'U');

Le champ type représente le type d'utilisateur de niveau base de données : pour ce qui est du type S, cela représente un utilisateur SQL avec une connexion SQL , le type U=un utilisateur Sql qui se connecte avec connexion windows .

Pour finir je lis dans un cours d'administartion de BDD Sql Server


Soit un utilisateur SQl Paul, auquel j'octroi le rôle db_owner.
D'après ce que je comprends, Cet utilisateur ne sera pas propriétaires de ses objets .Est ce donc l'utilisateur dbo qui le sera??
new_wave

Le propriétaire de l'objet sera le propriétaire du schéma auquel appartient l'objet et pas directement l'utilisateur qui va le créé. C'est le principe de séparation utilisateur / schéma avec SQL Server qui permet une meilleur gestion de la sécurité. On peut transférer les objets dans les schémas, changer les propriétaires de schémas et éventuellement supprimer l'utilisateur qui est à l'origine de création de l'objet sans impact sur le fonctionnement d'une application.

++

[SQLpro]

Soit un utilisateur SQl Paul, auquel j'octroi le rôle db_owner.
D'après ce que je comprends, Cet utilisateur ne sera pas propriétaires de ses objets .Est ce donc l'utilisateur dbo qui le sera??

Pour compléter mike, par rapport à Oracle qui mélange joyeusement les notions d'utilisateur de propriétaire et de schéma SQL, la norme SQL prévoir la séparation de toute ces choses :
1) un propriétaire est forcément un utilisateur SQL (au niveau de la base)
2) un schéma SQL appartient à un propriétaire QUI n'a pas forcément le même nom !
3) un même utilisateur SQL peut être le propriétaire de plusieurs schéma de la base voir de tous les schémas (c'est même souvent le cas...)
4) un utilisateur doté des privilèges adéquats peut créer un objet dans un schéma qui ne lui appartient pas. Autrement dit, USER_A peut être propriétaire de SCHEMA_A et USER_B peut créer une table dans SCHEMA_A...
5) SQL Server étant multibase ET multischéma SQL, ne pas confondre ces deux notions qui sont souvent confondus aussi bien dans oracle que dans MSQmerde....

A +

[new_wave]

Merci encore beaucoup pour tous vos éclairages !!!