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é
|