Could anyone please help me to understand this code under SQL-Server Job steps. One of the step having this process and I am not getting its process behavior with Type - "Operating System (CmdExe)" and Run-as - "SQL Server Agent Service Account".
Also, What is the actual role of these Type & Run-as in option?
Run as defines the proxy account to be used to run this step. Proxy accounts defines a security context in which this job step runs. Each proxy corresponds to a security credential. For example, if you try to execute a copy command with CmdExec type, you must use a credential (e.g. Windows user account) that has rights to read the source file and rights to write in the destination folder.
Job steps can be different types:
Executable programs and operating system commands.
Transact-SQL statements, including stored procedures and extended stored procedures.
PowerShell scripts.
Microsoft ActiveX scripts.
Replication tasks.
Analysis Services tasks.
Integration Services packages.
Each type is executed differently. T-SQL scripts are sent to the database engine, executable programs (CmdExec) starts external programs (e.g. copy to copy files, or DTSRun to run a DTS package outside of SQL Server, as in your example), etc.
Related
I have a question regarding the purpose of some service in sql. What does the process, the purpose of them.
OracleSchedulerXE
OracleORADB19Home1MTSRecoveryService
OracleOraDB19home1TNSListner
OracleRemExecServiceV2
OracleServiceXE
OracleVSSWriter
I tried to find something about OracleSchedurXE but I did nt find anithing.
Thank you.
If I Google any of the service names, I get back several pages that go into detail about what they do.
OracleSchedulerXE is used by Oracle for the dbms_scheduler package that lets you schedule jobs to run inside the database.
OracleORADB19Home1MTSRecoveryService is used for interacting with the Microsoft Transaction Server. Most commonly, that is used to allow applications to manage distributed transactions that involve Oracle and other Windows services.
OracleOraDB19home1TNSListner is used for the TNS listener.
That's the process that allows users to connect to the database from remote machines.
OracleRemExecServiceV2 is a service used by the Oracle Universal Installer during installation that will be removed once you reboot after a successful install.
OracleServiceXE is the service that actually runs the Oracle database
OracleVSSWriter is a service that interacts with the Windows Volume Shadow Copy service to ensure that backups see files in a consistent state.
I developed an application that used SQL Server database 2017. I wrote most of the business logic in stored procedures, triggers & UDF. Now at the time of Go-Live, I want to deploy a compiled database on a client-server machine so no one can view or change scripts.
I can manage this from the SQL Security, access rights, etc. but actually, the Client network administrator has all the credentials and rights of the database and I do not want anyone to view/change the script even the administrator.
can I deploy a compiled database on a client-server instead of a regular one so no one can view/change scripts but can execute them Similarly like EXE file users can execute it but cannot view/change the code?
Does Microsoft SQL Server provide a solution on this or any workaround?
please suggest thanks in advance.
I have SSIS 2012 package which runs SQL command by executing SQLCMD command line utility with -E switch. This switch means that it should use trusted connection to connect to SQL server.
The problem is that if i try to run package directly through Object Explorer, i get ANONYMOUS LOGON error. I get the same error running package using stored procedures.
The only way i can run it is through SQL Server Agent Job which then uses SQL Server Agent login.
The question is how to run package using stored procedures with some user which will be used for trusted connection?
Two options. For your manual executions, you'll need to use [RunAs][1] command to launch the dtexec process as the desired user. Covered it a bit in this answer Deploying SSIS (SQL Server 2012) Project Outside Network
For scheduled executions, you'll need to create the appropriate stored credentials within SQL Server, authorize those credentials for use with jobs of type SSIS and then create your job using those stored credentials.
I've followed the steps at the site http://www.dotnetspider.com/resources/24960-How-Process-SSAS-Cubes-Automatically.aspx
It works in development phase, but I need to change the target of the cube in deployment environment.
I opened the package file and I've edited it manually, but it doesn't works...
I don't know if is authentication problems. But my questions is, how to parametrize the target of the cube that I want to process?
Thanks.
obs: I'm not expert in Analysis Services but I need to execute this job.
The best way is to, in SSIS, base your Analysis Services connection on an expression:
Create a variable #[Server] to hold the name of your Analysis Services server.
Add an expression to you Analysis Services connection, pointing the property ServerName to that variable.
Add a Package Configuration to your package, so you can have different configurations according to where you want to deploy the package.
I did this:
Make a DOMAIN\USER administrator of SQL Server Analysis Services
Give the same DOMAIN\USER the fixed-role "sysadmin" on the SQL Server.
Create new credentials in SQL Server with Login Data of this DOMAIN\USER.
Create a proxy user on SQL Server with the new created credentials, and allow AS Service Command and AS Service Query execution.
Create your SQL Server Agent Job that execute a query for cube processing and select the created proxy user.
I deployed my working package on server which is enterprise edition, SSIS installed on it. When I tries to run package by connecting to integration services engine from my desktop SQL client (which doesn't have SSIS installed) I get error "The task "Send Mail Task" cannot run on this edition of Integration Services. It requires a higher level edition."
Does it mean that I need to login to the server (RDP) and then run the package?
Also, when I schedule the package thru SQL agent it fails saying login time out but my windos auth login works for everything from connecting, deployment. Any clue?
For your first problem - yes, you need to RDP into the server in order to use SSMS to start the package. When you start it using SSMS on your client, it's attempting to launch the DTExec process on your client machine. It's not running DTExec on the server.
Your second problem is likely a permissions issue. Possibility #1: The connections you have set up on your package require your authentication information, and they don't have it because they're running as the Agent account. You can fix that by creating a Proxy for your account and using that to run your job step. Possibility #2: The connections you have set up on your package are having their sensitive information stripped out due to the default encryption on the packages that prevents anyone but "you" from seeing it - including a SQL Agent job that isn't running "as you". The same resolution as above can help that (as well as others).