ADSM-L

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

2007-04-11 11:57:27
Subject: Re: [ADSM-L] TDP SQL with multiple SQL instances
From: Del Hoobler <hoobler AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 11 Apr 2007 11:57:09 -0400
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é