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@VM.MARIST.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é
