I am very new to SQL Server database. We have installed SQL Server 2016. We would like to enable the change logs with maximum retention of 14 days. The purpose is to track any changes done etc.
Can someone please help me out with the steps to achieve this?
Welcome, Ayushi.
Based on your question, it appears that you want to have an easy ability to look at what has changed in the last 14 days. If this is the case, then you are probably looking at enabling Change Data Capture (CDC).
(Note: To ensure that you actually want CDC, and not just Change Tracking, you should read this Microsoft article)
Unfortunately, this is more than a simple "flip this switch to track changes" answer. To implement this, you can start with this article on implementing the different types of change tracking from Microsoft, and then go to the subarticles on actual implementation, space considerations, etc.
Note that you may only want to track changes on a few tables, and not the entire database, for space and performance reasons.
Related
My client is utilizing software that is SQL-based, the database having been set up by the software vendor for us. During a call I had made to the software vendor to ask them to connect to the SQL server to look at a problem we were having with the software, the software vendor told me that they could not proceed with troubleshooting and investigating the issue because Always Encrypted had been set on the database. Unfortunately the support technician could not tell me much about this, only that it was a road block for them and that it needed to be disabled, and that managing SQL databases to that extent was out of scope for their support.
I tried to look up how to disable or remove that feature from our database but all of the information I have found so far is about setting it up, not taking it down. I haven't tried to "tinker" with this at all on my own as what I have read so far tells me that this is definitely something that should not be touched without sufficient familiarity with managing SQL databases to know that modification of that feature on the database won't have potential negative ramifications (besides the data not being encrypted).
How can I remove or disable this feature from our database so I can get the software vendor to continue taking a look at their database?
Notes:
We have SQL Server 2017.
I don't know much about SQL Server - if a solution would have complications I might be expected to be aware of in trying it, I'm afraid I really won't be aware of them they're mentioned, which is something I'm also hoping to get from an answer (if applicable). I want to make sure I do it right.
We had an issue yesterday that we are trying to figure out. Out of nowhere everything on the database changed,
We know it was an update without a where clause, but we are just a few developers. So if any of us would have done it we would know it.
It was at a strange time of the day, very late at night and only a few ip addresses are allowed into the server.
Is there any way to get the full log with ips of all the transactions on azure?
Did anyone had a similar problem? can it be a break through?
Are there any software protections, scripts that we can add to limit this?
Is there any way to get the full log with ips of all the transactions on azure?
Few options i could think off,Even this is not possible in onpremises..if you don't have correct measures to detect this...else contact support for a request to read TLOG of the database(Azure support won't read the log,unless you have a business justification,as this involves involving many teams due to safety reasons)
1.) You could use activity log to know more details..
2.) There is an sys.event_log (Azure SQL Database) DMV ,which shows connections successfull or not .you can correlate to know the users based on your office set up..this won't show success or failures
To avoid this happening again,Audit data and Azure offers many features to know more on whats happening like
1..Get started with SQL database auditing
2. Enable rules to get alerted when some thing happens..
Enable Auditing and Threat Detection on the server if you hadn't
For more information, please read this page.
Note for bounty: please answer only if you know a tool that can monitor what changes in the same db, don't mention tools that compare 2 dbs. A visual tool, like Embarcadero Change Manager is appreciated.
I'd like to have a tool that allows me to see only "what changed" in a db, given a specific action.
Scenario can be:
1) start monitoring (with the tool)
2) user performs an action on GUI (like clicking the button "apply" after having changed the telephone number of a customer)
3) stop moniroting: show changes (with the tool) (in this case I should only see that the Address field has been changed)
Embarcadero's Change manager does this, but it does also many other things, and it is expensive. I am looking for a simpler tool that does only this.
Note: I don't need schema comparison, just simple data comparison.
If you have SQL Server 2008 Enterprise Edition you can use Change Data Capture to expose the transaction log in a more usable format than DBCC LOG dbname,3. See http://msdn.microsoft.com/en-us/library/bb522489.aspx for more information.
Check out the Lite/Free version of the various xSQL tools:
http://www.xsqlsoftware.com/LiteEdition.aspx
The have an object-level compare, as well as a data compare tool.
Those don't work "on the fly", but you can always have one database as a reference, and compare your current one against that baseline.
You can make Database Snapshots (quickly enough) and then compare with working DB. Both issues can be solved with free tools.
For free, one option is to use DBCC LOG dbname,3 to dump the transaction log.
Probably be fun interpreting the output, but certainly doable.
The other free alternative is to put audit tables in place and put auditing triggers on all your tables. This is a bit more flexible than change data capture because you can specify some additonal things that change data capture doesn't capture.
Profiler is also a tool that you can use to see what query the app sent to the database which should tell you what was changed in many cases. This is a less permanent solution than auditing, but consider if auditing is something that you would find useful in the logn run.
I can't imagine ever managing a database without setting up auditing. It's just too useful for fixing bad data changes or findong out who made a particular change.
The most obvious tool would be SQL Profiler. It will monitor every SQL statement, and thus every data change, that gets sent to the server and show you metrics about that statement, the account under which the statement was executed and a host of other pieces of information and it comes free with most SQL Server versions. If you only want to see data changes, you can add filters to only show Insert, Update and Delete statements.
If what you are trying to do is compare two databases to see what data is different between them, then I'd recommend something like Red-Gate's Data Compare (no I do not work for them). It is not free but invaluable for this type of column value by column value comparison.
I am not a DBA by any means, but being a web developer means that I will have to install, setup, and administer databases. In the past, I have just followed the default installation for SQL Server. Over time, I have grown smarter and learned that default installations almost always leave doors open and leak.
So...What are the critical settings that should be thoroughly evaluated when installing SQL Server 2005 for someone of my caliber? or 2008? Or is every setting "critical?"
Any good resources that will guide through a "proper" setup of SQL Server 2005?
Every setting is critical - but the things I always double check are:
Authentication type - Integrated or SQL? If SQL, make sure you put in a very strong sa password.
Service Accounts - think through what you want for the accounts. I generally create a domain user for each service separately, and run them with least priviledges.
database paths. Decide up front where you want your system databases & user databases - its much easier to do that during the install than deciding after the fact.
Though this has mostly gone away with 64-bit, I always make sure that "AWE" is enabled if SQL is the only thing running on the server and it's 32-bit. This way, SQL Server has access to all the memory the server has (up to 3GB in a 4GB server) instead of being restricted to the normal 2GB.
I second the opinion that they're all important, and they all have different purposes, so it's a matter of your environment.
Most settings can be accepted with the default settings. SQL 2005 has been changed to be more secure by default.
Be sure to do the steps to prepare accounts to use.
You might also look at your server hardware and try to separate OS, SQL Binaries, Data and Logs onto separate drives.
http://msdn.microsoft.com/en-us/library/ms143516.aspx - for all the juicy details.
Post install, you should set up dbmail and then set up maintenance plans that notify you on failure of backups or maintenance.
Drive configuration! Where you'll place your log and database files is of absolutely paramount importance in terms of performance
My number one setting to check is the server's collation. This will control the collation of the system databases, and you should ensure that the new server's collation is the same as the old one to avoid collation errors. Ideally your user database will be the same collation.
If the two collations are different, and you compare varchar data from TempDB to varchar data from your user database, you'll need to specify the collation.
Just about every other setting can be changed later, but server collation is one that you're stuck with for keeps. (Technically, you can rebuild the system databases with a new collation, but it's not worth the effort, and still requires you to run Setup again).
The Microsoft documentation in Books on Line and elsewhere is pretty thorough and accurate. I think it's the best documentation that Microsoft does. So I'd be rigorous about "RTM" before anything I would write here, which would be incomplete and inadequately explained in any case by comparison.
That said, the first priority should be Do No Harm. I've seen many more cases where imperfect understanding of the consequences of changing the settings has caused problems, than that the default settings need to be altered. (Note: This advice does not apply to MySQL, whose defaults are pretty random IMHO.)
I use an sql server regularly and have recently been getting frustrated by the performance. It would be difficult for me to get direct access to find out the hardware so:
Is there a direct way in management studio to assess performance or find out the exact hardware.
Alternatively does someone have a set of test sql procedures I could try and ideally compare to other results to get an idea of it's performance.
So far I have setup a few quick queries on my local machines sql express server just as test these seem to run quicker than the sql server on the network which is meant to be high performance although no one knows when it was last upgraded I have a feeling it hasn't been for 6 or 7 years. Obviously these test don't account for the possibility of others querying at the same time or network transfers of results... Hopefully someone has a better solution.
You can't just ask your server guys? Seems like there's a fair bit of mistrust if you can't get hardware metrics. Count of CPUs, total memory, etc.
If there's that amount of mistrust, even if you found the answer from the database server, rectifying it would be impossible. If you can't get the current parameters, how could you get a change of hardware passed the server guys?
Start building rapport. The best line in the world to get someone on your side is, "I'm in trouble and I need your help..." You've elevated them and subjugated yourself, you've put them in a position to save you. You'd be amazed at how much you can get out of people that way.
As far as standard queries. You could look at TPC queries.
IF you are on 2005:
SELECT * FROM sys.dm_os_performance_counters
That will give you some sql only stats. You will not find much info about the machine without at least terminal access. In the sql startup log you can see some info on processors as well.
You also might try updating your references in your server. I had an issue a while back that 1 query returned in 100ms and an identical query in 5+ minutes and the only difference between the 2 was a Capital letter in the table name in my query (whih obviously shouldn't matter).
After some searching and SO-Questioning, I found that I needed to update my statistics. Could it be something like this is needed for your database / SQL Server too?
This sort of thing can be very political, especially in a firm with an endemic CYA culture (which describes most financial services companies). If there's no reasonable
expectation of a good working relationship with the production staff, A few approaches are:
Look at the query plans of the
queries. Check that they are
sensible (using indexes when they
should etc.)
Make it formal. Ask their manager
to get the specifications of the
machine, the disk layout and server
configuration and the last time
statistics were updated on all
tables and indexes. Make it clear
that the machine appears to be
under-performing.
If the statistics are out of date,
get them updated.
and one more
SELECT * FROM sys.dm_os_sys_info