Re: Very Very Urgent, Please Help
- From: "DKRReddy" <dkrreddy@xxxxxxxxxxx>
- Date: Mon, 19 Sep 2005 18:19:35 -0700
Yes there was msdb access.The following is from sql trace.
exec sp_executesql N'exec msdb..sp_log_dtsstep_begin @P1, @P2, @P3', N'@P1
uniqueidentifier,@P2 nvarchar(27),@P3 datetime',
'4A1665AF-4C92-457F-B1B1-75B2BCD18E88', N'DTS_Error_Log_DB_DAILY_Step', 'Sep
6 2005 1:42:57:000AM'
SELECT N'Testing Connection...'
EXECUTE msdb.dbo.sp_sqlagent_get_perf_counters
exec sp_executesql N'exec msdb..sp_log_dtsstep_end @P1, @P2, @P3, @P4, @P5,
@P6, @P7, @P8', N'@P1 bigint,@P2 int,@P3 int,@P4 datetime,
@P5 float,@P6 int,@P7
nvarchar(185),@P8 bigint', 48814, 4, 1, 'Sep 6 2005 1:43:13:000AM',
1.634300000000000e+001, -2147467259,
N'
Step Error Source:
Microsoft OLE DB Provider for SQL Server
Step Error
Description:Timeout expired
Step Error code: 80004005
Step Error Help File:
Step Error Help Context
ID:0
', 0
exec msdb..sp_get_dtspackage N'DTS_Policy_Driver_SSN',
'{C7FF64C3-9006-42C9-BEB7-79775F09A2D2}', null
exec msdb..sp_get_dtspackage N'DTS_DM_To_DW_ALL_DAILY',
'{06A28751-CA51-410E-9421-907A507A1E04}', null
"Jéjé" <willgart@xxxxxxxxxxxxxxxxx> wrote in message
news:uWxyZDatFHA.3188@xxxxxxxxxxxxxxxxxxxxxxx
> does the profiler display something?
> do you see any MSDB access when you try to open/execute a package?
>
> have you try to force the server access by creating an alias?
> you can force the TCP/IP usage or netbios usage; also try an IP address
> instead-of a netbios or DNS name
>
>
> "DKRReddy" <dkrreddy@xxxxxxxxxxx> wrote in message
> news:%23wjNDdVtFHA.3896@xxxxxxxxxxxxxxxxxxxxxxx
> > No, production servers services will always run under domian admin
> > account.
> > This is not the issue.
> >
> >
> > "Darren Gosbell" <dgosbell_at_yahoo_dot_com> wrote in message
> > news:MPG.1d8b89989fc5c0c7989688@xxxxxxxxxxxxxxxxxxxxx
> > It sounds like you are running the SQL Agent service under the local
> > system account which does not have access to the DTS packages.
> >
> > The way I normally set up SQL Agent is to run it under a domain user
> > account. This has 2 advantages.
> >
> > 1) It can then access network resources such as file shares (Local
> > System can only access resources on the SQL Server itself)
> >
> > 2) You can also "debug" security issues such as the one you are now
> > having because you can log in under the same account as the SQL Agent
> > and run the packages from Enterprise manager it is often easier to see
> > exactly where your problems are occurring.
> >
> > I would recommend setting up this user with the minimum require security
> > privileges. RESIST the temptation to set this user up as an
> > administrator as it could mean that any user that can schedule a job can
> > run a process under this account. If someone cracks an SA password, they
> > can schedule a job to give them full access to your machine at the OS
> > level and from there possibly out into your network.
> >
> > --
> > Regards
> > Darren Gosbell
> > <dgosbell_at_yahoo_dot_com>
> > Blog: http://www.geekswithblogs.net/darrengosbell
> >
> > In article <#bi0pnMtFHA.596@xxxxxxxxxxxxxxxxxxxx>,
> > willgart@xxxxxxxxxxxxxxxxx says...
> >> does the SQL Agent service run under a known account?
> >>
> >> "DKRReddy" <dkrreddy@xxxxxxxxxxx> wrote in message
> >> news:%23SWDRmJtFHA.664@xxxxxxxxxxxxxxxxxxxxxxx
> >> > When running the dts package as a job , it's failing while opening
the
> >> > package itself.
> >> > Security log in keep filling, is this the cause?
> >> >
> >> >
> >> >
> >> > "Darren Gosbell" <dgosbell_at_yahoo_dot_com> wrote in message
> >> > news:MPG.1d88f7c738031b6f989685@xxxxxxxxxxxxxxxxxxxxx
> >> > This sounds like a permissions issue. If you can run the packages
from
> >> > Enterprise manager then the issue is not necessarily with the
packages
> >> > themselves.
> >> >
> >> > If the packages are executed via a SQL agent job that launches them
> >> > using dtsrun, then I suggest you check which account the SQL Agent
> >> > service is running under. It might also have something to do with the
> >> > owner of the Agent jobs.
> >> >
> >> > Packages run via Enterprise Manager run in the security context of
the
> >> > currently logged on user. Packages launched via SQL Agent run in the
> >> > context of the account that the SQL Agent Service logs in under.
> >> >
> >> > --
> >> > Regards
> >> > Darren Gosbell
> >> > <dgosbell_at_yahoo_dot_com>
> >> > Blog: http://www.geekswithblogs.net/darrengosbell
> >> >
> >> > In article <eP$UU6osFHA.3164@xxxxxxxxxxxxxxxxxxxx>,
> >> > dkrreddy@xxxxxxxxxxx
> >> > says...
> >> >> All packages are refering to the new server only.If I run the
package
> >> >> from
> >> >> enterprise manager runs fine no timeout errors.
> >> >>
> >> >>
> >> >>
> >> >> "Jéjé" <willgart@xxxxxxxxxxxxxxxxx> wrote in message
> >> >> news:OHhuUhnsFHA.3404@xxxxxxxxxxxxxxxxxxxxxxx
> >> >> > does your packages are stored in the MSDB database?
> >> >> > Have you changed your main package to use the right SQL Server
> >> >> > instance?
> >> >> >
> >> >> > if your main dts package try to open a package on the <old server>
> > and
> >> > if
> >> >> > this server is down, then you'll receive a timeout error.
> >> >> >
> >> >> >
> >
> >
>
.
- References:
- Very Very Urgent, Please Help
- From: DKRReddy
- Re: Very Very Urgent, Please Help
- From: Jéjé
- Re: Very Very Urgent, Please Help
- From: DKRReddy
- Re: Very Very Urgent, Please Help
- From: Jéjé
- Re: Very Very Urgent, Please Help
- From: DKRReddy
- Re: Very Very Urgent, Please Help
- From: Darren Gosbell
- Re: Very Very Urgent, Please Help
- From: DKRReddy
- Re: Very Very Urgent, Please Help
- From: Jéjé
- Re: Very Very Urgent, Please Help
- From: Darren Gosbell
- Re: Very Very Urgent, Please Help
- From: DKRReddy
- Re: Very Very Urgent, Please Help
- From: Jéjé
- Very Very Urgent, Please Help
- Prev by Date: Check syntax of stored procs and views-sp_grep
- Next by Date: Free Evaluation of Database Administration Software
- Previous by thread: Re: Very Very Urgent, Please Help
- Next by thread: Analyst Services Question
- Index(es):
Relevant Pages
|
Loading
