MonitoringandTroubleshooting•Chapter10 447 Cashier 1 starts ringing in the first customer. The first customer buys books 1, 2, and 3. Each book shows 10 copies in stock. The customer is purchasing 1 copy of each book. Cashier 2 starts ringing in the second customer. The second customer buys books 1, 3, and 4. Each book shows 10 copies in stock. The customer is purchasing 1 copy of each book. Cashier 1 finishes the sale and the system updates the in stock amount to show 9 copies in stock. Cashier 2 finishes the sale and the system updates the in stock amount to show 9 copies in stock. The problem is that even though there were two copies sold, the system only shows one copy sold. Now the in-stock amount is out of sync with what is actually in the store. There are a couple different solutions to this problem. One removes the concurrency issues without causing a work slowdown for the cashiers. Another removes the concurrency issue but causes a work slowdown. In the first, there is a good deal of code change, which has to be made to the client and the database; in the second, the solution requires minimal code change to the client and no change to the database. In the first solution, instead of passing the ending total back to the database as “9”, the system passes back that “1” has been sold. The database code must be changed to take the value being passed in and subtract it from the stored stock in hand. In the second solution, you configure the cashiers’ computers and the server to support distributed transactions. Then you set the isolation level to a higher level of transaction from the default. This will cause the SQL Server to take a lock on the record that contains the stock data. The stock can then updated using the current technique. When the transaction is committed, the system completes the update and commits the transaction to the database. The problem with this technique is that when the second cashier tries to ring up the second customer, the cash register won’t respond until the first cashier has completed the sale. Agent Issues The SQL Server Agent is a pretty robust system. It has its own log file, SQLAGENT.OUT, which writes to the same folder as the SQL Server ERRORLOG. Any issues the SQL Server Agent has are logged into the SQLAGENT.OUT file. If the SQL Agent isn’t starting or nothing is being logged to the SQLAGENT.OUT file, ensure that the account the SQL Agent is running under has full control of 448 Chapter10•MonitoringandTroubleshooting the folder and log files being written to. In order for the SQL Server Agent to work correctly, the account the SQL Agent is running under should be a member of the sysadmin fixed server role. If the agent doesn’t have these rights, it won’t have access to view all the jobs nor will it have the ability to perform scheduled database maintenance tasks. Te s T Da y Ti p Don’t get confused by which service logs data into which log file. The ERRORLOG is used by the SQL Server engine, and the SQLAGENT.OUT file is used by the SQL Server Agent. With the release of SQL Server 2005, we were introduced to the concept of proxy accounts. Proxy accounts allow a user who creates a SQL Server Agent job to run individual steps of the job as another domain or local user. This is especially useful when SQL Server Agent jobs need access to network resources but the SQL Server Agent is running under a local user account or a system account. This concept of proxy accounts adds another layer of complexity to configuring and managing SQL Server Agent jobs. ex a m Wa r n i n g Credentials and proxies, while not new in SQL Server 2008, were new to SQL Server 2005, which means that you have a greater chance of seeing questions about them on the exam. All SQL Server Agent job step types support running under a proxy account with the exception of the T/SQL job step type. In order to create a proxy account, you must first create a credential. (See Chapter 4for more information about creating a credential.) After the credential is created, you can create a proxy account either within the SQL Server Management Studio in the Object Explorer or via T/SQL by using the sp_add_proxy system stored procedure, which can be found in the msdb database. In Figure 10.2, you can see a proxy account called “Sample_ Proxy,” which is based on the credential “Sample_Credential”. This proxy account has access to be used only for job step types of the operating system type. MonitoringandTroubleshooting•Chapter10 449 Figure 10.2 Creating a SQL Server Agent Proxy TE s T Da y Ti p Credentials are created based on domain or local Windows accounts. Proxies are made from credentials. You cannot create a proxy until a credential has been created. To create a credential, you must have the current password of the Windows account that the credential will be based on. If the password for the Windows account is ever changed, the credential must be manually updated before the proxy account will begin working again. 450 Chapter10•MonitoringandTroubleshooting On the second tab of the New Proxy window, you can assign local, domain, or SQL Server logins, which all have the right to use the proxy account. Even if the account used to create the credential (that is, mapped to the proxy) is the login that will be running, the job will not have access to use the credential. For example, let’s say you have a domain user named CONTOSCO\bob, and this login needs to run a job. However, the SQL Server doesn’t have access to a folder that holds the application that needs to be launched, and you create a credential and proxy based on the CONTOSCO\bob account. The login CONTOSCO\bob will not have access to the proxy unless you add CONTOSCO\bob as a principal on the second screen. Logins that are members of the sysadmin fixed server role have access to all proxy accounts on the server, and these rights cannot be removed. Figure 10.3 shows a SQL Server login being granted rights to the SQL Server Agent proxy. Figure 10.3 Granting SQL Server Logins Access to the Proxy MonitoringandTroubleshooting•Chapter10 451 Figure 10.4 Creating a Job Using a Proxy Account After you have created the proxy and granted the correct login the right to the proxy, you can use the proxy within your job step as shown in Figure 10.4. When you have selected the job step type, additional options appear in the “Run as” drop down box. Simply select the proxy account you wish to use and Click OK. If there is a problem with the SQL Server Agent’s proxy account, you will see it listed in the history of the SQL Server Agent job. To access the job history, you can right click on the job in the Object Explorer and select View History (see Figure 10.5). Because the proxy is mapped to a credential, which is mapped to a domain or local Windows account, there are several things that can cause problems with the proxy account. The account’s password might have expired or . to the same folder as the SQL Server ERRORLOG. Any issues the SQL Server Agent has are logged into the SQLAGENT.OUT file. If the SQL Agent isn’t starting or nothing is being logged to the SQLAGENT.OUT. and the SQLAGENT.OUT file is used by the SQL Server Agent. With the release of SQL Server 2005, we were introduced to the concept of proxy accounts. Proxy accounts allow a user who creates a SQL. you set the isolation level to a higher level of transaction from the default. This will cause the SQL Server to take a lock on the record that contains the stock data. The stock can then updated