ADSM-L

Re: [ADSM-L] TDP SQL with multiple SQL instances

2007-04-11 14:24:59
Subject: Re: [ADSM-L] TDP SQL with multiple SQL instances
From: CAYE PIERRE <Pierre.Caye AT ALCATEL-LUCENT DOT FR>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 11 Apr 2007 18:03:21 +0200
Thanks Del,

I can breath again... Pffff

Anyway, I think that the simplest it is, the best it is.
Because of one thing, if we install and deploy a solution, who will maintain it 
?

Regards,

Pierre 

-----Message d'origine-----
De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part de 
Del Hoobler
Envoyé : mercredi 11 avril 2007 17:57
À : ADSM-L AT VM.MARIST DOT EDU
Objet : Re: [ADSM-L] TDP SQL with multiple SQL instances

Pierre,

In your case, is seems a single TSM NODENAME per machine is the way to go. As I 
mentioned in my previous email, this decision is based on your needs. Maybe 
others who are running multiple SQL Server instances per machine can tell of 
their experiences... 

Thanks,

Del

----------------------------------------------------


"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 04/11/2007 
11:05:20 AM:

> Hi everyone,
> 
> On some nodes, we have one SQL base running mutiples SQL instances.
> On (fortunately) few nodes, we also have multiple SQL bases runnings 
> single or multiple instances.
> Actually we are using one TSM TDPSQL node for each SQL instance, 
> whatever happend...
> 
> But we seriously think about working with only ONE TSM TDPSQL node per 
> machine.
> 
> Can somebody tell me what is the best practice ?
> 
> I don't really agree with the idea that separates nodes for each SQL 
> instances to manage datas separately is a good idea, because for 
> example of the master MSDB, northwind database, and so...
> I think that a simple node per machine is a more simple approach, 
> giving us the same level of security, simplifying the management, the 
> deployement, the scripting and so on...
> On restore point of view, we didn't have to sink about the node we 
> need to work with and therefore pick the right option file with all 
> troubles due to any mystake, we can see everything through the GUI, 
> and
so...
> 
> Anyway, we are obliged, by the tdpsqlc syntax, to work with multiples 
> versions of options files so why make things more complicated than 
> they already are, thanks to dev. Team...
> 
> As you understand, we a facing a mass problems, because we have to 
> manage not only one or two SQL bases, but numerous (actually it is 
> about 50, and it is growing...)
> 
> An other point is that we are using an external scheduler, with the 
> constraint of writing adequat and, if possible universal, scripts.
> 
> So... Any advices ?
> 
> Pierre Cayé