I would like to get Logs or SQL executed on a perticular Date. I tried with v$sql and v$sqlarea. But its not giving old logs. Please help. I need to investigate a big mistake happened on last month.
The only option I see is to restore an old backup to an auxiliary database and try to find the exact time when the mistake happened.
Afterwards you can compare the current database with the auxiliary database and restore the data manually with export or database link + standard sql.
It depends on what went wrong this will be pretty difficult. In any case I wish you good luck!!
Related
I'm gathering information about the database by executing time-based SQL injection attacks (in lab environment). I discovered the current database user and the current database name. But now I don't know the way to get names of the first, the second, the third [,...] tables in that current database. Is there any way can help solve the problem?
I'm working with PostgreSQL, but if you know any way in another DBMS, please tell me, I'm so so grateful!
To list all tables in the current database, you can run the \dt command in psql.
I was meant to update a single column of a record in th database but i forgot to specify the id and every single record has now been updated! is there a way i can roll back the data please help!
I was meant to run the following statement :
Update Table set Cusname = "some name" where id = 2;
but i actually ran the following:
update Table set Cusname = "some name"
now every single cusname column has the same name . please help
Please help !
There's not much you can do... this is why you have a good backup strategy in place (and, ideally, don't execute any "ad hoc" t-sql in a production database before testing in a test database, then copy/paste the statements to help avoid these types of errors in the future).
Pulling info from the comments, you can start off by doing something along these lines: Can I rollback a transaction I've already committed? (data loss)
(this is for PostgreSQL, but the idea is the same... stop the server, backup all relevant files, etc).
If you have transaction logging and log backups, you can attempt a point in time restore, but this must be set up prior to your error. See here: Reverse changes from transaction log in SQL Server 2008 R2?
Your best bet in this case may be to spend some time working on resolving without restoring. It looks like you updated your customer names. Do you have another source for customer information? Can you compile an external list of customers and, say, addresses, so you can do a match on those to reset your db's customer names? If so, that might be a much easier route, getting you most of the way to a full recovery of your bonked field. If you don't have a ton of data, you can do this and fill the rest in manually. It's a process, but without a good backup of the db to revert to, it may very well be worth looking at...
Also note that if the database is hosted on a cloud based S/P/Iaas, you may have deeper level backups, or in the case of "SQL Database" (e.g., SQL Azure), point in time backups are set up out of the box even for the lowest service plans.
I have a weird issue I've never ran into before. I have a stored procedure that joins a bunch of data. When I do an update on a table that is found in one of the joins it doesnt update, until say 20-30 seconds later, or not at all. I see the value updated in the actual table, but the stored procedure has the old value. I didnt think stored procedures could cache like this, or delay like this. Where should I look to fix this?
Try aliasing all of your tables and using the correct alias in the SELECT portion of your query.ff
Unfortunately there is some caching possibly of the old query plan for the previous version of the stored procedure. It seems like a bug in SQL Server. After a short period of time, it seems to update it but yes - pretty sure it's a bug.
Source: using SSMS on SQL Server 2012 -> 2017 for large data management
I use an application connected with an sql database. I found using the profiler that the application runs an update query with a syntax error. I don't have access to the application's source code. The result is that the record is not updated. Is there a way to modify the query every time it is executed with something like trigger? I can't use INSTEAD OF because there ism't any record updated or inserted.
This answer
https://stackoverflow.com/a/3319031/1359088
suggests a way to log to a text file all the errors. You could write a little utility and schedule it to run every hour or whatever, which could read through this log, find the erroneous sql statements, fix them, then run them itself.
I've an SSIS package that runs a stored proc for exporting to an excel file. Everything worked like a champ until I needed to a do a bit of rewriting on the stored proc. The proc now takes about 1 minute to run and the exported columns are different, so my problems are the following;
1) SSIS complains when I hit the preview button "No column information returned by command"
2) It times out after about 30 seconds.
What I've done.
Tried to clean up/optimize the query. That helped a bit, but it still is doing some major calculations and it runs just fine in SSMS.
Changed the timeout values to 90 seconds. Didn't seem to help. Maybe someone here can?
Thanks,
Found this little tidbit which helped immensely.
No Column Names
Basically all you need to do is add the following to your SQL query text in SSIS.
SET FMTONLY OFF
SET NOCOUNT ON
Only problem now is it runs slow as molasses :-(
EDIT: It's running just too damn slow.
Changed from using #tempTable to tempTable. Adding in appropriate drop statements. argh...
Although it appears you may have answered part of your own question, you are probably getting the "No column information returned by command" error because the table doesn't exist at the time it tries to validate the metadata. Creating the tables as non-temporary tables resolves this issue.
If you insist on using temporary tables, you can create the temporary tables in the step preceeding the data flow. You would need to create it as a ## table and turn off connection sharing for the connection for this to work, but it is an alternative to creating permanent tables.
A shot in the dark based on something obscure I hit years ago: When you modified the procedure, did you add a call to a second procedure? This might mess up SSIS's ability to determine the returned data set.
As for (2), does the procedure take 30+ or 90+ seconds to run in SSMS? If not, do you know that the query is actually getting into SQL from SSIS? Might be worth firing up SQL Profiler to see what's actually being sent to SQL Server. [Which was the way I found out my obscure factoid.]