The first thing I would like to see is how the processor or RAM use tomcat during the launch of your application.
If you see a lot of processor activity and an increase in RAM, then it probably loads a lot of things, for example, many classes, or does some huge pre-allocation or the like. In this case, dump streams can help you a lot, but also "lsof" (if your tomcat works in * nix environment) to see which files it works in.
However, if you see that he is just sitting there, then he is probably waiting for some kind of connection.
One of the reasons could be the connection to the database, as you expected. The database usually responds quickly, and an unsuccessful attempt to connect to the database is usually distinctly recorded somewhere, but it can still be.
Another, less well-known reason may be some XML validation. Some XML data is often loaded for a web application, and it is not uncommon to use a validating parser to load this XML. Parser validation requires a schema or DTD to validate, and the URL for a schema / DTD file is often included in XML. Thus, some parsers will try to download the schema file from the Internet to check the XML, and this can take a long time to connect to the Internet. Moreover, some parsers fail silently and simply do not validate XML, possibly after a rather long timeout. Sorry for the ambiguity regarding "some parsers", etc., but if the XML is loaded using the libraries used inside your webapp, they can use the JVM XML parser, any possible version of Xerces, any possible version for JDOM, etc. .... and even the most different libraries can use different parsers.
However, if the problem is with the connection, it is easier to see it with "netstat -anlp | grep java" (your tomcat has * nix environment, otherwise it should be "netstat -ano" on the windows) and looks for what outgoing connection it is trying to make your cat. There you can see DB connections, as well as outgoing (usually http) connections that are looking for schemes or other things.