Bonjour,
 
Je dispose d'un boitier de stockage NAS. J'ai créé ma base SQL Server en local, et maintenant je souhaite qu'elle soit sur le boitier NAS.  
J'ai trouvé ce lien, disant qu'il est possible d'installer une BD sur un boitier NAS :
http://support.microsoft.com/kb/304261
 
Mais ça ne m'explique pas comment faire. Ca semble traiter uniquement des problèmes rencontrés.
 
Sinon, j'ai aussi lu ce tuto :
http://www.technos-sources.com/tut [...] er-31.aspx
Faut-il que je créé un cluster et des noeuds ? Car je ne trouve pas l'outil d'administration de mon serveur NAS.  
Merci de votre aide, car je suis un peu perdu.

C'est fortement déconseillé de passer par un NAS, sauf matériel spécifié comme compatible et sur un réseau dédié.
 
Pour passer outre, il faut que tu crées ta bdd via un script en activant le flag trace 1807, et en donnant le chemin UNC ou ta base sera stockée.

Merci pour la réponse.  
Et comment savoir si mon NAS est certifié WHQL ? C'est un D-Link DNS-323.
 
Pour le flag trace, c'est lors des create Table que l'on déclare ça ?  
Encore merci.

Si ce n'est pas indiqué dans les specs du matériel (et ce n'est apparemment pas le cas), il ne l'est pas.
 
Tu actives le flag trace soit en utilisant la commande DBCC TRACEON(1807), ou mieux, pour que l'option soit active à chaque redémarrage de ton serveur, dans le enterprise manager, dans les options de démarrage de ton serveur SQL, en rajoutant -T1807 en paramètre de démarrage.

si c'est D_LInk, c'est pas certif
si ça coûte moins de 10k€, c'est pas certif
 
(en gros)

Ok merci, je viens de faire cela à l'instant.
J'ai aussi contacté D-Link pour vérifier, si par chance le routeur est WHQL. S'il ne l'est pas, je pense mettre la BD sur un autre PC.
 
Sinon, voici mes paramètres de démarrage :
 
-T1807;-dC:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\DATA\master.mdf;-eC:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\LOG\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\DATA\mastlog.ldf
Il ne faut pas préciser le chemin juste après -T1807 ?
 
Pour l'UNC, je ne trouve sur Google que des exemples en VBS, ou C#. Est-ce possible de spécifier l'UNC avec une fonction écrite en SQL ?
 
 
 
EDIT :
 

 
 
Ah merci. Dommage. Je vais tester la BD sur le NAS, si ça ne marche pas je basculerai définitivement vers la 2nde solution : utiliser un vieux PC comme serveur.

Une fois que tu as bien activé le flag, tu crées ta database (ou tu l'attaches si tu l'as déja copiée sur ton NAS) avec du SQL tout ce qu'il y a de plus normal, en mettant juste le chemin UNC au lieu du chemin classique.
 
Exemple :
 
CREATE DATABASE test ON
 ( NAME = test_dat,
  FILENAME = '\\DLINK\test.mdf',
  SIZE = 10MB,
  MAXSIZE = 20MB,
  FILEGROWTH = 10MB)
 LOG ON
 ( NAME = test_log,
  FILENAME = '\\DLINK\test.ldf',
  SIZE = 5MB,
  MAXSIZE = 25MB,
  FILEGROWTH = 5MB)
 
Si tu as des soucis de permissions, vérifie bien que le compte sous lequel ton service SQL tourne a les droits d'accès au NAS.

Merci je teste ça tout de suite !
 
Edit : La base est bien créée, on voit bien apparaître le fichier .mdf, même si cela est bien plus long que d'habitude.  
Maintenant, il ne me reste plus qu'à modifier mon projet Java/Jsp en fonction de la nouvelle base, j'ai un petit soucis au niveau de l'URL mais ce n'est pas le bon forum pour en parler. ^^
 
En tout cas merci beaucoup pour ton aide, ccp6128. Bonne journée.
 
Edit 2 : Est-ce normal que mon PC apparaisse comme propriétaire de la base, alors que le fichier mdf se trouve dans le NAS ?

Durant mes diverses expériences diverses, j'ai eu l'occasion à deux reprises de trouver des fichiers vitaux sur des NAS.
 
1/ A l'université, un NAS hébergait... l'OS de deux serveurs Dec Alpha.
=> J'ai jamais vu des serveurs aussi instables et lents de ma vie (l'année précédente, ils n'étaient pas montés avec ce système, et malgré un upgrade, matériel, il étaient clairement à la rue après cette modif)
 
2/ Chez un gros client, un NAS hébergeait les bases de données Oracle de plusieurs serveurs. Vu le client, ses moyens et sa politique informatique, je peux supposer que c'était le genre de NAS où tu peux rentrer tout entier dedans et pas avoir besoin de faire des contorsions pour changer les disques.
=> Ca marchait pas mal en ce qui concerne les performances brutes. Cependant, les temps de réponse étaient très amoindris, sans oublier le problème latant à la mutualisation des ressources : dès qu'une base faisait de la maintenance, c'était tous les serveurs qui étaient idle. En revanche, l'intérêt financier était flagrant : un seul élément du réseau à backuper, et surtout, possibilité d'utiliser des serveurs bas de gamme pour faire des serveurs Oracle en grand nombre (ça changeait des serveurs Sun dédiés pour chaque application).
 
Bref, il en ce qui concerne les serveurs de base de données, je pense qu'un NAS n'est pas forcément une bonne chose, où alors il doit être dédié à un seul serveur, et un réseau dédié doit être utilisé entre le NAS et le serveur (et pas un simple switch manageable qui fait du partitionnement).
 
Sinon, ben oui, ça me semble logique que ton serveur soit le propriétaire de la base sur le NAS. Et j'espère bien même ! Il est impensable qu'un autre serveur vienne bidouiller dans la base en même temps que ton serveur !

Merci beaucoup pour ces précisions.  
Dommage donc. Le NAS apparaît vraiment comme inutile dans mon cas.  
Néanmoins, vous n'auriez pas une idée pour que le serveur NAS ne soit pas totalement inutile ?  
Je vais déjà y mettre des documents Word générés par mon programme.
 
Mais si je met par exemple les fichiers .MDF dans ce NAS, et que j'installe SQL Server chez chacun des utilisateurs afin qu'ils aient un moteur SQL Server, est-ce possible que ces utilisateurs puissent manipuler la BD ?

 
Non, surtout pas. Tu ne peux pas attaquer le fichier mdf en direct à partir de plusieurs moteurs.

Arf, le NAS me sera inutile jusqu'au bout, pour la base de données, alors.
 
Dans ce cas, je ne comprends pas pourquoi dans le lien Microsoft, il est dit qu'on peut héberger une BD SQL Server sur un NAS (même s'il est vrai que le mien n'est pas WHQL).
http://support.microsoft.com/kb/304261/fr
 
C'est seulement valable pour une BD accessbile d'un seul poste ?

On peut. Mais ça ne rend pas pour autant tes fichiers "magiques". Ca te donne juste des possibilités de backup centralisé ou de reprise rapide en cas de problème matériel sur le serveur qui s'en sert.
 
Quand des users ont besoin d'accéder a des données issues d'une bdd, on utilise une appli qui va interroger le serveur de base de données, on n'installe pas sur chaque poste un moteur SQL qui va taper dans les fichiers de la base.

Ah ok merci.
Donc si je comprend bien, les fichiers MDF étant sur le NAS, je n'aurais besoin que d'une application pour interroger ces fichiers ? Et ce genre d'application permettrait que plusieurs personnes à la fois interrogent ces fichiers ?

Tu fais une confusion entre les fichiers de la base et le serveur de base de données.
 
Alors, en très simplifié (je suis pas non plus un expert dans le domaine, disons juste un utilisateur assez régulier de SQL server), le composant moteur dans un serveur de base de données, c'est le moteur.
 
Le moteur stocke les informations dans les fichiers de base de données, et peut les transmettre aux applis qui en ont besoin via le réseau, en passant pas un processus qui s'apelle le listener et qui permet la communication.
 
 
Le schéma classique c'est requête client -> listener -> moteur qui traite la requête du client et renvoie la réponse.
 
Le moteur est garant de l'intégrité des fichiers de base de données, et il n'est pas question de toucher à ces fichiers pendant qu'il fonctionne.
 
Si tu as un serveur SQL, qui stocke ses fichiers sur un disque réseau, le client ne va pas interroger le disque réseau, mais le moteur qui se trouve sur le serveur SQL.
 
Le NAS est juste la pour stocker ailleurs les fichiers, par exemple pour une problèmatique de sauvegarde, ou d'espace disponible.

Ah et bien merci beaucoup, tout s'éclaire pour moi. Le NAS ne servira donc qu'à stocker les fichiers de BD, mais il faudra en plus un serveur qui tourne en permanence.  
Et encore, sachant que le NAS héberge les fichiers, le temps d'accès risque d'être plus long.  
 
En tout cas merci beaucoup, j'aurais beaucoup appris, ça me permettra de ne plus refaire les mêmes erreurs plus tard. ^^

défaut de formation ou erreur de casting à l'embauche ? oO
 
j'ai failli m'étrangler en lisant le topic

C'est pas la première fois que je réponds à un tel topic.
 
Avec ce genre de NAS un peu hybrides SOHO/PME, sous Linux, il devient difficile de différencier le rôle d'un serveur de celui d'un NAS, surtout qu'il est possible d'installer pas mal d'extensions dessus (c'est du Linux qui tourne, donc installer du Apache ou du MySQL est tout à fait faisable).

faisable oui, de là à dire que c'est intelligent c'est une autre histoire
 
mais c'est surtout le fait d'installer N moteurs sql server qui m'a un peu fait peur, je dois l'avouer

Tout à fait d'accord.
 
Sur le coup, ca m'a furieusement fait penser à la vision made in access, le genre de trucs où on te présente sur le papier la super appli réseau qui tape sur une bdd, et qui se résume en fait à un fichier vaguement partagé. Ca n'aide pas trop à se représenter mentalement comment marche un vrai SGBD.

c'est totalement ça
 
et je trouve que le niveau moyen de culture sgbd se dégrade à une vitesse phénoménale, tout le monde veut faire tout et n'importe quoi n'importe comment, mais surtout ne pas y mettre les moyens parce que "pour un truc de stockage ça coute quand même vachement cher"

c'est le souci d'un NAS :
- d'un côté, tu as un RAID et des disques 100% dédiés à tes fichiers (donc rapidité sans faille, cache disque énorme, etc.)
- de l'autre, t'as le problème de la latence réseau qui vient s'ajouter à la latence des accès disques
- aujourd'hui, à moins d'avoir une connecion 10Gbits entre le NAS et le serveur, le débit soutenu du NAS sera forcément inférieur à de la connectique interne, même si tu passes par un sous-réseau dédié.
 
sans oublier le risque infiniment plus important de déterrioration/coupure du signal réseau par rapport à une nappe SCSI ou SATA
 
en revanche, l'intérêt principal du NAS, c'est que lorsque tu as une multitude de bases de données, plutôt que d'investir dans de nombreux serveurs honéreux, tu investi dans un NAS très honéreux qui tiendra tout à fait la charge, et tu n'as ensuite qu'à le connecter à des petits serveurs bas de game qui seront dédiés pour chaque base. quand on a le choix entre 10 serveurs mutialisés Sun ou 1 NAS + 30 serveurs Dell PowerEdge, le choix est rapide.
 
un NAS, par essence, ça ne prend son utilité que dans de grosses architectures, ou alors il va fortement être sous-utilisé (serveur de partage de fichiers/backup par exemple)
 
pour en revenir à ce qu'à dit cpc6128 (sans la faute ) un seul moteur de base de données ne peut accéder à un même fichier en même temps (et dans l'absolu, personne d'autre que le moteur de base de données ne dois jamais accéder au fichier MDF).
 
et c'est ensuite le serveur bdd qui répond aux requêtes, c'est donc le seul qui doit être exposé aux autres ordinateursdu réseau, le NAS dans le cas d'un hébergement de bases de données, doit au contraire être impérativement sur un réseau séparé : les serveurs de sgbd ont chacun deux cartes réseau, une pour le réseau global, et une pour le NAS et uniquement le NAS.
 
dans le cadre d'un déploiement de mirroring de serveur, il est éventuellement possible de faire basculer un serveur shadow sur les fichiers d'un autre serveur, mais dans l'unique condition que ce premier est tombé : en cas de panne du serveur bas de gamme, un second serveur prend immédiatement le relais sur le même fichier de données, et donc la rupture de service n'est assortie que de faibles conséquences et résolue en quelques minutes/secondes.
 
au final, j'en reviens quand même au NAS : le gros problème d'avoir un système de fichier sur le réseau, c'est... le réseau. par essence, un fichier de base de données se doit d'être dans un état parfaitement intègre à tout moment. c'est à dire que si en plein milieu d'un énorme travail on débranche physiquement le disque (panne de courant, crash subit de l'os, etc.), tout problème de filesystem mis à part, le fichier doit être immédiatement réutilisable tel quel. les latences, pertes et parasites induits par un réseau ne font que compromettre ce point vital d'un sgbd.

sauf que pour moi ca sert à stocker des fichiers basiques, pas des bases de données
 
sûr que ca marche, cela dit ... comme ca peut

c clair que moi j'ai toujours vu ça à la base comme un bon gros serveur de fichier de base.
 
mais dans une optique de mutualisation des ressources, ça peut prendre son sens : entre plusieurs serveurs avec une chaîne RAID 10 chacun qui :
1/ est lente
2/ sur une carte contrôleur pourrie
3/ bouffe 50% de la place
 
tu prends un NAS avec une bonne grosse chaine en RAID 50 qui :
1/ est infiniment plus rapide
2/ sur du vrai matos qui sait traîter un Go/s et avec un vrai cache matériel
3/ bouffe moins de 10% de la place
 
pour un prix qui va rapidement devenir inférieur si l'absence de contrôleur disque honéreux dans les serveurs applicatifs permet de baisser considérablement leur prix.
 
en dehors de ça, comme toi, pour moi c'était uniquement pour stocker des fichiers ou à la limite les fichiers d'un serveur de mail (mais faut déjà en avoir l'utilité)
 
-- edit : pfiou il est tard, je sais plus écrire

à la limite en admettant que dans un tel cas le réseau soit dédié, qu'on omette la surcouche induite par l'OS du NAS, qu'on suppose que la config disque est bien foutue, qu'on ait pas pris des disques moisis, qu'on supporte la perte de l'accès de bas niveau au disque par l'OS interne de SQL Server, qu'on néglige la gestion de la sécurité pour l'accès via le réseau ...
 
bref, on a rien compris, on veut pas de perfs, donc pourquoi pas

j'oubliais un dernier souci inhérant aux NAS : pas de drivers ni console d'admin sur le NAS, généralement un admin qui fini pas son boulot et ne monitore pas le NAS.
 
résultat, notre admin réseau est allé il y a 15 jours chez un hébergeur de serveur pour backuper un NAS.
 
il se connecte en R232 sur le NAS, installe l'outil qui permet de l'administrer (et le sortir du réseau pour faire une image bit par bit du NAS sans risques de modifications des fichiers) et il se prend deux alertes : sur un RAID 10 de 6 disques, 2 disques étaient morts... un de plus et proutch 2 chances sur 3 que toute la base de production du client était morte.
 
avec des disques directement dans le serveur, tu ne vas pas tarder à être noyé sous les alertes, ce qui aide bien à éviter ce genre de pépins