bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
Il me semble qu'il y a un nouvel outil sous w2003 qui permet de faire de
répartition de charge par processus (cad limité un process à xx % de cpu)
c'est Ressource Manager, je ne sais pas s'il est livré de base ou avec le
Reskit.
Combiné avec la gestion de la mémoire de SQLserver, il est possible de
isoler les instances que sous w2000.
Cdlt
"mb" a écrit dans le message de
news:
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
Il me semble qu'il y a un nouvel outil sous w2003 qui permet de faire de
répartition de charge par processus (cad limité un process à xx % de cpu)
c'est Ressource Manager, je ne sais pas s'il est livré de base ou avec le
Reskit.
Combiné avec la gestion de la mémoire de SQLserver, il est possible de
isoler les instances que sous w2000.
Cdlt
"mb" <mb@isped.fr> a écrit dans le message de
news:ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl...
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
Il me semble qu'il y a un nouvel outil sous w2003 qui permet de faire de
répartition de charge par processus (cad limité un process à xx % de cpu)
c'est Ressource Manager, je ne sais pas s'il est livré de base ou avec le
Reskit.
Combiné avec la gestion de la mémoire de SQLserver, il est possible de
isoler les instances que sous w2000.
Cdlt
"mb" a écrit dans le message de
news:
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
bonjour
Nous allons installer un sql server 2000 standard édition sur windows 2003
et sur un serveur dell bi pro xéon avec 4 Go de ram.
Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
Est-ce une bonne idée de faire 2 instances ?
Une instance Développeurs à 1.5 Go et une instance Production 2 Go et 500
Mo pour le Système
Quelles sont les avantages et les inconvénients ?
Est-ce que si un Développeur boucle sur un programme sur l'instance
Développeurs, ceci peut -il avoir une influence sur l'autre instance
Production
Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
un bloc de 3.5 Go ?
Merci pour vos conseils
A mon avis, il faut toujours séparer la production et le développement.
Même si l'isolement SQL Server était parfait, bien d'autres facteurs
jouer. Par exemple si tu veux installer un outil de développement, un
service pack, faire une trace, définir une sécurité fine au niveau réseau
etc, etc...le fait d'avoir production et développement sur le même serveur
sera gênant...
Patrice
--
"mb" a écrit dans le message de
news:
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
A mon avis, il faut toujours séparer la production et le développement.
Même si l'isolement SQL Server était parfait, bien d'autres facteurs
jouer. Par exemple si tu veux installer un outil de développement, un
service pack, faire une trace, définir une sécurité fine au niveau réseau
etc, etc...le fait d'avoir production et développement sur le même serveur
sera gênant...
Patrice
--
"mb" <mb@isped.fr> a écrit dans le message de
news:ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl...
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
A mon avis, il faut toujours séparer la production et le développement.
Même si l'isolement SQL Server était parfait, bien d'autres facteurs
jouer. Par exemple si tu veux installer un outil de développement, un
service pack, faire une trace, définir une sécurité fine au niveau réseau
etc, etc...le fait d'avoir production et développement sur le même serveur
sera gênant...
Patrice
--
"mb" a écrit dans le message de
news:
> bonjour
>
> Nous allons installer un sql server 2000 standard édition sur windows
> et sur un serveur dell bi pro xéon avec 4 Go de ram.
>
> Il semble que sql server 2000 standard édition est bridé à 2 Go de ram.
>
> Est-ce une bonne idée de faire 2 instances ?
>
> Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
> Mo pour le Système
>
> Quelles sont les avantages et les inconvénients ?
>
> Est-ce que si un Développeur boucle sur un programme sur l'instance
> Développeurs, ceci peut -il avoir une influence sur l'autre instance
> Production
>
> Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
gérer
> un bloc de 3.5 Go ?
>
> Merci pour vos conseils
>
>
>
>
Je viens d'installer sur un serveur w2003 sql2000 de test le sp3 sur une
instance pas de reboot pas d'influence sur l'autre instance
par contre le pipe passe par le même tuyau
"Patrice Scribe" a écrit dans le message de
news:
> A mon avis, il faut toujours séparer la production et le développement.
>
> Même si l'isolement SQL Server était parfait, bien d'autres facteurs
peuvent
> jouer. Par exemple si tu veux installer un outil de développement, un
> service pack, faire une trace, définir une sécurité fine au niveau
> etc, etc...le fait d'avoir production et développement sur le même
> sera gênant...
>
> Patrice
>
> --
>
> "mb" a écrit dans le message de
> news:
> > bonjour
> >
> > Nous allons installer un sql server 2000 standard édition sur windows
2003
> > et sur un serveur dell bi pro xéon avec 4 Go de ram.
> >
> > Il semble que sql server 2000 standard édition est bridé à 2 Go de
> >
> > Est-ce une bonne idée de faire 2 instances ?
> >
> > Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
500
> > Mo pour le Système
> >
> > Quelles sont les avantages et les inconvénients ?
> >
> > Est-ce que si un Développeur boucle sur un programme sur l'instance
> > Développeurs, ceci peut -il avoir une influence sur l'autre instance
> > Production
> >
> > Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
> gérer
> > un bloc de 3.5 Go ?
> >
> > Merci pour vos conseils
> >
> >
> >
> >
>
Je viens d'installer sur un serveur w2003 sql2000 de test le sp3 sur une
instance pas de reboot pas d'influence sur l'autre instance
par contre le pipe passe par le même tuyau
"Patrice Scribe" <scribe@chez.com> a écrit dans le message de
news:uZrecV0jDHA.1656@tk2msftngp13.phx.gbl...
> A mon avis, il faut toujours séparer la production et le développement.
>
> Même si l'isolement SQL Server était parfait, bien d'autres facteurs
peuvent
> jouer. Par exemple si tu veux installer un outil de développement, un
> service pack, faire une trace, définir une sécurité fine au niveau
> etc, etc...le fait d'avoir production et développement sur le même
> sera gênant...
>
> Patrice
>
> --
>
> "mb" <mb@isped.fr> a écrit dans le message de
> news:ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl...
> > bonjour
> >
> > Nous allons installer un sql server 2000 standard édition sur windows
2003
> > et sur un serveur dell bi pro xéon avec 4 Go de ram.
> >
> > Il semble que sql server 2000 standard édition est bridé à 2 Go de
> >
> > Est-ce une bonne idée de faire 2 instances ?
> >
> > Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
500
> > Mo pour le Système
> >
> > Quelles sont les avantages et les inconvénients ?
> >
> > Est-ce que si un Développeur boucle sur un programme sur l'instance
> > Développeurs, ceci peut -il avoir une influence sur l'autre instance
> > Production
> >
> > Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
> gérer
> > un bloc de 3.5 Go ?
> >
> > Merci pour vos conseils
> >
> >
> >
> >
>
Je viens d'installer sur un serveur w2003 sql2000 de test le sp3 sur une
instance pas de reboot pas d'influence sur l'autre instance
par contre le pipe passe par le même tuyau
"Patrice Scribe" a écrit dans le message de
news:
> A mon avis, il faut toujours séparer la production et le développement.
>
> Même si l'isolement SQL Server était parfait, bien d'autres facteurs
peuvent
> jouer. Par exemple si tu veux installer un outil de développement, un
> service pack, faire une trace, définir une sécurité fine au niveau
> etc, etc...le fait d'avoir production et développement sur le même
> sera gênant...
>
> Patrice
>
> --
>
> "mb" a écrit dans le message de
> news:
> > bonjour
> >
> > Nous allons installer un sql server 2000 standard édition sur windows
2003
> > et sur un serveur dell bi pro xéon avec 4 Go de ram.
> >
> > Il semble que sql server 2000 standard édition est bridé à 2 Go de
> >
> > Est-ce une bonne idée de faire 2 instances ?
> >
> > Une instance Développeurs à 1.5 Go et une instance Production 2 Go et
500
> > Mo pour le Système
> >
> > Quelles sont les avantages et les inconvénients ?
> >
> > Est-ce que si un Développeur boucle sur un programme sur l'instance
> > Développeurs, ceci peut -il avoir une influence sur l'autre instance
> > Production
> >
> > Est-ce qu'il vaut mieux passer à la version supérieur de SQL 2000 pour
> gérer
> > un bloc de 3.5 Go ?
> >
> > Merci pour vos conseils
> >
> >
> >
> >
>
From: "Patrice Scribe"
References:
Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? >Date: Mon, 13 Oct 2003 18:54:10 +0200
Intéressant, chaque instance de SQL Server te retourne une valeur
de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien comment
cela peut marcher.
Sur le plan du principe, une machine de développement et de production ne
répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
risque supplémentaire sur la disponibilité de la production et une perte de
flexibilité sur le développement.
Patrice
--
From: "Patrice Scribe" <scribe@chez.com>
References: <ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl>
Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? >Date: Mon, 13 Oct 2003 18:54:10 +0200
Intéressant, chaque instance de SQL Server te retourne une valeur
de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien comment
cela peut marcher.
Sur le plan du principe, une machine de développement et de production ne
répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
risque supplémentaire sur la disponibilité de la production et une perte de
flexibilité sur le développement.
Patrice
--
From: "Patrice Scribe"
References:
Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? >Date: Mon, 13 Oct 2003 18:54:10 +0200
Intéressant, chaque instance de SQL Server te retourne une valeur
de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien comment
cela peut marcher.
Sur le plan du principe, une machine de développement et de production ne
répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
risque supplémentaire sur la disponibilité de la production et une perte de
flexibilité sur le développement.
Patrice
--
Salut,
Chaque instance de SQL Server a ses propres binaires, ses propres services
et ses propres process.
Elles peuvent très bien avoir des build différentes (j'ai par exemple
toutes les builds majeures sur le même serveur : RTM SP1 SP2 SP3 et SP3 +
dernière mouture de hotfix). Cependant elles partagent quelques éléments
communs comme les outils d'admin ou les DLL de connectivité (MDAC) par
exemple.
Et surtout, surtout, elles partagent la même machine !!
Donc
- si reboot nécessaire du serveur de dev, le serveur de prod va rebooter
avec
- si un serveur "mange" tout le cpu (au hasard, test de dev sur serveur de
dev) le serveur de prod va en pâtir.
- Eventuels problèmes de sécurité (admin locaux = sysadmins des 2
par défaut)
- Pb avec l'OS (bidouillage du dev) impactera les 2 instances
- Partage de la mémoire
- Partage éventuellement du même disque ou du même controleur selon config
- "Erreur humaine" favorisée ("oops j'ai arrété le mauvais service" ca
n'existe pas que dans les BDs)
- Impossibilité de tester la nouvelle version/hotfix de MDAC sur le dev
sans toucher à la prod.
etc etc..
Rien n'empêche donc vraiment de placer ces 2 instances sur le serveur,
AMHA, c'est prendre des risques et c'est aussi réduire le spectre des
possibles sur le serveur de dev.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "Patrice Scribe"
>References:
<#iA#
>Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? > >Date: Mon, 13 Oct 2003 18:54:10 +0200
>
>Intéressant, chaque instance de SQL Server te retourne une valeur
différente
>de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien
>cela peut marcher.
>
>Sur le plan du principe, une machine de développement et de production ne
>répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
un
>risque supplémentaire sur la disponibilité de la production et une perte
>flexibilité sur le développement.
>
>Patrice
>
>--
>
Salut,
Chaque instance de SQL Server a ses propres binaires, ses propres services
et ses propres process.
Elles peuvent très bien avoir des build différentes (j'ai par exemple
toutes les builds majeures sur le même serveur : RTM SP1 SP2 SP3 et SP3 +
dernière mouture de hotfix). Cependant elles partagent quelques éléments
communs comme les outils d'admin ou les DLL de connectivité (MDAC) par
exemple.
Et surtout, surtout, elles partagent la même machine !!
Donc
- si reboot nécessaire du serveur de dev, le serveur de prod va rebooter
avec
- si un serveur "mange" tout le cpu (au hasard, test de dev sur serveur de
dev) le serveur de prod va en pâtir.
- Eventuels problèmes de sécurité (admin locaux = sysadmins des 2
par défaut)
- Pb avec l'OS (bidouillage du dev) impactera les 2 instances
- Partage de la mémoire
- Partage éventuellement du même disque ou du même controleur selon config
- "Erreur humaine" favorisée ("oops j'ai arrété le mauvais service" ca
n'existe pas que dans les BDs)
- Impossibilité de tester la nouvelle version/hotfix de MDAC sur le dev
sans toucher à la prod.
etc etc..
Rien n'empêche donc vraiment de placer ces 2 instances sur le serveur,
AMHA, c'est prendre des risques et c'est aussi réduire le spectre des
possibles sur le serveur de dev.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "Patrice Scribe" <scribe@chez.com>
>References: <ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl>
<uZrecV0jDHA.1656@tk2msftngp13.phx.gbl>
<#iA#XtZkDHA.3732@tk2msftngp13.phx.gbl>
>Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? > >Date: Mon, 13 Oct 2003 18:54:10 +0200
>
>Intéressant, chaque instance de SQL Server te retourne une valeur
différente
>de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien
>cela peut marcher.
>
>Sur le plan du principe, une machine de développement et de production ne
>répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
un
>risque supplémentaire sur la disponibilité de la production et une perte
>flexibilité sur le développement.
>
>Patrice
>
>--
>
Salut,
Chaque instance de SQL Server a ses propres binaires, ses propres services
et ses propres process.
Elles peuvent très bien avoir des build différentes (j'ai par exemple
toutes les builds majeures sur le même serveur : RTM SP1 SP2 SP3 et SP3 +
dernière mouture de hotfix). Cependant elles partagent quelques éléments
communs comme les outils d'admin ou les DLL de connectivité (MDAC) par
exemple.
Et surtout, surtout, elles partagent la même machine !!
Donc
- si reboot nécessaire du serveur de dev, le serveur de prod va rebooter
avec
- si un serveur "mange" tout le cpu (au hasard, test de dev sur serveur de
dev) le serveur de prod va en pâtir.
- Eventuels problèmes de sécurité (admin locaux = sysadmins des 2
par défaut)
- Pb avec l'OS (bidouillage du dev) impactera les 2 instances
- Partage de la mémoire
- Partage éventuellement du même disque ou du même controleur selon config
- "Erreur humaine" favorisée ("oops j'ai arrété le mauvais service" ca
n'existe pas que dans les BDs)
- Impossibilité de tester la nouvelle version/hotfix de MDAC sur le dev
sans toucher à la prod.
etc etc..
Rien n'empêche donc vraiment de placer ces 2 instances sur le serveur,
AMHA, c'est prendre des risques et c'est aussi réduire le spectre des
possibles sur le serveur de dev.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "Patrice Scribe"
>References:
<#iA#
>Subject: =?iso-8859-1?Q?Re:_Multiple_instance_Avantage_Incovénient? > >Date: Mon, 13 Oct 2003 18:54:10 +0200
>
>Intéressant, chaque instance de SQL Server te retourne une valeur
différente
>de SELECT ServerProperty('ProductLevel') ? Je ne vois pas très bien
>cela peut marcher.
>
>Sur le plan du principe, une machine de développement et de production ne
>répondent pas aux mêmes critères d'utilisation. Cela me semble introduire
un
>risque supplémentaire sur la disponibilité de la production et une perte
>flexibilité sur le développement.
>
>Patrice
>
>--
>
From: "mb"
References:
Subject: Re: Re: Multiple instance Avantage Incovénient
Date: Mon, 20 Oct 2003 12:09:19 +0200
Lines: 91
Merci
Techniquement les deux instances fonctionne bien sur un OS 2003
Nous avons fait des tests sur PC PIII
Instance 1 avec une boucle 100 % du CPU
Instance 2 avec une boucle 100 % du CPU
Un programme en VB avec une boucle 100 % du CPU
Réaction
Lancement de programme VB 100 % du CPU
CPU 100%
Lancement Instance 1 avec une boucle 100 % du CPU
CPU 100% VB50% INST1 50%
Lancement Instance 2 avec une boucle 100 % du CPU
CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
Conclusion
- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ - Entrepise
M. - ....
- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais il
faut aussi faire des choix avec le nombre de serveur que l'on possède.
From: "mb" <mb@isped.fr>
References: <ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl>
Subject: Re: Re: Multiple instance Avantage Incovénient
Date: Mon, 20 Oct 2003 12:09:19 +0200
Lines: 91
Merci
Techniquement les deux instances fonctionne bien sur un OS 2003
Nous avons fait des tests sur PC PIII
Instance 1 avec une boucle 100 % du CPU
Instance 2 avec une boucle 100 % du CPU
Un programme en VB avec une boucle 100 % du CPU
Réaction
Lancement de programme VB 100 % du CPU
CPU 100%
Lancement Instance 1 avec une boucle 100 % du CPU
CPU 100% VB50% INST1 50%
Lancement Instance 2 avec une boucle 100 % du CPU
CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
Conclusion
- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ - Entrepise
M. - ....
- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais il
faut aussi faire des choix avec le nombre de serveur que l'on possède.
From: "mb"
References:
Subject: Re: Re: Multiple instance Avantage Incovénient
Date: Mon, 20 Oct 2003 12:09:19 +0200
Lines: 91
Merci
Techniquement les deux instances fonctionne bien sur un OS 2003
Nous avons fait des tests sur PC PIII
Instance 1 avec une boucle 100 % du CPU
Instance 2 avec une boucle 100 % du CPU
Un programme en VB avec une boucle 100 % du CPU
Réaction
Lancement de programme VB 100 % du CPU
CPU 100%
Lancement Instance 1 avec une boucle 100 % du CPU
CPU 100% VB50% INST1 50%
Lancement Instance 2 avec une boucle 100 % du CPU
CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
Conclusion
- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ - Entrepise
M. - ....
- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais il
faut aussi faire des choix avec le nombre de serveur que l'on possède.
Effectivement, l'aspect budget vient souvent mettre son grain de sable =)
J'ajouterai ce dernier commentaire :
Il faut différencier les serveurs de "Dev'" et de "Préprod".
Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
OS client et une édition Developper de SQL. Les performances sont rarement
le critère de fonctionnement de tels serveurs, on est plutot sur des pb de
design, de tests, de fonctionnalités etc..
Par contre, le deuxième type est souvent utilisé pour des tests de montée
en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
certains vont même jusqu'a utiliser des configurations totalement
identiques, ce qui leur permet de faire des rotations entre prod et
une fois une solution testée avec succès en préprod, afin de limiter les
downtime de production.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "mb"
>References:
<#iA#
<G8gatq$
>Subject: Re: Re: Multiple instance Avantage Incovénient
>Date: Mon, 20 Oct 2003 12:09:19 +0200
>Lines: 91
>Merci
>Techniquement les deux instances fonctionne bien sur un OS 2003
>Nous avons fait des tests sur PC PIII
>
>Instance 1 avec une boucle 100 % du CPU
>Instance 2 avec une boucle 100 % du CPU
>Un programme en VB avec une boucle 100 % du CPU
>
>Réaction
>Lancement de programme VB 100 % du CPU
>CPU 100%
>Lancement Instance 1 avec une boucle 100 % du CPU
>CPU 100% VB50% INST1 50%
>Lancement Instance 2 avec une boucle 100 % du CPU
>CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
>
>Conclusion
>- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
>M. - ....
>- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais
>faut aussi faire des choix avec le nombre de serveur que l'on possède.
>
>
Effectivement, l'aspect budget vient souvent mettre son grain de sable =)
J'ajouterai ce dernier commentaire :
Il faut différencier les serveurs de "Dev'" et de "Préprod".
Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
OS client et une édition Developper de SQL. Les performances sont rarement
le critère de fonctionnement de tels serveurs, on est plutot sur des pb de
design, de tests, de fonctionnalités etc..
Par contre, le deuxième type est souvent utilisé pour des tests de montée
en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
certains vont même jusqu'a utiliser des configurations totalement
identiques, ce qui leur permet de faire des rotations entre prod et
une fois une solution testée avec succès en préprod, afin de limiter les
downtime de production.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "mb" <mb@isped.fr>
>References: <ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl>
<uZrecV0jDHA.1656@tk2msftngp13.phx.gbl>
<#iA#XtZkDHA.3732@tk2msftngp13.phx.gbl>
<usK3hqakDHA.2080@TK2MSFTNGP10.phx.gbl>
<G8gatq$kDHA.2148@cpmsftngxa06.phx.gbl>
>Subject: Re: Re: Multiple instance Avantage Incovénient
>Date: Mon, 20 Oct 2003 12:09:19 +0200
>Lines: 91
>Merci
>Techniquement les deux instances fonctionne bien sur un OS 2003
>Nous avons fait des tests sur PC PIII
>
>Instance 1 avec une boucle 100 % du CPU
>Instance 2 avec une boucle 100 % du CPU
>Un programme en VB avec une boucle 100 % du CPU
>
>Réaction
>Lancement de programme VB 100 % du CPU
>CPU 100%
>Lancement Instance 1 avec une boucle 100 % du CPU
>CPU 100% VB50% INST1 50%
>Lancement Instance 2 avec une boucle 100 % du CPU
>CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
>
>Conclusion
>- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
>M. - ....
>- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais
>faut aussi faire des choix avec le nombre de serveur que l'on possède.
>
>
Effectivement, l'aspect budget vient souvent mettre son grain de sable =)
J'ajouterai ce dernier commentaire :
Il faut différencier les serveurs de "Dev'" et de "Préprod".
Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
OS client et une édition Developper de SQL. Les performances sont rarement
le critère de fonctionnement de tels serveurs, on est plutot sur des pb de
design, de tests, de fonctionnalités etc..
Par contre, le deuxième type est souvent utilisé pour des tests de montée
en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
certains vont même jusqu'a utiliser des configurations totalement
identiques, ce qui leur permet de faire des rotations entre prod et
une fois une solution testée avec succès en préprod, afin de limiter les
downtime de production.
Cordialement,
Guillaume Fourrat
Microsoft France
--------------------
>From: "mb"
>References:
<#iA#
<G8gatq$
>Subject: Re: Re: Multiple instance Avantage Incovénient
>Date: Mon, 20 Oct 2003 12:09:19 +0200
>Lines: 91
>Merci
>Techniquement les deux instances fonctionne bien sur un OS 2003
>Nous avons fait des tests sur PC PIII
>
>Instance 1 avec une boucle 100 % du CPU
>Instance 2 avec une boucle 100 % du CPU
>Un programme en VB avec une boucle 100 % du CPU
>
>Réaction
>Lancement de programme VB 100 % du CPU
>CPU 100%
>Lancement Instance 1 avec une boucle 100 % du CPU
>CPU 100% VB50% INST1 50%
>Lancement Instance 2 avec une boucle 100 % du CPU
>CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
>
>Conclusion
>- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
>M. - ....
>- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod mais
>faut aussi faire des choix avec le nombre de serveur que l'on possède.
>
>
Exactement !!!
nous serons dans le cadre PREPROD et nous allons même appeler cette
PREPROD
le dev (la vrai bidouille) se fera en local sur du msde de chaque
développeur
Michel
""Guillaume Fourrat [MSFT]"" a écrit dans
message de news:
> Effectivement, l'aspect budget vient souvent mettre son grain de sable
> J'ajouterai ce dernier commentaire :
> Il faut différencier les serveurs de "Dev'" et de "Préprod".
> Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
avec
> OS client et une édition Developper de SQL. Les performances sont
> le critère de fonctionnement de tels serveurs, on est plutot sur des pb
> design, de tests, de fonctionnalités etc..
> Par contre, le deuxième type est souvent utilisé pour des tests de
> en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
> certains vont même jusqu'a utiliser des configurations totalement
> identiques, ce qui leur permet de faire des rotations entre prod et
préprod
> une fois une solution testée avec succès en préprod, afin de limiter les
> downtime de production.
>
> Cordialement,
>
> Guillaume Fourrat
> Microsoft France
> --------------------
> >From: "mb"
> >References:
>
> <#iA#
>
> <G8gatq$
> >Subject: Re: Re: Multiple instance Avantage Incovénient
> >Date: Mon, 20 Oct 2003 12:09:19 +0200
> >Lines: 91
>
> >Merci
> >Techniquement les deux instances fonctionne bien sur un OS 2003
> >Nous avons fait des tests sur PC PIII
> >
> >Instance 1 avec une boucle 100 % du CPU
> >Instance 2 avec une boucle 100 % du CPU
> >Un programme en VB avec une boucle 100 % du CPU
> >
> >Réaction
> >Lancement de programme VB 100 % du CPU
> >CPU 100%
> >Lancement Instance 1 avec une boucle 100 % du CPU
> >CPU 100% VB50% INST1 50%
> >Lancement Instance 2 avec une boucle 100 % du CPU
> >CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
> >
> >Conclusion
> >- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
Entrepise
> >M. - ....
> >- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod
il
> >faut aussi faire des choix avec le nombre de serveur que l'on possède.
> >
> >
>
Exactement !!!
nous serons dans le cadre PREPROD et nous allons même appeler cette
PREPROD
le dev (la vrai bidouille) se fera en local sur du msde de chaque
développeur
Michel
""Guillaume Fourrat [MSFT]"" <gfourrat@online.microsoft.com> a écrit dans
message de news:jHDUO4gmDHA.2148@cpmsftngxa06.phx.gbl...
> Effectivement, l'aspect budget vient souvent mettre son grain de sable
> J'ajouterai ce dernier commentaire :
> Il faut différencier les serveurs de "Dev'" et de "Préprod".
> Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
avec
> OS client et une édition Developper de SQL. Les performances sont
> le critère de fonctionnement de tels serveurs, on est plutot sur des pb
> design, de tests, de fonctionnalités etc..
> Par contre, le deuxième type est souvent utilisé pour des tests de
> en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
> certains vont même jusqu'a utiliser des configurations totalement
> identiques, ce qui leur permet de faire des rotations entre prod et
préprod
> une fois une solution testée avec succès en préprod, afin de limiter les
> downtime de production.
>
> Cordialement,
>
> Guillaume Fourrat
> Microsoft France
> --------------------
> >From: "mb" <mb@isped.fr>
> >References: <ukNtEKzjDHA.2424@TK2MSFTNGP10.phx.gbl>
> <uZrecV0jDHA.1656@tk2msftngp13.phx.gbl>
> <#iA#XtZkDHA.3732@tk2msftngp13.phx.gbl>
> <usK3hqakDHA.2080@TK2MSFTNGP10.phx.gbl>
> <G8gatq$kDHA.2148@cpmsftngxa06.phx.gbl>
> >Subject: Re: Re: Multiple instance Avantage Incovénient
> >Date: Mon, 20 Oct 2003 12:09:19 +0200
> >Lines: 91
>
> >Merci
> >Techniquement les deux instances fonctionne bien sur un OS 2003
> >Nous avons fait des tests sur PC PIII
> >
> >Instance 1 avec une boucle 100 % du CPU
> >Instance 2 avec une boucle 100 % du CPU
> >Un programme en VB avec une boucle 100 % du CPU
> >
> >Réaction
> >Lancement de programme VB 100 % du CPU
> >CPU 100%
> >Lancement Instance 1 avec une boucle 100 % du CPU
> >CPU 100% VB50% INST1 50%
> >Lancement Instance 2 avec une boucle 100 % du CPU
> >CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
> >
> >Conclusion
> >- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
Entrepise
> >M. - ....
> >- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod
il
> >faut aussi faire des choix avec le nombre de serveur que l'on possède.
> >
> >
>
Exactement !!!
nous serons dans le cadre PREPROD et nous allons même appeler cette
PREPROD
le dev (la vrai bidouille) se fera en local sur du msde de chaque
développeur
Michel
""Guillaume Fourrat [MSFT]"" a écrit dans
message de news:
> Effectivement, l'aspect budget vient souvent mettre son grain de sable
> J'ajouterai ce dernier commentaire :
> Il faut différencier les serveurs de "Dev'" et de "Préprod".
> Les premiers peuvent se contenter, par exemple d'un modeste PC desktop
avec
> OS client et une édition Developper de SQL. Les performances sont
> le critère de fonctionnement de tels serveurs, on est plutot sur des pb
> design, de tests, de fonctionnalités etc..
> Par contre, le deuxième type est souvent utilisé pour des tests de
> en charge et pour simuler efficacement le serveur de prod. Dans ce cas,
> certains vont même jusqu'a utiliser des configurations totalement
> identiques, ce qui leur permet de faire des rotations entre prod et
préprod
> une fois une solution testée avec succès en préprod, afin de limiter les
> downtime de production.
>
> Cordialement,
>
> Guillaume Fourrat
> Microsoft France
> --------------------
> >From: "mb"
> >References:
>
> <#iA#
>
> <G8gatq$
> >Subject: Re: Re: Multiple instance Avantage Incovénient
> >Date: Mon, 20 Oct 2003 12:09:19 +0200
> >Lines: 91
>
> >Merci
> >Techniquement les deux instances fonctionne bien sur un OS 2003
> >Nous avons fait des tests sur PC PIII
> >
> >Instance 1 avec une boucle 100 % du CPU
> >Instance 2 avec une boucle 100 % du CPU
> >Un programme en VB avec une boucle 100 % du CPU
> >
> >Réaction
> >Lancement de programme VB 100 % du CPU
> >CPU 100%
> >Lancement Instance 1 avec une boucle 100 % du CPU
> >CPU 100% VB50% INST1 50%
> >Lancement Instance 2 avec une boucle 100 % du CPU
> >CPU 100% VB30% INST1 30% INST1 30% et 10% SYST
> >
> >Conclusion
> >- Rien ne décroche mais tout est lent ACCESS - ANALYSEUR DE REQ -
Entrepise
> >M. - ....
> >- C'est bien mieux d'avoir 2 serveurs un de test et l'autre de prod
il
> >faut aussi faire des choix avec le nombre de serveur que l'on possède.
> >
> >
>
