Pentium III recommendedĪn Introduction to the SQL Server Transaction Log
APEX SQL LOG SOFTWARE
They are required by the software to function and mandatory to be placed in master as this is the only place SQL Server allows to place custom extended stored procedures. Basically that’s a stored procedure and several extended stored procedures.
APEX SQL LOG INSTALL
One thing to be aware of, however, is that ApexSQL Log needs to install on the first connect to a new server some “server-side components”, which actually means that several objects will be created in your master database. The whole installation process is straight-forward and simple to handle. Licensing is necessary on a per-server basis the activation process needs to be done for each instance you want to monitor on the given server. This can either be done automatically or manually. After buying the tool, you need to activate it. You can download the software from the ApexSQL homepage at and explore it for a fully-functional 30 days trial. Installation, System Requirements, supported SQL Server versions The second part will then deal with case studies in a suboptimal OLTP environment. In this paper at hand I will discuss the use of ApexSQL Log in an “optimal” OLTP environment.
APEX SQL LOG SERIES
This is the first of a series of two whitepapers. Nor does it save you from implementing a proper backup strategy and probably even a disaster recovery plan. Yet useful and necessary, doesn’t it absolve you from your responsibility to implement a suitable permission concept for the users of your databases. I intentionally say “hopefully not”, as the ApexSQL Log tool should clearly be seen as what it is and what it is designed for: It is a tool of last resort! The purpose of this whitepaper is to explore how ApexSQL Log can assist you, as a DBA, in your (hopefully not!) daily work when you get confronted with questions like the above mentioned. One of these specialised tools is ApexSQL Log, which is the subject of my discussion here. The answer to such questions is more or less always the same: “SQL Server does not offer any documented built-in mechanisms to view the content of the log file or recover specific rows from the log. Sometimes even complete objects were dropped by accident and now they need to be recovered. Probably someone mistakenly deleted the wrong row or deleted or modified more rows than planned. Such questions are good candidates for a FAQ and the reasons for the questioners to ask are manifold. When you follow the different communities dedicated to Microsoft SQL Server, you cannot help noticing many questions about if it is somehow possible to view or audit the content of the log file.
0 kommentar(er)
