Discussion :

[Népomucène]

Maintenant que tu le dis, la différence entre le mode simple et complet me semble plus claire.

J'avais fait un essai de plan de sauvegarde différentielle pour avoir une sauvegarde toute les heures.
(chez un autre client, cela avait bien marché car la base était peu sollicitée)
Là, la génération de plans de production provoque l'ajout de paquets de 200.000 lignes (BULK INSERT par un serveur secondaire de préparation)
La sauvegarde différentielle a tout de suite mis le serveur à genou. Problème de puissance de ce serveur, je suppose.
Du coup, on se contente d'une sauvegarde par jour.

Avec le nouveau serveur, et tes explications, je pense pouvoir faire des sauvegardes complètes 2 fois par jour
et donc de passer en mode de récupération simple et bannir à jamais le BACKUP LOG WITH TRUNCATE_ONLY

[SQLpro]

Bien entendu. J'ai toujours considéré que c'était une bidouille.

ça l'est d'autant plus que ce n'est plus supporté depuis la version 2008 (de tête)

Extrait de l'aide en ligne de microsoft :
"
Les options BACKUP LOG WITH NO_LOG et WITH TRUNCATE_ONLY ont été supprimées. Si vous utilisez le mode de récupération complète ou le mode de récupération utilisant les journaux de transactions et si vous devez supprimer la chaîne de sauvegarde de fichier journal d'une base de données, passez au mode de récupération simple. Pour plus d'informations, consultez Afficher ou modifier le mode de récupération d'une base de données (SQL Server).
"

C'est d'autant plus normal que cela ait été supprimé que c'était parfaitement débile de forcer son journal à enregistrer des informations inutile afin de s'obliger à les supprimer !

A +

[Népomucène]

c'était parfaitement débile de forcer son journal à enregistrer des informations inutile afin de s'obliger à les supprimer !

Je plussoie.

Je suppose que si ce faux BACKUP n'avait pas existé alors cela m'aurait amené à faire plus de recherches sur les modes.

Il est regrettable que la doc de SQL2000 (papier à l'époque) n'était pas très pédagogique pour les développeurs "full-stack" dans mon genre où on fait (presque) tout dans des petites structures.
Quand je suis tombé sur ce "TRUNCATE_ONLY", bien qu'assez étrange, je n'y ai pas vu malice puisque c'était dans le code officiel du Transaq-SQL !

Bon, c'est promis, je ne l'utiliserai plus.

Autre question toujours en suspend :
La configuration actuelle est de 3 serveurs SQL2000 reliés entre eux par le système de "serveur attaché"
Comme SQL2016 ne daigne pas communiquer avec SQL2000, j'envisage de tout rassembler sur la même machine.
Je tiens tout de même à la séparation des tâches.
Dans ce cas, est-il plus judicieux de :
- Créer 3 instances différentes de SQL Server sur le serveur Windows
- Créer 3 serveurs virtuels Windows (sur la même machine) ayant chacun leur serveur.

[SQLpro]

Autre question toujours en suspend :
La configuration actuelle est de 3 serveurs SQL2000 reliés entre eux par le système de "serveur attaché"
Comme SQL2016 ne daigne pas communiquer avec SQL2000, j'envisage de tout rassembler sur la même machine.
Je tiens tout de même à la séparation des tâches.
Dans ce cas, est-il plus judicieux de :
- Créer 3 instances différentes de SQL Server sur le serveur Windows
- Créer 3 serveurs virtuels Windows (sur la même machine) ayant chacun leur serveur.

Ni l'une ni l'autre n'est une bonne solution. La meilleure solution reste d'avoir un serveur physique par instance SQL Server.

Maintenant si tu nous expliquais à quoi servent tes instances et quelle sollicitation elles ont (la charge) on pourrait peut être te répondre sur la moins mauvaise des solutions si tu ne veut pas mettre 3 serveurs physiques.

A +

[Bernardos]

en ce qui me concerne, je trouve que tous les développeurs devraient avoir un minimum de formation de dba et que dans tous les projets et toutes les équipes, il faut l'intervention régulière d'un dba pour valider un certains nombres de points, de requetes, de configurations...

Autre question toujours en suspend :
La configuration actuelle est de 3 serveurs SQL2000 reliés entre eux par le système de "serveur attaché"
Comme SQL2016 ne daigne pas communiquer avec SQL2000, j'envisage de tout rassembler sur la même machine.
Je tiens tout de même à la séparation des tâches.
Dans ce cas, est-il plus judicieux de :
- Créer 3 instances différentes de SQL Server sur le serveur Windows
- Créer 3 serveurs virtuels Windows (sur la même machine) ayant chacun leur serveur.

une certitude : il faut abandonner tes serveurs 2000.
ton serveur SQL2016, c'est quoi ? du physique? du virtuel? quelle est la configuration?
Moi perso, je ne suis absolument pas chaud pour la virtualisation des serveurs hébergeant du sql server.
A choisir, je préfère la solution de 3 instances sur un serveur physique(pour autant que les data et log soient sur des disques séparés) mais la meilleur solution reste 3 serveurs physiques avec chacun une instance et chacune une base...
Cordialement,

[Bernardos]

oops,
j'ai fait une double réponse. j'étais en train de rédiger quand une casserole sur le feu a sonné à la porte
enfin je fais 1000 trucs en même temps
Ceci dit sans se concerter, on dit la même chose.

Entre parenthèses, je remarque que chez mes clients qui ont du budget, l'énorme tendance est de se commander un serveur physique super puissant, avec plein de ram et plein de cpu. ensuite, on y claque 6 ou 7 instances (oui oui je l'ai vu de mes yeux vu) dont certaines comportant un grand nombre de petites bases... et pire comme on a besoin de disques supplémentaire, on crée des disques dans des baies non dédiées avec des sytèmes de lun et autre abomination...
Alors que acheter 3,4 serveurs plus modestes auraient été beaucoup plus pertinent.


je ne sais pas si il y a du changement au niveau de sql server 2016 à ce niveau là, mais pour les versions précédentes de sql server , il faut bien penser à formater les disques avec une taille de secteur de 64 Ko.

Maintenant si tu nous expliquais à quoi servent tes instances et quelle sollicitation elles ont (la charge) on pourrait peut être te répondre sur la moins mauvaise des solutions si tu ne veut pas mettre 3 serveurs physiques.

Je plussoie , il est hyper important d'analyser et de comprendre ses besoins. c'est en fonction de cela, que les choix vont être guidés...
Si tu as une instance de dev peu solicitée, je ne tiendrai pas le même discours qu'une instance de prod hyper solicitée avec énormément d'insert, d'update, de delete et de select simultané.
Dans ta description de tes 3 instances, dis nous également combien de bases tu as (plus évidemment la charge pour chacune d'elle)
Cordialement,

[Népomucène]

Je vous réponds très bientôt sur les besoins. Je dois finir en urgence un boulot sur MSACCESS (interdiction de rigoler !)
Quand je vous dis que je fais presque tout ...

[SQLpro]

... Je dois finir en urgence un boulot sur MSACCESS (interdiction de rigoler !)...

Condoléances....

A +

[aieeeuuuuu]

Je dois finir en urgence un boulot sur MSACCESS (interdiction de rigoler !)

Et pleurer, par compassion, on peut ?

Ce qui vous a amené à avoir trois serveurs, c'est visiblement pour que des taches assez lourdes n'impactent pas la production.
Alors, une autre évolution depuis 2000, c'est le gouverneur de ressources, qui pourra limiter (en temps réel, selon la charge du serveur) les ressources allouées pour la "lourde tache" si les besoins de la production sont importants afin que cette dernière ne soit (presque) pas impactée.

ça pourrait être bien utile dans votre cas.

[Népomucène]

Je vous remercie tous de vos messages de soutien (un tantinet ironiques) sur mes tâches urgentes en Access.
Inutile de rappeler que l'existence de ce type d'outil permet de résoudre le besoin simple d'un client à budget/temps très limité.

c'est visiblement pour que des taches assez lourdes n'impactent pas la production

C'est exactement cela. Dès que je suis sorti d'Access, j'en dirai plus long,
et je regarde aussi ce "Resource Governor"

[Népomucène]

Me revoilà.

Comme vous l'avez deviné, je reçois des "plans de production" en provenance de systèmes extérieurs.
Un plan de production est un fichier plat de taille variable entre 50.000 Ko et 1/2 Go en fonction de la quantité à produire.
Il faut intégrer ce plan et surtout le "retravailler" pour calculer l’ordonnancement de la production dans l'usine.

L'intégration se fait en une fois avec un BULK INSERT.
Au début la tâche était placée sur le serveur principal. Celui-ci est connecté à plusieurs dizaines de postes qui enregistrent l'avancement de la production.
Il a fallu déplacer cette tâche sur un petit serveur car elle ralentissait énormément le serveur.

Actuellement, le petit server intègre le plan de production et calcule l’ordonnancement (des centaines de lignes de Transaq sql)
Quand c'est prêt, il l'injecte sur le serveur de principal par paquet de 5.000 lignes.
Je fais un WAITFOR '00:00:03' entre chaque INSERT pour laisser la priorité aux autres tâches sur le serveur principal.

En ce moment, je suis plutôt d'avis de conserver ce système. Il faut que j'arrive à convaincre le client de mettre des sous dans un petit serveur de préparation.

Je garde sous le coude l'idée du "Resource Governor" que je n'ai pas encore eu le temps de tester.

Voilà voilà ...

[Bernardos]

L'intégration se fait en une fois avec un BULK INSERT.

que te donnes ce script?

Code :

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

1
2
3
4
5
6
7
8
9
SELECT name,
       object_schema_name(parent_object_id)+ '.' + object_name(parent_object_id) ,
       type_desc, 
       is_disabled, 
         is_not_trusted, 
         ' ALTER TABLE ' + object_schema_name(parent_object_id)+ '.' + object_name(parent_object_id) + ' WITH CHECK CHECK CONSTRAINT ' + name as 'Requête pour vérifier la contrainte'
FROM sys.foreign_keys
where is_not_trusted = 1 
order by object_schema_name(parent_object_id),object_name(parent_object_id)

il est fort à parier qu'il te rende un résultat. ce qui veut dire que ton bulk insert désactive les contraintes avant de faire son chargement puis les réactive. sauf que, comme les contraintes n'ont pas été vérifiées pendant le chargement, il se pourrait qu'il y aient des incohérences. pour se prémunir de cela, Sql server met la propriété is_untrusted à 1. il "suffit" de refaire un controles des contraintes pour que tout rentre dans l'ordre(pour autant qu'il n'y ait pas d'incohérence du au chargement)

revenons maintenant au fond de la problématique.
ton serveur 2016, c'est du physique? quelles sont les caractériqtiques(cpu, ram, disques, ...)

Quant à ton architecture actuelle, tu as 3 serveurs.
Donc pareillement, décrit nous leurs caractéristiques et en plus dis nous ce qu'ils font et ce qu'ils ont comme instances et bases.
celui que tu appelles ton "petit serveur" a t il une base exactement identique au "grand serveur " ?
Les chargement se font ils à des moment bien déterminé ou de manière aléatoire?
Cordialement,

[Népomucène]

il est fort à parier qu'il te rende un résultat. ce qui veut dire que ton bulk insert désactive les contraintes avant de faire son chargement puis les réactive. sauf que, comme les contraintes n'ont pas été vérifiées pendant le chargement, il se pourrait qu'il y aient des incohérences. pour se prémunir de cela, Sql server met la propriété is_untrusted à 1. il "suffit" de refaire un controles des contraintes pour que tout rentre dans l'ordre(pour autant qu'il n'y ait pas d'incohérence du au chargement)

Je te remercie de ton script mais il ne fonctionne pas en SQL2000 (la migration n'est pas faite)
Par ailleurs, je ne travaille que sur des tables qu'on pourrait qualifier de temporaires :
avant chaque importation de plan de production, toutes les tables de travail sont remises à zéro (TRUNCATE TABLE)
Les données sont analysées d'un point de vue métier par des procédures stockées.
Je n'ai jamais eu d'incohérence.

Mon problème est dans la charge de travail du "petit serveur".

celui que tu appelles ton "petit serveur" a t il une base exactement identique au "grand serveur " ?

non pas du tout. Il ne sert qu'à calculer l'ordonnancement de la production.
Une fois l'ordonnancement calculé, il est envoyé au serveur de production.
Aucune donnée n'est conservée sur le "petit serveur".

ton serveur 2016, c'est du physique? quelles sont les caractériqtiques(cpu, ram, disques, ...)

Ce sera un serveur physique mais je n'ai pas ses caractéristiques puisqu'il n'est pas encore acheté (on attend les devis).

[Népomucène]

Me revoilà sur mon problème n°2 de serveur lié.

Finalement, j'ai réussi à connecter dans les deux sens le SQL2016 au SQL2000 en utilisant une connexion ODBC.
1) Sur le SQL2016
- je suis allé dans source de données ODBC 64 bits et j'ai créé une DSN système avec le pilote "SQL Server" 6.03.9600.17415 que j'ai nommé "SQL2000"
- j'ai créé un serveur lié avec :

type de serveur "Autre source de données"
Fournisseur : "Microsoft OLE DB Provider for ODBC Drivers"
Nom de produit : SQL2000
Source de données : SQL2000

2) Sur le SQL2000
- je suis allé dans source de données ODBC et j'ai créé une DSN système avec le pilote "SQL Server" 2000.86.39.59.00 que j'ai nommé "SQL2016"
- j'ai créé un serveur lié avec :

type de serveur "Autre source de données"
Fournisseur : "Microsoft OLE DB Provider for ODBC Drivers"
Nom de produit : SQL2016
Source de données : SQL2016

Et là, les deux serveurs veulent bien se parler avec des requêtes type : SELECT * FROM SQL2016.MaBase.dbo.Matable

Je continue mes tests ...
Si je peux me passer de remplacer les "petits" serveurs SQL2000, ce serait un gros avantage immédiat ; même si je vais pousser à la migration de l'ensemble des serveurs vers SQL2016.

[Bernardos]

Finalement, j'ai réussi à connecter dans les deux sens le SQL2016 au SQL2000 en utilisant une connexion ODBC.

Je suis content pour toi mais le jeu en vaut il la chandelle? Je m'explique, d'une part tu as consacré pas mal de temps et d'énergie (enfin je pense) à configurer cette architecture, d'autre part , le fruit de ton travail est une architecture dont 2 briques peuvent s'écrouler à tout moment.

Si je peux me passer de remplacer les "petits" serveurs SQL2000, ce serait un gros avantage immédiat

Si cela peut dépanner dans une situation d'urgence(très immédiat) oui. après, l'action suivante doit être la migration vers 2016.

; même si je vais pousser à la migration de l'ensemble des serveurs vers SQL2016.

pour moi c'est la seule solution viable à court terme.
Sur une échelle de 1 à 10, quel est l'impact (négatif) qu'aurait un plantage définitif d'un de tes petits serveurs 2000 (voir les 2) ? Comme on est dans de la production industrielle(si j'ai bien suivi), l'impact le plus parlant est l'impact financier.

Cordialement,

[Népomucène]

pour moi c'est la seule solution viable à court terme

Si d'un coup de baguette magique j'avais pu faire que le client achète directement 3 serveurs SQL2016 ce topic n'existerait pas.
Donc j'essaye de faire avec les moyens du bord ... c'est à dire SANS moyen.

Entre-temps, je suis tombé sur un nouvel os : le SQL2000 arrive à faire des requêtes sur le SQL2016 mais n'arrive pas à exécuter des procédures stockées.
Pourtant dans les propriétés du serveur lié SQL2016 j'ai bien coché "RPC" et le SQL2016 est bien configuré pour accepter les connexions distantes et les 'remote proc trans'

[Népomucène]

Entre-temps, je suis tombé sur un nouvel os : le SQL2000 arrive à faire des requêtes sur le SQL2016 mais n'arrive pas à exécuter des procédures stockées.
Pourtant dans les propriétés du serveur lié SQL2016 j'ai bien coché "RPC" et le SQL2016 est bien configuré pour accepter les connexions distantes et les 'remote proc trans'

Quelle andouille ! Il fallait aussi cocher la propriété "RPC out"
Il faut dire que, dans la boîte de dialogue d'Enterprise Manager, "RPC out" est traduit par "Sans RPC"
Ce n'est pas très heureux comme traduc !

[Invité]

Ce n'est pas très heureux comme traduc !

C'est pour ça que j'installe toujours le SSMS en anglais... C'est souvent la galère sinon entre la doc et l'interface française.

[Népomucène]

Eh oui, je suis bien d'accord. Même avec un gros éditeur (Microsoft) on n'est jamais à l'abri d'une traduction approximative.
J'aurai aussi du regarder la doc du code Transaq-SQL de l'ajout d'un serveur lié (forcément international donc).

Un autre avantage d'avoir l'interface en anglais est qu'on a beaucoup plus de réponses dans les recherches internet.
Quand j'ai cherché le "Sans RPC", je n'ai rien eu du tout !!!