| Author |
Topic |
|
vaaccess
Starting Member
23 Posts |
 Posted - 2005-10-31 : 11:19:52
|
| So, I'm looking into using an MSX/TSX setup to help manage and monitor jobs, etc.I took two test boxes and set one up as a Master and one as a Target and got it working...was able to push a job out and it ran and reported back, etc.So, that's all great, but this was one small limited test. I'm curious to know if there are any gotchas that some of you have experienced that you would be willing to share with me to help prevent me from experiencing the same issues, etc.I have about 40 instances that I'm considering using this MSX/TSX setup with, the remaining 15 instances would be monitored by something like Quest. Can a single MSX handle jobs on 40 instances? I already have maintenance plans and jobs set up on all the remote servers. Is there a way to transfer their ownership up to the MSX so they can be monitored from there? So far I haven't seen a way to do that.*ponders*Actually, one thing I just realized is that I could set up a job that looked for failed jobs. If I pushed that job out to all the TSX servers that could be used to alert me that something failed on a TSX box. That would actually be a great way to do it the more I think about it...Can anyone think of a reason why that is a bad idea?Thanks! |
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-10-31 : 14:10:01
|
I can't think of a reason that's a bad idea.  To import the existing jobs, you would need to use script to setup jobs, job steps, and push the jobs out after deleting existing ones I believe. I don't think a lot of people on here use MSX servers, although if they do I would love to hear from them. Have you looked at SQLSentry at all?MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
 |
|
|
vaaccess
Starting Member
23 Posts |
Posted - 2005-10-31 : 14:24:32
|
| Yeah, we currently have SQL Sentry installed.Overall, I'm not happy with the way that SQL Sentry works and that's why we are moving up to Quest for our Tier 1 servers. For the rest of the servers I want to come up with a "free" solution...We won't be keeping SQL Sentry going foward. |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-10-31 : 16:50:19
|
| What problems have you had with SQL Sentry. We were going to evaluate it once the new version came out. The biggest issue I have with the current version is no centralized management of multiple servers and no way to really setup decisioning, balancing, and robust dependencies. Having said that, Quest is an entirely different product than SQL Sentry. What Quest tool are you planning on using.MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
vaaccess
Starting Member
23 Posts |
Posted - 2005-10-31 : 16:59:34
|
| We're going to install Foglight for the daily monitoring and SLA creation, but also use Spotlight and Quest Central...SQL Sentry is more like what MOM can do with regards to monitoring. It just doesn't do all that we want it to be able to do. We also have Oracle and SQL Server and wanted a single tool to monitor/manage both environments. We personally have had issues with bugs that I personally don't think should even make it past UAT, but then again I can be pretty picky sometimes...One annoying thing was about 3-4 weeks ago the SQL Sentry DB repository server ran out of space. The person I replaced had set up a DB on that same server in FULL mode, but never did any transaction backups so the log grew and grew...No big deal, right? I mean, SQL Sentry should just throw out an error or two about the problem. Well...What happened was that SQL Sentry continued to send out an e-mail every 5 seconds for several hours (started Friday night around 1AM if I recall correctly) saying that the log was full...I think we had 53K e-mails in our in-boxes by the time I stopped it. That took a LONG time to clean up. Luckily it happened on the weekend and I was able to stop it before our Exchange server died...That's just one example for you. ;)Mike |
|
|
|
derrickleggett
Pointy Haired Yak DBA
4184 Posts |
Posted - 2005-10-31 : 17:52:26
|
| Ok. That example sounds like your implementation of the product. SQL Sentry isn't a MOM-like tool anyway. It's a job management tool:http://www.sqlsentry.net/If you're having any problems with the particular tool above, let me know. That's the one I'm interested in evaluating when the new version comes out. If it's not up to our standards, we're writing our own job system to perform what I described above.I love the Quest tools. I wish we could afford them here. We're considering the purchase of Foglish. I can't justify Spotlight or Quest Central though, much as I would like to have them. MeanOldDBAderrickleggett@hotmail.comWhen life gives you a lemon, fire the DBA. |
|
|
|
vaaccess
Starting Member
23 Posts |
Posted - 2005-10-31 : 22:36:35
|
| Why does it sound like the implementation was wrong? The SQL Sentry repository is tracking all of our jobs. When it tried to record some of the job history it is monitoring and the drive was full, that's when it started to barf.You're right, though, MOM does monitor a lot more than SQL Sentry does and MOM doesn't allow you to manage jobs, etc, etc, etc...I didn't mean it the way it sounded I guess. Personally I don't have an issue keeping track of jobs and working through timing issues on multiple servers and the only benefit in my mind is the job monitoring...Don't get me wrong, I'm not saying it's a crappy product I can see value in it for some, but it just doesn't do what we need it to do whereas Quest does. |
|
|
|
schuhtl
Posting Yak Master
102 Posts |
Posted - 2005-11-02 : 09:50:58
|
| My company uses MSX/TSX to manage all of our backup, integrity and reindexing jobs. The only thing I have found to be some what of a pain is when you create a new multi server job and create a new step the database dropdown list only contains the databases on the master server. It would be nice when you create a new job that only has only one target server if it would list the databases on that target server. We have and Admin database on most of our servers that contains all of our admin scripts so to get around the problem I mentioned my step looks something like this...USE ADMIN GO EXEC usp_Backup @Path = '"D:\BACKUP\"', @dbType = 'User', @DbName = 'CTrackDB'The 'GO' causes problems when trying to script your job. Other than that everything has worked great for us. |
|
|
|
|
Master Server MSX/TSX Setup