SQL Server 2008 R2 MSX/TSX: TSX Cachefile Problems


  • Hello

    I have an SQL Server 2008 R2 Environment in wich im implemented a MSX/TSX Configuration. I have one MSX Instance and two TSX Instances. However all works fine but I noticed in the Errorlogs of the TSX SQL Server Agents that there is a record wich says following:

    Date  07.02.2012 12:48:29
    Log  SQL Server Agent (Current - 07.02.2012 12:48:00)

    [419] Unable to open or read TSX cache file 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.INSTANCE0\MSSQL\JOBS\TSXCACHE.BIN' (win32 error code: 2)

    When I go to the given Location I cant see a file with this name. Also I found nothing usefull so far in the internet or microsoft forums.

    If anybody has a solution or informations please let me know it would be very usefull.

    Thank you. Peace Luca

    • แก้ไขโดย Luca Müller 7 กุมภาพันธ์ 2555 17:17
    7 กุมภาพันธ์ 2555 17:16


  • Hello Luca,

    Can you report this issue to SQL feedback


    Sethu Srinivasan [MSFT]

    SQL Server

    13 กรกฎาคม 2555 18:30
  • I have this problem occasionally. In our case, the answer is to reset the perms on this folder to inherit from the parent so taht the sql service/or at least your agent service has rights to it.  Typically, if you use a domain user/un privileged acct as your service user, there are some cases where a few perms on the SQL install have to be set.  In our environment for consistency, we use GPOs to enforce folder perms for the SQL locations.   However, during a SP apply or if your perms aren't quite right in the first place, the SQL installer edits the perms on this folde to be restrictive(it has tended to do this on the DATA folder too).  If you are using GPOS as it our case, the inheritance flags perhaps a little more limited when using a GPO may not be working exactly the way you want.   Essentially, it is a permissions problem, and you just need to make sure your service acct has rights all the way down to this folder.  You probably have to check it after you apply a SP also.  An oddly, like some others said, it continues working it seems despite the constant error so I'm not sure what that cache file really does.

    UC Berkeley

    27 พฤศจิกายน 2555 22:00