After inspecting all the grants, a single database takes another 5 minutes to inspect.ĭataGrip will run "select grantee from information_er_privileges group by grantee " which identifies 307 records where it runs a SHOW GRANT for each. I have watched the database logs (~/.cache/JetBrains/DataGrip2020.2/database-log/database.log) and identified that DataGrip spends 12 minutes running SHOW GRANT statements. ![]() I'm hoping there might be a solution because I'm pretty working without the benefits of an introspected database schema because the task ultimately never completes before I need to move the next database and inspection starts all over again. If you alter a table in any database, it seems to trigger a full re-inspections of everything where it could just re-inspect the one table that was altered. When it queries database users, it does this one user at a time. I'm using a local mysql CLI - so it's not network lag.Īside from DataGrip having very slow execution of queries, it seems to skip obvious optimisations. If I run that same query using the mysql CLI it takes a fraction of second. Each query it fires can take up to 2 seconds to complete. If I tail the log to see what DataGrip is doing I can see that it's queries are excessively slow. Having maybe 4 database inspected with 200 tables each can take hours to complete. However, as of a recent version (perhaps 2019.3) DataGrip became excessively slow. I'm having the same issue with excessively slow schema inspections.ĭataGrip has always been a poor performer (in comparison to HeidiSQL which can very rapidly inspect an entire database.) As a result, where our servers may have up to 100 database, I toggle which ones I'm working with so DataGrip only inspects a couple. Using it for the first time with was looking so good, I was so excited to see packages in full detail and not have to be in SQLDeveloper from Oracle.but I might have to switch back to that for a bit. I love DataGrip and used it with Postgres and Snowflake at my last place of work with no issues. I'm really hoping that I didn't just bring down my organization's oracle server to it's knees from an introspection on a large schema that took a while. I tried to cancel it and it just kept hanging, ultimately I force quit the application and then wasn't able to connect back to the database. I ended up walking away as I was kinda signing off for the day, but came back and hour and some change latter and it was still introspecting, granted the schema was massive. I had been doing some work, then wanted to add an additional schema to the managed schema list and it started introspection. For more details, see DBE-5060.And today, I'm nervous that I might of bogged down my organization's oracle server because of this product's problem with introspection. Note that the execution of this statement might be slow. You can obtain correct sources by using SHOW CREATE. ![]() The source code for triggers and routines is broken in the 'information_schema' of MySQL (see Bug #66414). In the Expert options, We have the following two checkboxes,īy default, "Use SHOW CREATE for source code" is selected, The explanation of that option is below, Use the SHOW CREATE statement to generate the CREATE statement for an object source code. To avoid the error - missing source code:Ĭlick on "Data Source Properties" (1 in the below image) -> Advanced (2 in the below image) -> Expert options (3 in the below image) We will receive the below error when we try to extract the Stored Procedure DDL, How to fix - missing source code error on Datagrip?
0 Comments
Leave a Reply. |