Additionally, NTPDate is not a service/daemon. It's a one-time command tool that immediately synchronizes the software clock. It's packaged with NTP on some Linux distributions, but not necessarily all.
I would not recommend its use on a system that is running a database. Historically, many database products don't deal well with abrupt changes in system time.
Note that the authors of ntp/ntpdate deprecate the use of ntpdate. The recommendation is to run ntpd to keep your clock continuously synced. The page where they explain why they deprecate it has lots of good information about how to use ntpd in a context where it is replacing ntpdate.
Once you have been running ntpd long enough to have a good drift file, there should be no reason to use ntpdate at all. As long as ntpd is properly configured (which the above page discusses, the important parts being that it is running with -g, and you have iburst for a good server), ntpd should be able to correct your clock quickly. If you need for some reason to wait for ntpd to get a good sync before doing something (like starting a service that needs the time to be correct), you can use the ntp-wait command.
ntpq -p will show you the status of the NTP daemon, with information about which peers it's syncing with and its opinion on the hygiene habits (or clock accuracy, if you prefer) of each.
Additionally, NTPDate is not a service/daemon. It's a one-time command tool that immediately synchronizes the software clock. It's packaged with NTP on some Linux distributions, but not necessarily all.
I would not recommend its use on a system that is running a database. Historically, many database products don't deal well with abrupt changes in system time.
Note that the authors of ntp/ntpdate deprecate the use of ntpdate. The recommendation is to run ntpd to keep your clock continuously synced. The page where they explain why they deprecate it has lots of good information about how to use ntpd in a context where it is replacing ntpdate.
Once you have been running ntpd long enough to have a good drift file, there should be no reason to use ntpdate at all. As long as ntpd is properly configured (which the above page discusses, the important parts being that it is running with -g, and you have iburst for a good server), ntpd should be able to correct your clock quickly. If you need for some reason to wait for ntpd to get a good sync before doing something (like starting a service that needs the time to be correct), you can use the ntp-wait command.
ntpq -p
will show you the status of the NTP daemon, with information about which peers it's syncing with and its opinion on the hygiene habits (or clock accuracy, if you prefer) of each.