performance

Dominique Peralta wrote:

Bonjour Hélios,
si vous voulez vous "payer" Fred Brouard, faites-le en privé. Ici, on ne
cherche pas la bagarre, mais uniquement des renseignements lorsque l'on est
coincé. Depuis 5 ans que je lis ce forum, j'avoue que ces derniers temps, ça
commence à me gonfler.

J'abonde ! Je me suis posé sérieusement la question il y a quelques
temps de filtrer Helios dans mon client, et histoire d'illustrer à quel
point c'est usant en 11 ans de pratique de Usenet c'est la deuxième fois
seulement que je songe à l'usage du bloquage.

Helios donc, soyez gentil d'arrêter, ici on parle de technique.

Pierre Goiffon a écrit :

Dominique Peralta wrote:

Bonjour Hélios,
si vous voulez vous "payer" Fred Brouard, faites-le en privé. Ici, on
ne cherche pas la bagarre, mais uniquement des renseignements lorsque
l'on est coincé. Depuis 5 ans que je lis ce forum, j'avoue que ces
derniers temps, ça commence à me gonfler.

J'abonde ! Je me suis posé sérieusement la question il y a quelques
temps de filtrer Helios dans mon client, et histoire d'illustrer à quel
point c'est usant en 11 ans de pratique de Usenet c'est la deuxième fois
seulement que je songe à l'usage du bloquage.

Helios donc, soyez gentil d'arrêter, ici on parle de technique.

justement quand on parle de technique il faut eliminer les mauvaises
technique si un mec est incapable de coder une date dans un SGBD ce
n'est pas de ma faute je ne fait que relever cela pour justement mettre
en doute la fiabilité de ses interventions

Bonjour
Je pense que le mieux est d'ignorer ce sinistre personnage qui se permet de
critiquer la technique des autres alors que je n'ai jamais vu
d'interventions constructives de sa part.
Hormi le fait de venir proposer ses disques durs en leasing, il n'a pas
grand chose à proposer.

"Pierre Goiffon" <pgoiffon@free.fr.invalid> a écrit dans le message de
news:493e3246$0$25737$426a74cc@news.free.fr...

Dominique Peralta wrote:

Bonjour Hélios,
si vous voulez vous "payer" Fred Brouard, faites-le en privé. Ici, on ne
cherche pas la bagarre, mais uniquement des renseignements lorsque l'on
est coincé. Depuis 5 ans que je lis ce forum, j'avoue que ces derniers
temps, ça commence à me gonfler.

J'abonde ! Je me suis posé sérieusement la question il y a quelques temps
de filtrer Helios dans mon client, et histoire d'illustrer à quel point
c'est usant en 11 ans de pratique de Usenet c'est la deuxième fois
seulement que je songe à l'usage du bloquage.

Helios donc, soyez gentil d'arrêter, ici on parle de technique.

Bonjour amateur de débat ^^
Concernant le hors sujet, quel que soit les "news group" je n'en ai
jamais vu un ou les uns ne se pouillent pas avec les autres. Chacun sa
passion.
Concernant mes petits moutons, nous avons plusieurs bases, car elles
sont séparés car différentes, la même appli, mais pas la même lan gue,
pas les mêmes info. Et le mot Schémas me parlant autant que si on me
parlait chinois, je pense que ca restera ainsi pour l'heure (il est
prévu que je parte en formation SQL d'ici quelques mois, le besoin
etant présent)
J'ai lu votre doc sur la haute dispo, et le mirroring semble préco
pour peu de base. J'en ai 20 et le chiffre aura tendance a gonfler,
donc option a exclure.
Niveau performance, nous avons trouvé notre hic.
Deja le fait de faire un log shipping toute les minutes. J'ai omnis il
semblerait dans mon message initial de dire que j'ai deux serveurs,
chacun avec une dizaine de bases. le serveur un log ship le deux, et
inversement le deux log ship le un. Toutes les minutes donc ils
recoivent et envoient. Il n'en fallait pas plus pour tuer la bête. Et
pour couronner le tout, nous sommes dans une baie SAN avec un gros
probleme d'I/O disque.

Donc prochaine étape : regler notre soucie d'I/O disque. Réactiver le
log ship toute les 15 mns, mais cette fois ci avec un troisieme
serveur qui viendra receptionner.

Ce n'est peut etre pas DBA approuved :) mais on fait avec les moyens
du bord.

@+
T

bonjour,


twingo@ifrance.com a écrit :

Bonjour amateur de débat ^^
Concernant le hors sujet, quel que soit les "news group" je n'en ai
jamais vu un ou les uns ne se pouillent pas avec les autres. Chacun sa
passion.
Concernant mes petits moutons, nous avons plusieurs bases, car elles
sont séparés car différentes, la même appli, mais pas la même langue,
pas les mêmes info. Et le mot Schémas me parlant autant que si on me
parlait chinois, je pense que ca restera ainsi pour l'heure (il est
prévu que je parte en formation SQL d'ici quelques mois, le besoin
etant présent)

Un schéma est une unité logique de placement des objets de la base
(table, procédure, vue). Une base à toujours au moins un schema par
défaut dbo.
Vous pouvez en créer autant que vous voulez à l'aide de CREATE SCHEMA.
Comme vous avez 20 bases et que je suppose qu'elles ne font pas plus de
1 Terra octets de volumes (toutes cumulées), il serait judicieux pour
les performances de créer dans l'un des bases autant de schéma que vous
avez de base (-1) et y reporter tout vos objets.
De ce fait vous n'aurez plus qu'une seule base et cela simplifiera
absolument tout :
1) une seule procédure d'admin pour les sauvegardes, réindexation, etc...
2) des performance notablement améliorées en matière de fichiers de
stockage et de journal (avec 20 bases vous entremêlez la croissance des
fichiers ce qui les fragmentent irrémédiablement au niveau physique).
3) un portage plus simple pour l'avenir : une seule base à migrer, un
seule serveur, une seule licence à payer

J'ai lu votre doc sur la haute dispo, et le mirroring semble préco
pour peu de base.

exact


> J'en ai 20 et le chiffre aura tendance a gonfler,

donc option a exclure.

non, jouer sur les schémas !

Il est facile de migrer n base sur une seule à travers les schmés SQL.
je vous en montre le principe :
1) demander à l'IHM de vous pisser le script de création de tous les
objets de votre base
2) supprimez les GO intempestifs
3) ajouter au début du script les deux commandes suivantes :

USE Mabase;
GO

CREATE SCHEMA XXX --> mettez y le nom de l'ancienne base

4) migrez les données :
INSERT INTO MaBase.MonSchema.MaTable
SELECT * FROM MonAnciennebase.dbo.Matable

5) définissez un nouvel utilisateur SQL avec ce nouveau schéma par
défaut et sa connexion avec les privilèges maximum sur la base.

6) reconnectez vos application avec ce nouvel utilisateur !

Vous n'avez pas à modifier votre application...

Étonnant non ????

Niveau performance, nous avons trouvé notre hic.
Deja le fait de faire un log shipping toute les minutes.

Effectivement le Log Shipping n'est pas fait pour faire du temps réel et
avec 20 bases c'est 80 descripteurs de fichiers ouverts !

Augmentez votre temps de latence à au moins 15 minutes Et plus vous
aurez de bases, plus il faudra allonger ce temps de latence !

J'ai omnis il
semblerait dans mon message initial de dire que j'ai deux serveurs,
chacun avec une dizaine de bases. le serveur un log ship le deux, et
inversement le deux log ship le un. Toutes les minutes donc ils
recoivent et envoient. Il n'en fallait pas plus pour tuer la bête.

De manière générale croiser le log shipping ou le mirroring n'est pas top !

> Et

pour couronner le tout, nous sommes dans une baie SAN avec un gros
probleme d'I/O disque.

La encore il faut avoir des SAN hautement administrable et ne pas faire
n'importe quoi. Définir des LUN qui sont sur des disques physiques et ne
pas utiliser le zonage (c'est à dire pas de partition sur un disque ...).
Il faut que SQL Server ne voient exclusivement que des disques physiques
et non un conglomérat !

En sus il faut tailler tout vos fichiers de données et journal en taille
fixe. par exemple si votre base va faire 10 Go dans 3 ans, alors tailler
votre ficher de données à 10 go de votre JT à 3, sinon les opérations de
croissance génère des pertes significatives de ressources. Faites le
test que je donne dans ce blog :
http://blog.developpez.com/sqlpro?title=fragmentation_physique_des_fichiers_et_t
vous verrez la différences...
En plus sans cela les croissances de fichier s'entrelacent et génère une
fragmentation physique de fichier irrémédiable !

Donc prochaine étape : regler notre soucie d'I/O disque.

c'est comme je vous l'ais indiqué !

Réactiver le
log ship toute les 15 mns, mais cette fois ci avec un troisieme
serveur qui viendra receptionner.

Non, vous devrez peut être passer à 20mn;.. puis 30mn....

Ce n'est peut etre pas DBA approuved :) mais on fait avec les moyens
du bord.

Vous perdez du temps, des ressources et de l'argent ! Soyez réaliste un
DBA c'est au minimum 10 jours de formation + des années de pratique.
Aujourd'hui SQL Server est aussi complexe à administrer que Oracle ou DB2 !

A +

@+
T

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

"helios services" <helios@com02.net> a écrit dans le message de
news:493ae473$0$20040$426a74cc@news.free.fr...

Dominique Peralta a écrit :

"Un serveur RAID5 ou 6 est plus performant" : c'est une information.
"Brouard est égal à lui-même" : c'est du dénigrement, donc, sans intérêt
pour les lecteurs.

"helios services" <helios@com02.net> a écrit dans le message de news:
493a8e7d$0$6051$426a74cc@news.free.fr...

il est donc interdit de pensé que Brouard est égal a lui meme et qu'un
serveur RAID5 ou 6 est plus performant ?

non "égal à lui même" ne peut pas être du dénigrement a moins que "lui
même" soit dévalorisant :-)

il est vrai que je me considérait comme diffamé si on me disait que je
suis égale à lui même :-)

Parce que vous vous sentez supérieur à cette personne, ou que vous vous
sentiriez dévalorisé d'être une femme.
Dans les deux cas vous êtes à côté de l'esprit communautaire des forums.
Cette remarque n'attend pas de réponse, avec vos fils il y a déjà assez à
filtrer ;-(

On 10 déc, 16:54, Fred BROUARD <broua...@club-internet.fr> wrote:

bonjour,

Un schéma est une unité logique de placement des objets de la base
(table, procédure, vue). Une base à toujours au moins un schema par
défaut dbo.
Vous pouvez en créer autant que vous voulez à l'aide de CREATE SCHEMA .
Comme vous avez 20 bases et que je suppose qu'elles ne font pas plus de
1 Terra octets de volumes (toutes cumulées), il serait judicieux pour
les performances de créer dans l'un des bases autant de schéma que vo us
avez de base (-1) et y reporter tout vos objets.
De ce fait vous n'aurez plus qu'une seule base et cela simplifiera
absolument tout :
1) une seule procédure d'admin pour les sauvegardes, réindexation, et c...
2) des performance notablement améliorées en matière de fichiers de
stockage et de journal (avec 20 bases vous entremêlez la croissance des
fichiers ce qui les fragmentent irrémédiablement au niveau physique).
3) un portage plus simple pour l'avenir : une seule base à migrer, un
seule serveur, une seule licence à payer

J'en ai parlé a quelqu'un qui connait bien plus que moi SQL, et voici
sa question :

Si nous modifions cet aspect de schémas, y a t'il un risque que notre
application soit perdu ? Est ce que notre application doit etre
programmé de tel sorte qu'elle comprenne la notion des schémas ? ou
cela n'a aucune incidence (je vais bien entendu poser la question a
notre revendeur applicatif)

> Ce n'est peut etre pas DBA approuved :) mais on fait avec les moyens
> du bord.

Vous perdez du temps, des ressources et de l'argent ! Soyez réaliste un
DBA c'est au minimum 10 jours de formation + des années de pratique.
Aujourd'hui SQL Server est aussi complexe à administrer que Oracle ou D B2 !

A +

Oui dans le meilleur des mondes nous sommes tous certifié, chacun dans
son propre domaine.
Mais dans nombre d'entreprise, la réalité se veut etre multi
casquette, multi tâche, donc moyen du bord.
Et pour les gens comme moi, il y a les forums d'expert :)

Merci pour vos réponses, et votre aide.

@+
T

twingo@ifrance.com a écrit :
...

J'en ai parlé a quelqu'un qui connait bien plus que moi SQL, et voici
sa question :

Si nous modifions cet aspect de schémas, y a t'il un risque que notre
application soit perdu ?

no,, si vous faites biens les choes

Est ce que notre application doit etre
programmé de tel sorte qu'elle comprenne la notion des schémas ?

Non, puisque ce sera le schéma par défaut de l'utilisateur. Mais cela
marchera à condition qu'aucune des requêtes n'ai été faites avec des
objet dont le nom a été préfixé par le schéma dbo (sauf fonction....).

ou
cela n'a aucune incidence (je vais bien entendu poser la question a
notre revendeur applicatif)

En principe aucun.

De toute façon il faut faire un essais !

Ce n'est peut etre pas DBA approuved :) mais on fait avec les moyens
du bord.

Vous perdez du temps, des ressources et de l'argent ! Soyez réaliste un
DBA c'est au minimum 10 jours de formation + des années de pratique.
Aujourd'hui SQL Server est aussi complexe à administrer que Oracle ou DB2 !

A +

Oui dans le meilleur des mondes nous sommes tous certifié, chacun dans
son propre domaine.
Mais dans nombre d'entreprise, la réalité se veut etre multi
casquette, multi tâche, donc moyen du bord.
Et pour les gens comme moi, il y a les forums d'expert :)

mais c'est économiquement pas viable. En effet je viens de vous montrer
comment économiser du serveur et des ressources à tous les niveaux.
préférez vous faire la fuite en avant et rajouter des serveurs, des
licences, de l'admin... qui va vous couter la peau des fesses ou
n'auriez vous pas intérêt çà prendre une ou deux journées de conseil ?

la dernière fois que j'ai fait une journée de conseil de ce genre
c'était à Londres fin auôt et au final la boîte à gagné environ 30 000
euros pour une prestation facturée 2800 € TTC charges comprises (avion,
hotel...)

A +

Merci pour vos réponses, et votre aide.

@+
T

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************

On 11 déc, 16:09, Fred BROUARD <broua...@club-internet.fr> wrote:

De toute façon il faut faire un essais !

nous le ferons.

mais c'est économiquement pas viable. En effet je viens de vous montrer
comment économiser du serveur et des ressources à tous les niveaux.
préférez vous faire la fuite en avant et rajouter des serveurs, des
licences, de l'admin... qui va vous couter la peau des fesses ou
n'auriez vous pas intérêt çà prendre une ou deux journées de co nseil ?

Il n'est pas exclu d'en arriver là. En revanche ca ne sera pas pour
tout de suite.

@+

T

twingo@ifrance.com a écrit :

On 11 déc, 16:09, Fred BROUARD <broua...@club-internet.fr> wrote:

De toute façon il faut faire un essais !

nous le ferons.

mais c'est économiquement pas viable. En effet je viens de vous montrer
comment économiser du serveur et des ressources à tous les niveaux.
préférez vous faire la fuite en avant et rajouter des serveurs, des
licences, de l'admin... qui va vous couter la peau des fesses ou
n'auriez vous pas intérêt çà prendre une ou deux journées de conseil ?

Il n'est pas exclu d'en arriver là. En revanche ca ne sera pas pour
tout de suite.

@+

T

ça tombe bien j'ai peu de dispo avant juillet !!!

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************