I need to find if /3GB switch and /PAE is enabled on a server.
Also, I want to know the size of page file and physical RAM on the server.
I can check them manually but how can I check them using TSQL on both SQL 2000 and SQL 2005?
Use WMI:
The Win32_OperatingSystem class exposes the PAEEnabled property
The Win32_ComputerSystem class exposes the SystemStartupOptions property that contains the boot.ini parameters (pre-Vista)
Post Vista you need to use the Boot Configuration Data WMI Provider to see if /3gb is enabled, but I'm not sure how.
To run WMI queries, use ExecuteWQL from the Policy Based Management framework (which you should be using anyway for the audit task you describe, see Administering Servers by Using Policy-Based Management).
PowerShell can also read WMI. Ultimately, WQL queries can be run straight from T-SQL using sp_OACreate and friends.
this looks like one http://sugeshkr.blogspot.com/2007/12/check-if-3gb-is-configured-or-not.html
If(Select Virtual_Memory_In_Bytes/1024/(2048*1024) from Sys.dm_os_Sys_Info) < 1
Begin
PRINT '/3GB Switch Not Configured in Boot.Ini (CHECK)'
End
Related
Is it somehow possible to call a web service from SQL Server without using CLR and get response immediatly back(not powershell, etc..)?
SQL Server provide a lot of different options to execute external scripts or connect to other devices. SQLCLR is one of the best but not the only option
From SQL 2016 you can use R or you can use Python, which let basically do what ever you want if you have permission.
You can use xp_cmdshell to execute commands
You can use OLE Automation objects (here is a nice sample).
You can use auditing tools (not recommended for most of these cases since these run in the background and not only when you need them), which allow you to execute external scripts on event
You can use simple QUEUE in the server side. In the Sp you can simply add message to the QUEUE and using external service app you can execute anything that you want once a new message get to the QUEUE. This option can be very useful since the execution is done asynchronous.
I can probably think about a lot more options... but let's start with these :-)
I have been using MS Access databases via DAO for many years, but feel that I ought to embrace newer techniques.
My main application runs on end user PCs (no server) and uses a shared database that is created and updated on-the-fly. When the application is first run it detects the absence of a database and creates a new empty one.
Any local user running the application is allowed to add or update records in this shared database. We have a couple of other shared databases, that contain templates, regional information, etc., but these are not updated directly by the application.
Updates of the application are released from time to time and each new update checks the main database version and if necessary executes code to bring the database up to the latest specification. This may involve the creation or deletion of tables and/or columns. New copies of the template databases are also included as part of the update.
Our users are not required to be computer-literate and should not need to run any sort of database management software beyond those facilities provided by the application.
It all works very nicely with DAO/Access, but I'm struggling to find how to do it with SQL Express. The databases seem to be squirrelled away in locations that are user-specific and database creation and update seems at best awkward to do by program code alone.
I came across some references "Xcopy deployment" that looks like it could be promising, but there seem to be references to "user instances" that sound suspiciously like something that's not shared. I'd appreciate advice from anyone who has done it.
It sounds to me like you haven't fully absorbed the fundamental difference between the Access Database Engine (ACE/Jet) and SQL Server:
When your users launch your Access application it connects to the Access Database Engine that has been installed on their machine. Their copy of ACE/Jet opens the shared database file (.accdb or .mdb) in the network folder. The various instances of ACE/Jet work together to manage concurrent updates, record locking, and so on. This is sometimes called a "peer-to-peer" or "shared-file" database architecture.
With an application that uses a SQL Server back-end, the copies of your application on each user's machine connect over the network to the same instance of SQL Server (that's why it's called "SQL Server"), and that instance of SQL Server manipulates the database (which is stored on its local hard drive) on behalf of all of the clients. This is called "client-server" or "server-based" database architecture.
Note that for a multi-user database you do not install SQL Server on the client machines, you only install the SQL Server Client components (OleDb and ODBC drivers). SQL Server itself is only installed in one place: the machine that will act as the SQL... Server.
re: "database creation and update seems at best awkward to do by program code alone" -- Not at all, it's just "different". Once again, you pass all of your commands to the SQL Server and it takes care of creating the actual database files. For example, once you've connected to the SQL Server if you tell it to
CREATE DATABASE NewDatabase
it will create the database files (NewDatabase.mdf and NewDatabase_log.LDF) in whatever local folder it uses to store such things, which is usually something like
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
on the server machine.
Note that your application never accesses those files directly. In fact it almost certainly cannot do so, and indeed your application does not even care where those files reside or what they are called. Your app simply talks to the SQL Server (e.g. ServerName\SQLEXPRESS) and the server takes care of the details.
Just to update on my progress. Inspired by suggestions here and this article on code project:
http://www.codeproject.com/Articles/63147/Handling-database-connections-more-easily,
I've created a wrapper for the ADO.NET methods that looks quite similar to the DAO stuff that I am familiar with.
I have a class that I can use just like a DAO Database. It wraps ADO methods like ExecuteReader, ExecuteNonQuery, etc. with overloads that can accept a SQL parameter. This allows me to directly replace DAO Recordsets with readers, OpenRecordset with ExecuteReader and Execute with ExecuteNonQuery.
Each method obtains and releases the connection from its parent class instance. These in turn open or close the underlying connection as required depending on the transaction state, if any. So a connection is held open for method calls that are part of a transaction, but closed immediately for a single call.
This has greatly simplified the migration of my program since much of the donkey work can be done by a simple "find and replace". The remaining issues are then relatively easy to find and sort out.
Thanks, once again to Gord and Maxwell for your advice.
This answer is too long to right down... but go to Microsoft page, there they explain how to make it: http://office.microsoft.com/en-us/access-help/move-access-data-to-a-sql-server-database-by-using-the-upsizing-wizard-HA010275537.aspx
I hope this help you!!
Is it possible to monitor what is happening to an Access MDB (ie. what SQL queries are being executed against it), in the same way as you would use SQL Profiler for the SQL Server?
I need logs of actual queries being called.
The answer depend on the technology used from the client which use MDB. There are different tracing settings which you can configure in HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC http://office.microsoft.com/en-us/access/HP010321641033.aspx. If you use OLEDB to access MDB from SQL Server you can use DBCC TRACEON (see http://msdn.microsoft.com/en-us/library/ms187329.aspx). I can continue, but before all you should exactly define which interface you use to access MDB.
MDB is a file without any active components, so the tracing can makes not MDB itself, but the DB interface only.
UPDATED: Because use use DAO (Jet Engine) and OLE DB from VB I recommend you create JETSHOWPLAN regisry key with the "ON" value under HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\JET\4.0\Engines\Debug (Debug subkey you have to create). This key described for example in https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5064388.html, http://msdn.microsoft.com/en-us/library/aa188211%28office.10%29.aspx and corresponds to http://support.microsoft.com/kb/252883/en allow trace OLE DB queries. If this output will be not enough for you you can additionally use TraceSQLMode and TraceODBCAPI from HKEY_LOCAL_MACHINE\Software\Microsoft\Jet\4.0\Engines\ODBC. In my practice JETSHOWPLAN gives perfect information for me. See also SHOWPLAN commend.
UPDATED 2: For more recent version of Access (like Access 2007) use key like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Access Connectivity Engine\Engines. The tool ShowplanCapturer (see http://www.mosstools.de/index.php?option=com_content&view=article&id=54&Item%20%20id=57, to download http://www.mosstools.de/download/showplan_v9.zip also in english) can be also helpful for you.
If you're accessing it via ODBC, you can turn on ODBC logging. It will slow things down a lot, though. And it won't work for any other data interface.
Another thought is using Jet/ACE as a linked server in SQL Server, and then using SQL Profiler. But that's going to tell you the SQL that SQL Server processed, not what Jet/ACE processed. It may be sufficient for your purposes, but I don't think it would be a good diagnostic for Jet/ACE.
EDIT:
In a comment, the original poster has provided this rather crucial information:
The application I am trying to monitor
is compiled and at a customer's
premises. I am trying to monitor what
queries it is attempting against an
MDB. I cannot modify the application.
I am trying to do what SQL Profiler
would do for a SQL Server.
In that case, I think that you could do this:
rename the original MDB to something else.
use a SQL Server linked server to connect to the renamed MDB file.
create a new MDB with the name of the original MDB and link to the SQL Server with ODBC.
The result will be an MDB file that has the same tables in it as the original, but they are not local, but links to the SQL Server. In that case, all access will be going through the SQL Server and can be viewed with SQL Profiler.
I don't have a clue what this would do to performance, or if it would break any of the data retrieval in the original app. If that app uses table-type recordsets or SEEK, then, yes, it will break. But this is the only way I can see to get logging.
It shouldn't be surprising that there is no logging for Jet/ACE, given that there is no single server process managing access to the data store.
Keep in mind that the file sitting on your hard drive is simply a windows file. So, there is a big difference between a server based system and that of a simple text file, or Power Point file, or in this case a mdb file just sitting on the drive.
However you can get the jet engine to display its query optimizeing via showplan.
How to do this is explained here:
http://www.databasejournal.com/features/msaccess/article.php/3658041/Queries-On-Steroids--Part-IV.htm
The above article also shows how to access the jet disk read statistics, which I also find extremely useful for optimizing things.
Just remember to turn off that data engine logging system when you’re not using it as it creates huge log files…
you could write your own profiler, based on a "transaction" object that will centralize all instructions sent to the database, You'll end up somewhere with a "transaction.execute" method, and a transaction table in your access db. This table can then be used to collect transaction's instructions, start time, end time, user sending the instruction, etc.
I'd suggest upsizing the tables to SQL Server. There is a tool from the SQL Server group that is better than the Upsizing Wizard that is included with Access.
SQL Server Migration Assistant for Access (SSMA Access)
Also see my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page
Is there a tool for windows that we can use to inspect any SQL commands that go through a particular ODBC data source?
You can make ODBC log out everything it's doing:
http://support.microsoft.com/kb/274551
http://msdn.microsoft.com/en-us/library/ms711020%28VS.85%29.aspx
You can also do it programmatically:
... One can do this by calling SQLSetConnectAttr and set the SQL_ATTR_TRACE attribute in the connection to SQL_OPT_TRACE_ON. So, by doing this you would be enabling/disabling it for the connection duration.
http://decipherinfosys.wordpress.com/2009/01/17/odbc-tracing/
If you're using SQL Server, look at the SQL Server Profiler. Profiler allows you to monitor/trace all communications between your application and the SQL Server, including which procedures are called, parameter values, etc, without having to modify your application.
If you're using a different server, you should be able to find a sql proxy that will do the same thing.
Is there any way to map to a network drive by using a stored procedure? I have tried:
xp_cmdshell 'net use Q: [shared_network_drive] [pwd] /user:[username]'
but I got an error saying something like
'System error 1312 has occurred.'
'A specified logon session does not exist. It may already have been terminated.'
However, when I run the same command in a cmd console in the same box as the SQL server machine, there is no problem at all. It looks like that SQL process does pass correct logon credential information. Any way to do it by SQL SP?
In an other forum someone posted a tip about how to solve the System error 1312 has occurred. problem by specifying the username including its domain like this:
net use Q: \\[host]\[folder] [pwd] /user:[host]\[username]
I tried it and it worked for me.
I spent one hour, but the problem solves: You must specify [HOST]\[username]
If you write like this: u:/username - it doesn't work
Do you have a proxy account set up for xp_cmdshell? If you are not a member of sysadmin, it requires a proxy account. The documentation for xp_cmdshell and sp_xp_cmdshell_proxy_account will explain it in detail, but try executing the following:
EXEC sp_xp_cmdshell_proxy_account 'DOMAIN\Username', 'password'
Of course, replace the user and password information with the account information on your network under which you want this to execute.
WARNING: xp_cmdshell can be a HUGE hole in security. Make sure that at the very least the proxy account that you use has very limited security. Don't use any kind of admin account and don't use an actual user's account.
Why would you even want to do this?!? Even if it is possible, you should be carefully asking yourself why you would want to do so.
My suggestion: don't. My impression is that you need to change your approach--whatever purpose that network drive mapping might serve should be pursued in a more appropriate place outside of the database engine. Once you choose that appropriate place, actually invoking the mapping will probably become trivial.
Rod, you are right. It is a big risk to do that in SQL server and not all the SQL admins would allow to open this door. What I am doing is to migrate legacy process to a scheduled SQL job so that required data will be available for another department's application to fetch data in another scheduled process.
I guess that a windows service job might be a better application to pull data out and transfer the result to the required network drive.
Actually, use Win Scheduled Tasks tool is what I need. I can create a .Net app to do the job and then add the application to the scheduled tasks.
The problem happens when using Distributed File System, no matter which operating system you're using. Instead, get the actual name of a server hosting the DFS content.