4 Hidden JD Edwards Cleanup Tasks That Boost Performance

So to shift to the next section and next topic here, what is security history?

So security history is, I think it's a crucial auditing feature that tracks user activity, their login, people's logins, people's logouts, any changes to the user profiles. If you added roles or took away roles, that information is captured in that table, which is F9312. It's, it's a great audit trail table basically for user authentication and any administration security changes, I mean including password changes. You'll find out if somebody changed password for a user ID or if the user themselves did it. It's logged in that table really.

So is there anything else that would be in that table that would be beneficial or are those like the main ones?

Those are the main ones. It's usually your if, if your security history is set to 1, there is a setting that's in the JDEINI section of your enterprise server that has to be turned on. It will then capture your sign in & out activity. So it's every single login. So it's an event type 01 for sign in or login and then log off as a 02. It includes the time stamps and if it was successful or if it was a failure. So if somebody's password isn't working, it'll say failure or failed. But it didn't allow them in and you can kind of dig into it to see that their user ID was disabled or it's not working for whatever reason. Maybe it doesn't have a a system user attached to it or something along that lines, but it also includes the password changes.

Both self-service updates and if an administrator did it or reset their password, and that's an event type 04 that shows profile modifications, it'll log any changes to that user ID that took place in the P0092. It shows your sign in or your password changes, which is also logged in the F98 OW SEC. And then any other administrative changes, you know, audit records that updates for those roles to those user assignments to menu security to it's, it's a lot.

It's perfect. It's super helpful when you're trying to see if users have logged in, if you're trying to clean up user accounts, you can actually look to see when the last time was that they logged into the system and know whether that account, that account is valid anymore or if that user ID is still needed.

Yeah, that's so it's always tracking when people are logging in, the different password changes, everything like that.

But how did, how does that affect performance, maybe even storage and even compliance?

I would say storage. That's where I set the purging of the sign in & offs. The 0102 records might be a great idea. There's no real risk, I don't think just an overabundance of data in that table using up, you know, valuable disk space on your enterprise server and it it might slow down performance when logging in. I don't I've never heard of that or seen that, but just it's something to note I guess.

Yeah.

But it would there be like that the side of it of maybe there is an issue that you run into and maybe it was from X amount of days before. Is there is that the main risk of purging this data a little too quickly?

It could be yeah, for sure. JD Everest does deliver like the the UBE, I think it's R9312 where you can purge that information. But it's, it's one of those orders, not a clear answer. Like it depends how much information you want to keep out there. Some people keep up to a year, some people keep six months because they have so many users logging in and logging out. It's it varies. It's one of those up to you. It really is.

So on the other side, then what's the risk of never purchasing this data again?

Just a very large table using us a lot at this base and and. I think, I think that's it. I mean, I really, I don't see much of A risk with that one.

Yeah, probably it, it might affect performance in that way too, of slowing it down because it has to add to an even longer table and creating even more disk space in that way. So I could see that, Yeah.

How about that?

So let's talk about the clean up. What policies should teams follow when cleaning this data?

Again, it's going to relate back to what does your company want to keep? I mean, I, I have a version of the R9312 that I either, I run monthly as part of my system hygiene on, on customers that it can either keep a rolling, you know, six months of information or whatever that date or time may be. And I then I have another one that that basically they run it once a year and just clean up the whole past year. And then they just capture or you know, if they're keeping two years out there, they clean up the the one year and keep a year's worth out there. So it varies. It's a hard one.

Yeah, it is.

Yeah.

I'm sure that it also goes into compliance as well of what are the industry standards? What do you have to adhere to? What types of data are you using? So yeah, definitely you're right when it comes to it varies, depends on what types of data that you are actually utilizing. If it is sensitive data versus not sensitive data, who has access to it? And yes, if there are certain people in your company that have access to that sensitive data and certain people that don't, it could differ even within your own company, which is funny to think about, but maybe a headache for some people that are out there.

But you know, that's why we have you Diane, to help us through this.

Great.

Just bang me in the head if you all right.

So moving on to the fourth problem here, forgetting the object usage tracking when it's enabled.

If you have object usage tracking enabled, why is this item on this list and even as an issue?

Well, I I think let's let's define what it is first. So object user tracking is is a built in feature that monitors which applications, which batch programs, which business functions are actually used by the users and the system it comes disabled with with the software itself. So so you or someone else would have had to enable it and configure it using the application P980042 TI think it is, but it's great with helping IT teams plant upgrades, optimize performance by identifying unused objects, streamlining security. You know, realize that nobody's using this application, but yet it's in Star public and it doesn't need to be.

You can analyze compliance items, you know, to show who uses what, when and where within the system. And it can provide crucial insights for impact analysis before applying patches like ESUS or Asus or just for general system management. It's it's a great thing that Oracle delivered to us, especially for helping with upgrades.

I think that's probably one of the biggest things is people want to realize or you know, what's being used or is it, is it being used is an object actually being used or a version being called or along that lines. So that's, that's usually why most people will turn it on is to see all of that information and capture that information.

But then people forget it's on and it, it can grow to be very large. And those tables can be huge because, again, it's capturing every ube and every application that every user is losing. Unless you have that skinny down, there is a configuration table you can do to just skinny things down and say, I only want to know about this. But most people don't do that. They leave it wide open.

Interesting.

So I would assume that that would also affect performance in a way of like, how could you walk me through how that would affect performance?

Yeah, I think it would definitely increase database activity for sure. Like I said, each, each event is tracked. So like each, each time the user launches it, it calls us, creates a system, call it, it'll create records in the F-989-O2 and I think F98911 tables, adding write operations and database loads to that.

I mean, there will also be resource consumption because the the tracking process itself uses the system resources, CPU, memory to collect and to write all that data, potentially impacting overall system performance and responsiveness.

So I think it, I think it does. But again, I don't think it's, it's large enough that people are going to be like, Oh yeah, that's why my system is super slow. But it's definitely going to, I think it could be a little bit of a hit.

Yeah.

So it might help a little bit. And heck, if you go through all this list and start cleaning everything up, you might see a change from, oh, this is taking a minute to load to maybe this is only taking 30 seconds, maybe even less to load in certain instances, obviously.

But you did mention something a little bit earlier when we were talking about this. But what would be the steps to clean this up or at least minimize what is stored?

Yeah, that's again the Oracle. Oracle delivered a purge. Purge UBE for us to use. That'll clean up all that. That object usage tracking detail in the F98911 table. I think it is by running the R98911. I believe there's AP on the end for purge, which is that UBE that again, it's up to what your company, you know wants to keep and how much they want, how much information they would want to keep.

But you can run that UBE to clean up all of that detail that's may not be needed. I mean, if you turn this on and in 2020 and you know, you forgot that it's there, it's not gathered almost six years of data, that's that table's got to be ginormous.

And it would really good to clean that up and delete some of that older data, especially if you upgraded say in 2024 and you use it all for that. But now again, it's still on. And is anybody looking at it? Do you really need to have it on?

You can minimize what the amount of data that is being written to it. You can add object names to the configuration list of things to exclude and things to not track. Or again, you could just have it wide open or turn it off all together and then wipe out the table your dated.

Your DBA will probably love you because it'll be like whoa the space.

So if you want to make your DBA happy, clean up your data.