We have an ERP Program used to create and manage stock / orders. Somehow an order has vanished - this should not be possible. It should be possible to cancel an unwanted order, but never delete it completely.
The order in question was created, printed and sent to a customer - and then disappeared. I know the Primary key and Table info, and want to search the log to see if this was somehow deleted, or perhaps there was a rollback.
How can I translate/search the log in this way?
Please note: I did not write this program, and its not my job to fix it.
I just need to diagnose the issue and contact the SW Vendor, if required, and have them fix it. As such I cannot post any code.
With so little information it is hard to give a definitive answer.
I'd start by searching the regular logs. If you have some kind of audit trail mechanism that would be a great help!
If a search through the regular logs doesn't find you the answer then I would:
Get a copy of the database
Go through the REDO logs using the appropriate DBA tools. Since I'm not an sqlanywhere DBA I would get help from one.
When I found the place in time where the order was deleted I would find any other information I could get. The user that did the commit or users that where logged on at the time (I don't know exactly what kind of information you can get here). Also, go back to the other logs you may have and check around that time stamp.
To learn exactly how to go through the redo logs of an SQL Anywhere database you should first try your google luck and then ask in Database Administrators.
Solved!!!!
The Sybase Central tool has an option (which I couldn't find in the manual and missed the first time I looked), which can translate a log file into a series of statements and create a *.SQL file.
Tools -> SQL Anywhere -> Translate Log File -> Follow wizard (which hopefully for you is in a language that you speak, for me it was not).
Related
I need to log the last time the user signed in using my node.js server. I am looking into three options. The persistence requirement is not super high, meaning that the margin of error of this record being recorded is open.
Use SQL DB and whenever the user logs in it modifies their profile account.
Record it in a server text file. So whenever the user logs on, this file will be opened and updated. The opening, recording and closing of the file will all be done asynchronously.
I'm thinking that the second option is the better on because I'm using SQL for many other operations so I prefer to not interrupting my DB as much as possible.
One concern I have for the second option is the performance hit on the server that will be caused by the frequently read and write to a local text file.
I'm curious what other people who have gone through this path thought about my thought process. Any opinions or tips are highly welcomed. Thank you.
Normally you should use a SQL database, it is a much more better way than the plain text.
The main problem with a text file is that when you log in, you can simply append a line (but what about a couple of user loggin in at the same moment ? You have not any warranty that all the access are logged), but when you want to extact the last login for a user, you should read (and then load) all the file from the start (or the end), which can cause a really worst problem than the access to the DB.
Naturally you can work out all the problems with a text file, but then you have written a lot of code to avoid a simple update query.
I don't think that, with the information you give, you should be worried about the performance of a database access in this case.
I am trying to get a list of the programs (RPG/CL/SQL) and files a service account on the iSeries has touched. The idea is that having this list we can tie specific permissions (I know this will really complicate things) to the user account in order to achieve a more secure application specific service account. Is there any way to do this and maybe get a report by running a command. Maybe there is a SQL statement?
Please excuse me if my terms are not appropriate, I am still new to the iSeries.
The audit journal will have what you are looking for....if so configured.
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzarl/rzarlusesecjnl.htm
The newest 7.1 TR includes stored procedures to allow easy read of journals.
https://www.ibm.com/developerworks/community/wikis/home/wiki/IBM%20i%20Technology%20Updates/page/DISPLAY_JOURNAL%20(easier%20searches%20of%20Audit%20Journal)
Charles
So though Charles' answer might be the one one should set up to get a thorough report. I wound up doing the following as suggested by one of my peers.
Please note that my goal though not properly explained as so, was to create an application specific user/service account for a program. This is to avoid using one with many privileges and thus gain some security.
1.Go through the source code (in my case classic ASP) and jot down all the names of the procedures used by that program.
2.Create a CL program that outputs the program references to a display file. Then export the file's contents onto Excel and massage where necessary.
PGM
DSPPGMREF PGM(MYLIB/PGM001) OUTPUT(*OUTFILE) OUTFILE(MYLIB/DSPPGMREF) OUTMBR(*FIRST *REPLACE)
DSPPGMREF PGM(MYLIB/PGM002) OUTPUT(*OUTFILE) OUTFILE(MYLIB/DSPPGMREF) OUTMBR(*FIRST *ADD)
ENDPGM
I was told however that service programs references cannot be displayed with DSPPGMREF. So the following was done for those.
PGM
ADDLIBLE LIB(ABSTRACT) POSITION(*LAST)
MONMSG MSGID(CPF0000)
WRKOBJR OBJ(SRVPGM01) OBJTYPE(*SRVPGM) OUTPUT(*OUTFILE) OUTFILE(MYLIB/WRKOBJR) MBROPT(*REPLACE)
WRKOBJR OBJ(SRVPGM02) OBJTYPE(*SRVPGM) OUTPUT(*OUTFILE) OUTFILE(MYLIB/WRKOBJR) MBROPT(*ADD)
WRKOBJR OBJ(SRVPGM03) OBJTYPE(*SRVPGM) OUTPUT(*OUTFILE) OUTFILE(MYLIB/WRKOBJR) MBROPT(*ADD)
ENDPGM
Thank you for all your help. I apologize that my answer is a little more specific than my question but in the end this was what I wanted to achieve, I had to generalize to ask the question. I'd thought i'd post post my answer anyways in case it helps someone in the future.
I altered a stored procedure and unknowingly overwrote some changes that were made to it by another developer. Is there a way to undo the changes and get the old script back?
Unfortunately I do not have a backup of that database, so that option is ruled out.
The answer is YES, you can get it back, but it's not easy. All databases log every change made to it. You need to:
Shutdown the server (or at least put it into read-only mode)
Take a full back up of the server
Get a copy of all the db log files going back to before when the accident happened
Restore the back up onto another server
Using db admin tools, roll back through the log files until you "undo" the accident
Examine the restored code in the stored proc and code it back into your current version
And most importantly: GET YOUR STORED PROCEDURE CODE UNDER SOURCE CONTROL
Many people don't grok this concept: You can only make changes to a database; you can't roll back the stored proc version like you can with application code by replacing files with their previous versions. To "roll back", you must make more changes that drop/define your stored proc.
Note to nitpickers: By "roll back" I do not mean "transaction roll back". I mean you've made your changes and decide once the server is back up that the change is no good.
"Is there a way to undo the changes and get the old script back?"
Short answer: Nope.
:-(
In addition to the sound advice to either use a backup or recover from source control (and if you're doing neither of those things, you need to start), you could also consider getting SSMS Tools Pack from #MladenPrajdic. His Management Studio add-in allows you to keep a running history of all the queries you've worked on or executed, so it is very easy to go back in time and see previous versions. While that doesn't help you if someone else worked on the last known good version, if your entire team is using it, anyone can go back and see any version that was executed. You can dictate where it is saved (to your own file system, a network share, or a database), and fine-tune how often auto-save kicks in. Really priceless functionality, especially if you're lazy about backups and/or source control (though again, I stress, you should be doing these things before you touch your production server again).
You could look through the cached execution plans and try to find the one where your colleague made his changes and run the relevant parts again.
EDIT
Although Bohemian looks to have a good answer if you've got the changes in the TL, this is what I'm talking about. Review the SQL text for the plan.
SELECT cached.*,
sqltext.*
FROM sys.dm_exec_cached_plans cached
CROSS APPLY sys.dm_exec_sql_text (cached.plan_handle) AS sqltext
But as squillman points out, there is no execution plan for DDL.
You won't be able to get it back from the database side of things. Your options at this point are pretty much limited to 1) recover from backup, 2) go to source control or 3) hope that someone else has a copy still up in an editor somewhere or saved to a file.
If neither of these are an option for you, then here's the obligatory "you should take regular backups and use source control"....
I'm way late to the game on this but I did this same thing this morning and found I had forgot to save my script at some point in the past and needed to recover it. (It will be in source control after I get done fixing this!!!)
Some people mentioned restoring from a backup but no one really mentioned how easy this is if you have a back up. Moreover, you aren't locked into rolling back the production database. I think this is key and assuming you have a back up I would say this is a much better alternative to what has been voted up to the best answer.
All you have to do is take your back up and restore it to a new database. Pull out the sp you are looking for and voila, you've recovered the missing code.
Don't forget to drop the newly created database after you've recovered the missing file.
I had the same problem, and I don't have the confidence to go restoring from log files to another server. I was pretty distraught until I realised the solution was very simple...
Press Ctrl-Z over and over until I had undone my changes and the run the ALTER PROCEDURE again.
Admittedly I was pretty lucky that I still had it there to revert to but it really is the easiest fix. Probably a bit late now though.
If you have scripted the stored procedure out from management studio object explorer this will work.
Before expand and collapse the object explorer just scroll and point to the stored procedure you have opened. Script the stored procedure as create or alter to then you can get the previous version of the proc since the object explorer doesn't refreshed yet. This is always my life saver.
Of course my boss is out the day something goes wrong. It's just me, an inexperienced little student here, trying to get our website back up and running. All alone.
The oracle database our site pulls data from won't let me connect (throwing the error on our site), giving me the error: ORA-00257. In full:
ORA-00257: archiver error. Connect internal only, until freed.
Cause: The archiver process received an error while trying to archive a redo log. If the problem is not resolved soon, the database will stop executing transactions. The most likely cause of this message is the destination device is out of space to store the redo log file.
Action: Check archiver trace file for a detailed description of the problem. Also verify that the device specified in the initialization parameter ARCHIVE_LOG_DEST is set up properly for archiving.
All I have is the username and password into the database. And of course the Oracle SQL Developer client.
My question is: am I equipped to fix this problem? If so, how? If it's fixable (by me), and someone can explain it, can they explain it very, very slowly and painstakingly?
If anyone can help, even if it's just to say, "You're doomed!" ...thank you in advance.
You've probably used up all of the space on the disk/partition where the archive logs are being written. Your DBA or DBA-standin should be involved at this point, because losing these logs will affect your ability to recover the database - Oracle is helping you by refusing transactions to make sure the database can be recovered if that is necessary.
Part of the setup routine for the product I'm working on installs a database update utility. The utility checks the current version of the users database and (if necessary) executes a series of SQL statements that upgrade the database to the current version.
Two key features of this routine:
Once initiated, it runs without user interaction
SQL operations preserve the integrity of the users data
The goal is to keep the setup/database routine as simple as possible for the end user (the target audience is non-technical). However, I find that in some cases, these two features are at odds. For example, I want to add a unique index to one of my tables - yet it's possible that existing data already breaks this rule. I could:
Silently choose what's "right" for the user and discard (or archive) data; or
Ask the user to understand what a unique index is and get them to choose what data goes where
Neither option sounds appealing to me. I could compromise and not create a unique index at all, but that would suck. I wonder what others do in this situation?
Check out SQL Packager from Red-Gate. I have not personally used it, but these guys make good tools overall and this seems to do what you're looking for. It let's you modify the script to customize the install:
http://www.red-gate.com/products/SQL_Packager/index.htm
You never throw a users data out. One possible option is to try and create the unique index. If the index creation fails, let them know it failed, tell them what they need to research, and provide them a script they can run if they find they have a data error that they choose to fix up.