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
De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part de
Envoyé : mercredi 11 avril 2007 17:57
À : ADSM-L AT VM.MARIST DOT EDU
Objet : Re: [ADSM-L] TDP SQL with multiple SQL instances
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
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 04/11/2007
> 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
> 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,
> 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é