Your query seems to from v10 and thus is missing two reg types. 'pg_catalog.regcollation' 'pg_catalog.regnamespace'

(I don't have sufficient reputation to comment yet) Have you compiled the package spec? And what happen when you compile the views? alter package DBMS_AUDIT_UTIL compile; alter view FGA_AUDIT_TRAIL VIEW compile;

I would follow this path: Generate dacpac from the root database if you don't have already a dacpac as update. Generate a scirpt of https://docs.microsoft.com/en-us/sql/tools/sqlpackage/sqlpackage?view=sql-server-ver15 commands using that dacpac as source, having one command for each target database. Execute those commands. In this way you can create a dacpac from your root database: sqlpackage.exe /action:extract /targetservername:server_name /targetdatabasename:root_database_name /targetfile:"\root_database_name.dacpac" then you have to apply it to each database you need. To apply a dacpac to a database you have to use this command \SqlPackage.exe /Action:Publish /SourceFile:"\root_database_name.dacpac" /TargetDatabaseName:db_name /TargetServerName:server_name You should have a a way to select all database you have to applay that dacpac select name from sys.databases where name like 'mydb%' -- or another filter you have so if you puth all together, you can do something like this: select '\SqlPackage.exe /Action:Publish /SourceFile:"\root_database_name.dacpac" /TargetDatabaseName:' + name +' /TargetServerName:server_name' from sys.databases where name like 'mydb%' In the query output you will have all the commands needed. This is an easy option. Probably there are better... Hope to be of help.

My workstation can do about 100K-150K LIO/CPU Second. A Logical IOs (LIO) is reading a single 8KB page from page cache. Ie when running a big parallel scan of a cached table with a trivial query plan I get IO stats like: Table 'frs_big'. Scan count 9, logical reads 519631, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0. (1 row affected) SQL Server Execution Times: CPU time = 5109 ms, elapsed time = 655 ms. And with MAXDOP 1 the same scan takes only 3625 CPU ms. And it's running Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz. Over the period you've got 22,902,891,616KB of Logical IO which, each LIO is 8KB, so 22902891616/8 LIO, and 20,393,171ms of CPU time. So with q as ( select 22902891616/8 lio, 20393171 cpu ) select 1000*lio/cpu lio_per_cpu_sec, lio/(24*60*60) lio_per_sec from q or lio_per_cpu_sec lio_per_sec --------------------------------------- --------------------------------------- 140,383 33,134 140,383 LIO/CPU Second. So the number of logical IOs roughly corresponds to the total CPU usage, and you're averaging 33,000 LIO/Sec over the 24 hour period. Given that you upgraded to 2019 with all the newer optimizer behavior you probably have some bad plans that are causing excessive scanning, but the speed of the server, and the moderate size is keeping your cache hit ratio very high and keeping the perceived performance acceptable. I'm not sure what that memory metric means. This is the query behind the report: exec sp_executesql N'WITH DateGenerator AS ( SELECT CAST(@interval_start_time AS DATETIME) DatePlaceHolder UNION ALL SELECT DATEADD(d, 1, DatePlaceHolder) FROM DateGenerator WHERE DATEADD(d, 1, DatePlaceHolder) < @interval_end_time ), WaitStats AS ( SELECT ROUND(CONVERT(float, SUM(ws.total_query_wait_time_ms))*1,2) total_query_wait_time FROM sys.query_store_wait_stats ws JOIN sys.query_store_runtime_stats_interval itvl ON itvl.runtime_stats_interval_id = ws.runtime_stats_interval_id WHERE NOT (itvl.start_time > @interval_end_time OR itvl.end_time < @interval_start_time) GROUP BY DATEDIFF(d, 0, itvl.end_time) ), UnionAll AS ( SELECT CONVERT(float, SUM(rs.count_executions)) as total_count_executions, ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) as total_duration, ROUND(CONVERT(float, SUM(rs.avg_cpu_time*rs.count_executions))*0.001,2) as total_cpu_time, ROUND(CONVERT(float, SUM(rs.avg_logical_io_reads*rs.count_executions))*8,2) as total_logical_io_reads, ROUND(CONVERT(float, SUM(rs.avg_logical_io_writes*rs.count_executions))*8,2) as total_logical_io_writes, ROUND(CONVERT(float, SUM(rs.avg_physical_io_reads*rs.count_executions))*8,2) as total_physical_io_reads, ROUND(CONVERT(float, SUM(rs.avg_clr_time*rs.count_executions))*0.001,2) as total_clr_time, ROUND(CONVERT(float, SUM(rs.avg_dop*rs.count_executions))*1,0) as total_dop, ROUND(CONVERT(float, SUM(rs.avg_query_max_used_memory*rs.count_executions))*8,2) as total_query_max_used_memory, ROUND(CONVERT(float, SUM(rs.avg_rowcount*rs.count_executions))*1,0) as total_rowcount, ROUND(CONVERT(float, SUM(rs.avg_log_bytes_used*rs.count_executions))*0.0009765625,2) as total_log_bytes_used, ROUND(CONVERT(float, SUM(rs.avg_tempdb_space_used*rs.count_executions))*8,2) as total_tempdb_space_used, DATEADD(d, ((DATEDIFF(d, 0, rs.last_execution_time))),0 ) as bucket_start, DATEADD(d, (1 + (DATEDIFF(d, 0, rs.last_execution_time))), 0) as bucket_end FROM sys.query_store_runtime_stats rs WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time) GROUP BY DATEDIFF(d, 0, rs.last_execution_time) ) SELECT total_count_executions, total_duration, total_cpu_time, total_logical_io_reads, total_logical_io_writes, total_physical_io_reads, total_clr_time, total_dop, total_query_max_used_memory, total_rowcount, total_log_bytes_used, total_tempdb_space_used, total_query_wait_time, SWITCHOFFSET(bucket_start, DATEPART(tz, @interval_start_time)) , SWITCHOFFSET(bucket_end, DATEPART(tz, @interval_start_time)) FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY bucket_start ORDER BY bucket_start, total_duration DESC) AS RowNumber FROM UnionAll , WaitStats ) as UnionAllResults WHERE UnionAllResults.RowNumber = 1 OPTION (MAXRECURSION 0)',N'@interval_start_time datetimeoffset(7),@interval_end_time datetimeoffset(7)',@interval_start_time='2022-01-03 15:57:04.2571919 -06:00',@interval_end_time='2022-02-03 15:57:04.2571919 -06:00' and ROUND(CONVERT(float, SUM(rs.avg_query_max_used_memory*rs.count_executions))*8,2) as total_query_max_used_memory, doesn't seem to me to be a terribly useful metric.

You are correct. For a Windows Cluster, you can only upgrade to the next version. Even though the Availability Group is the only resource, it is still built on Windows Clustering and must follow those upgrade rules. SQL Server can be upgraded anytime before or after upgrading the cluster. So if you need to get from Win2012R2 to Win2019, then you would follow these basic steps. Upgrade all cluster nodes to Win2016 Update the cluster function level to 2016 Upgrade all cluster nodes to Win2019 Update the cluster function level to 2019. https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-operating-system-rolling-upgrade

There was never a PostgreSQL version 9, but that is beside the point here. Most of the time, you won't have a problem with such an upgrade. But each major version of PostgreSQL introduced some incompatibilities, which are documented in the release notes of the base release (9.6, 10, 11, ...), so you cannot be certain. You should read through all these release notes to get an idea what problems you may encounter, but the important part is that you test your application thoroughly. A test is the only way to make sure you won't run into problems.

From what I read in the man page of pg_upgradecluster, there might be a typo in your command. Here is the synopsis from the man page: pg_upgradecluster [-v newversion] oldversion name [newdatadir] Either keep -v and explicitly add the new version number : pg_upgradecluster -V -v 14 13 main /srv/local/postgresql/data/14 or remove -v altogether (will default to the latest available version) : pg_upgradecluster -V 13 main /srv/local/postgresql/data/14

I wrote a https://gist.github.com/deric/0e45b86650f94f144084c0007ceb15c7 to perform additional upgrade checks (it does NOT replace pg_upgrade --check). Any non-default modifications to role_table_grants regarding pg_pltemplate would cause a fatal error during pg_upgrade process, basically it does following: for db in $(psql -tc "SELECT datname FROM pg_database;") do if [[ "${db}" != "template0" ]]; then dump=$(pg_dump --schema-only --quote-all-identifiers ${db} | grep pg_pltemplate) if [ ! -z "$dump" ]; then echo "ERROR: ${db} contains pg_pltemplate modifications. pg_upgrade will fail" exit 1 fi fi done echo "OK" The script might return something like this: -- Name: TABLE "pg_pltemplate"; Type: ACL; Schema: pg_catalog; Owner: postgres REVOKE ALL ON TABLE "pg_catalog"."pg_pltemplate" FROM "postgres"; REVOKE SELECT ON TABLE "pg_catalog"."pg_pltemplate" FROM PUBLIC; GRANT SELECT ON TABLE "pg_catalog"."pg_pltemplate" TO "reader"; ERROR: postgres contains pg_pltemplate modifications. pg_upgrade will fail in that case you have to run the inverse statements: GRANT ALL ON TABLE "pg_catalog"."pg_pltemplate" to "postgres"; GRANT SELECT ON TABLE "pg_catalog"."pg_pltemplate" TO PUBLIC; REVOKE SELECT ON TABLE "pg_catalog"."pg_pltemplate" FROM "reader"; then the database should be ready for upgrade to PostgreSQL 13.

Door Number 1, 2, or 3: 2, with a dash of 3. An ownership chain should prevent permission checks on a scalar UDF referenced from a view, so a user with SELECT permission on the view should not also need EXECUTE permission the UDF owned by the view's owner. Looks like this one of the many TSQL scalar UDF inlining bugs that were present in RTM and fixed in some CU. It reproed for me on RTM and stopped after upgrading to CU14. SQL Server doesn't usually slipstream Cumulative Updates (or Service Packs*), so the installer installs RTM, and then you patch after upgrade. Usually an updated installer will be built for GDR updates, but there's no reason to stay on RTM+GDR after a major version upgrade. It also stopped doing that on RTM when I set ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF; *SQL Server 2017 and later don't have service packs, only CU's.

From the manual: At the beginning of the backup, a checkpoint needs to be performed on the source server. This can take some time (especially if the option --checkpoint=fast is not used), during which pg_basebackup will appear to be idle.

You could use Major Public Cloud Providers (AWS, Azure, GCP) or any other Location (Hetzner Cloud, Linode, digitalOcean etc) [ https://www.packer.io/docs/builders ]that is supported by https://www.packer.io/guides/hcl . With Packer you can build and maintain your system image and customize it. Each time you want to upgrade you can build a new image. By building the new image you can choose the base image version you will build on run your modifications on. Image is saved on the provider. Finally you deploy your new server with the image you created and finally you dispose the old infrastructure, with the help of https://www.terraform.io/ . Since packer read code you treat it like any other code.

I once needed to make a "version updater" for a VB application. The abstract of the work would be, the user clicks on the updater(he even knows that there is another executable beyond that) that, in turn, searches the FTP repository for a newer version, having it low, uncompresses, copies the files to the correct folders, runs sql scripts in the bank, updates operating system records and in the end runs the application. Advantages of this format - no cost Disadvantages of this format - much code written for a simple taskAnother means, much more interesting, is to use a continuous integration server, type http://hudson-ci.org/ , in this way voc. would continue to need a "updating" but could separately package your libraries and decrease the amount of code, then the maintenance, in your updater.A third, I thought of her now, but I think it's even cooler. https://maven.apache.org/ with your application, use existing plugins or create yours for the purpose of recovering releases (SCM, ftp or continuous integration server), update database (scripts or hibernate).Finally, since you will not be able to overwrite a running file the simplest way is to have an updater (today it is very common, such lauchers) and that your client only "know" it, being from it the responsiveness to update and/or perform what today is your "main" file.I don't know a solution ready for this case, I hope I've given a light in your search.

Old oracle home is no more useful after upgrade. To safe remove it you should do either: Start > Installation Products > Oracle Universal Installer. from here you can select deinstall and remove the old oracle home. One alternative is to manually perform the process running the command: setup.exe -silent -detachHome ORACLE_HOME="C:\product\DBHome" ORACLE_HOME_NAME="DBHome" You have to replace ORACLE_HOME_NAME and ORACLE_HOME with the one on your system. To find them, in Windows, first get the value of \\HKEY_LOCAL_MACHINE\\Software\Oracle\inst_loc. in your windows registry. Then navigate in the inventory location and open the file: inventory.xml here you'll find some lines like: This is your line. Location is the one you know, write down the name and perform the command. When oracle home is detached you can manually delete it from windows explorer. IN addition, manual delete without detaching does not cause any problem but leave some annoying pointer in the inventory

The no-beep option causes the mysql command line client not to beep when errors occur. If that's an option you want, it should be in the [mysql] section of your my.cnf. This error suggests that it's in the [client] section of your my.cnf, which causes mysql_upgrade to throw the error since the option isn't recognized. Check your my.cnf and either remove the line or place it in the [mysql] section instead of [client] and you should be good. The [client] option group is read by all client programs (but not by mysqld). This enables you to specify options that apply to all clients. For example, [client] is the perfect group to use to specify the password that you use to connect to the server. (But make sure that the option file is readable and writable only by yourself, so that other people cannot find out your password.) Be sure not to put an option in the [client] group unless it is recognized by all client programs that you use. Programs that do not understand the option quit after displaying an error message if you try to run them. -- http://dev.mysql.com/doc/refman/5.5/en/option-files.html

Oracle 8.x.x has been out of support for some time. Apologies for the bad news, but your only option is to either recover the software from the dead disk, or ask Oracle (obviously with a valid support contract) for a copy of the software. Raise a ticket on My Oracle Support and they will help you.

There are no tools, so to speak. At least not that I am aware. The best thing to do is to test your code, verify your configurations and ensure that SQL Server is functioning optimally. I am hoping that you did this upgrade in a dev or test environment first and that you followed a process with steps that you can repeat again in production. If that's the case, do a full test of your code that interacts with SQL Server. Ensure everything functions as it did before and make sure that all of your maintenance works and that everyone can connect to it at as before. I would also look in your SQL Server Error Logs and see if there are any issues. Same thing with your windows event logs (particularly your system and application event log) I recently gave an answer here that talks a whole lot more about SQL Server Upgrades. Lastly, have you considered what you'll do about DB Compatibility Level? If you haven't, you might want to think about changing that for your databases to SQL 2008 and seeing if all works after a regression test. But please make sure you are in a dev or test. I do not advise just changing this in production, nor do I advise starting with an upgrade in production.

If you are upgrading in place, you shouldn't need to transfer any databases; the instance will retain information on databases. If you are installing a new named instance or installing it fresh on a different server, you have two major options: deatch-and-attach, and backup-and-restore. The detach-attach option is pretty quick: detach the current database using sp_detach_db or in SSMS, right-click on the database and go to Tasks --> Detach. Then, you can cut and paste the database files to their new location. On the new instance, use sp_attach_db or in SSMS, right-click the Databases folder and select "Attach..." from the menu options. The backup and restore option is pretty simple: take a backup of the current database. Then, copy that backup someplace where the new instance can see it, and restore from that backup. You'll have a copy of the current database on the 2008 instance, as well as on the 2005 instance. Here are some considerations: If you need the 2005 database up during this time, use backup-and-restore. The larger the database, the more likely you'd want to detach and attach, especially if this is staying on the same server and you're under a time crunch. Taking backups and restoring from backups can take longer than shuffling bits across the WAN (or, best-case, updating a file pointer in Windows). It also will mean more disk space in use, as backups take up some non-zero amount of space. If you are currently using replication, you can't detach until you disable publishing (as the BOL link above indicates). If you currently have any snapshots of the database, you can't detach until you drop all snapshots. If you don't want to drop those snapshots, go with the backup and restore method.

Really Short Answer - In Place is okay. You can review your configuration afterwards and implement the best practices for SQL Server 2012. A Longer Answer on SQL Server Upgrades/Migrations So this is an opinion thing and there isn't a necessarily wrong or right answer but I prefer migration style upgrades over in-place for a lot of reasons. That being said - some of my clients for various reasons have had no choice but to do an in-place and really since SQL Server 2005, in-place upgrades haven't been as bad as they used to be. Why I Prefer A Migration to an In-Place Upgrade Easier Rollback - If something goes wrong you can rollback by simple saying "we aborted the upgrade.. Please change connection strings to old server while we resolve this". With an in-place you are fixing it or you are down. Refresh Hardware - Hardware changes rapidly. You can easily get stuck on hardware that was right for your company 4 years ago but not right for today and the next four years with an in-place upgrade. You will likely have to do a migration at some point anyway for the new hardware. Feel Better - Sure... This one is subjective, but it feels good knowing you are starting with a new OS installation, a new SQL installation with no cobwebs from the person on the job before you (or you before you knew what you knew today) that could possibly cause you headaches in the future. New OS - A migration gives you a chance to start with a new OS version if you aren't on the latest and greatest today. You Can Test It - Ever want to get a set of baselines on a new machine before you install SQL and cloud it up with databases and usage? You can do that now. Sometimes it is easier to sneak in best practices - Maybe the SQL Server service account was a local admin. Maybe Builtin Administrators is in the SA server role. Maybe things have been sort of hacked together to make it work before. You can fix that all and start fresh. Free test environment and extra sleep - It is a great benefit to have an environment you can work in ahead of the actual cutover day when you make this new environment live. Doing a migration to a new environment means you can build it during business hours, well ahead of your actual cutover day and test it in many ways ahead of time. You can run full regression testing on all applications and systems for days and have a great peace of mind before you actually do the final set of restores/attaches and cutover all applications and access to the new environment. You don't have to do it all at once - A very common situation I bump into is an environment that is trying to consolidate to just a few instances. Perhaps one per version, perhaps one per "tier" and version. A lot of these projects have different timelines for various applications and databases based on testing, project plans and vendor certification timeliness. Doing the migration means you can move those databases that are ready, when they are ready and still handle requests for those databases that can't move for one reason or another. Mind you I am not saying you have to do this as a migration. In-Place works and it works well if you are not planning on the buying new hardware in your budget and can't do that for this upgrade. The support in the upgrade process is so much better than it was in the 6.5 days so you are not putting yourself in a bad position doing this. If you do plan on doing in-place for dev/test but want to do a migration for production you might consider doing at least one migration before production. This way you can work out your checklist ahead of time and deal with any potential issues that you weren't thinking of. Attach/Detach vs. Backup/Restore for Migrations If you decide to go with the migration approach, there is still one more decision you may still have a debate over and that is how you move your database to the new environment. You can either detach your database from the old server and attach it to the new or back it up and restore it there. I prefer backup/restore. The biggest advantage I hear about detach/attach is that it saves some time. For me backup/restore wins for a few reasons: Keep the old accessible - This allows you to still have an accessible database on the source server. detach/attach should do the same, but it will require a few steps and there is room for human error with detach/attach that could complicate this. You are guaranteeing that you have a backup - Instead of just taking a database from a detach and potentially forgetting a backup step, you've made sure that you've taken that backup. Human error - If you delete the wrong file, forget where you are sending something or otherwise mess up your steps, you risk much by moving the data and log files around for your database. Now you can mitigate this by copying instead of cutting (and if you do detach, you should get out of the cut and paste habit) but you could stil mess up. SQL Server is no longer locking those files and it's just too easy to delete a file accidentally for me to risk it. It isn't really that slower - Taking a backup and copying it is a bit more time, but it isn't that much that I am willing to pay the extra risk for it. In fact - using full recovery model and log backups, you can take the downtime down even lower for cutovers as described below in "How to Make the Migration Approach Faster" If you do decide to do the backup/restore - that means your old source database will still be online. I like to bring that database offline after taking the backup. I sometimes go a step further and take the whole SQL instance offline after I've scripted out security, jobs, linked server, certificates, database mail settings, and other instance wide information. This avoids an issue during testing where someone says "Everything looks great!" only to realize a day or two later that they have been talking to the old database on the old server. Taking those databases offline or the whole instance offline allows you to prevent those false positives and the mess they make. How to Make the Migration Approach Faster You can minimize the downtime required for the cutover from an old to new environment for a busy production environment with little downtime by utilizing the full recovery model. Basically - stage the environment you are migrating to by restoring the latest full backup, any differential backups and any already taken log backups specifying NORECOVERY - then all you will have to do for the final cut over is restore the log backups that were not yet restored and the final log backup you wish to restore specifying WITH RECOVERY. This way for a large database, the actual cutover downtime window can be drastically minimized by paying for the cost of the full, differential and most log restores ahead of the downtime window. Thanks to Tao for pointing this out in the comments! How to Make the In-Place Upgrade Safer A few things you can do to improve your experience and results when choosing the in-place approach. Backup - Take appropriate backups of all user and system databases of your environment ahead of time and ensure they are good (I'm paranoid.. I actually would restore them someplace first to really know they are good.. May be wasting your time.. But you may thank yourself in the event of a disaster).. Script out any configuration information about the SQL and OS installation at that environment. Test things well before you start - Verify that you have a good environment and good databases. You should be doing things like looking at the error logs and running DBCC CHECKDB on a regular basis, but before doing an in-place upgrade is a great time to start. Fix any issues ahead of time. Ensure OS health - Don't just make sure that SQL is healthy, make sure your server is healthy. Any gnarly errors in your system or application error event logs? How is your free space? Prepare for the worst - I had a blog post series awhile ago that went on the premise that if you aren't preparing for failure - you are actually preparing to fail.. I still believe that. So think through the issues you may have and deal with them accordingly ahead of time. Get yourself in the "failure" mindset and you will think of things that you wouldn't have otherwise. The Importance of Upgrade or Migration Checklists If you do decide to do an upgrade (whether in place or migration) you should seriously consider creating a checklist and using this checklist in each environment. You should include a bunch of things in this checklist, not the least of which: At the Start - Do some things like perform a test upgrade, test your applications on the latest Database Compatibility level and consider running a tool like the SQL Server Upgrade Advisor ahead of time to see what sort of tasks you need to complete before doing the SQL Server upgrade or migration. Pre Steps - Cleanup, OS tasks, patching ahead of time, preparing applications for the upgrade (clean shutdowns, connection string work), backups, etc. Upgrade/Migration Steps - Everything you have to do for the upgrade or migration to succeed and in the right order. Installation, changing (or not changing depending on your testing and approach) compatibility mode changes to databases, etc. Post Migration/Upgrade Steps - Various tests, post new version or new server configuration options, best practice implementation, security changes, etc. Rollback Steps - All along the way you should have rollback steps and milestones. If you get this far and this happens, what will you do? What are "do a full rollback" criteria? And how do you do that rollback (reverse connection string changes, change back settings, go back to the old version, reinstall if an in place, point back to the old server if a migration, etc.) And then have the person who will be doing the production upgrade follow the checklist in some environment other than production - especially one that closes resembles production if possible ("South of prod", as I say...) and note any issues or points where they had to divert from the checklist or improvise because of a lack in the checklist. Then get the changes merged in and have fun with your production change. I can not over stress the importance of testing thoroughly post migration or upgrade and ahead of your migration enough. Making a rollback decision in the midst of an upgrade should be an easy one - especially during a migration. If there is something uncomfortable, rollback and figure it out if you can't troubleshoot it effectively and reliably in the heat of the migration. Once you are live on this new environment and users connect - rollback becomes a difficult task. You can't restore a SQL Server database to an earlier version. That means manual work and data migrations. I always wait a couple weeks to kill the old environment but you should do all you can to avoid needing that old environment by finding all of your issues before your live users ever touch the new environment. Preferably before you even kick off the upgrade/migration. Quick note about SQL Server Reporting Services migration/upgrade Migrating an SSRS installation isn't quite a herculean task that many think it is. This technet/books online article is actually quite handy. One of the most important admonitions in that article is "Back up the encryption keys" especially if you have a lot of saved sensitive information like scheduled report e-mail recipient e-mail addresses, connection information for a multitude of connections, etc. You can ask one of my clients from awhile back how important that is. They know because I messed that step up and spent quite a lot of time modifying report schedules and connection string permissions.

Ensure you have enough space in / and data dir. Kill all processes for mysql in ps -ef | grep -i mysql If you see any any ibdata file generated under your default data directory you may remove them also iblogfile1,2 since its a fresh installation no need to safe backup them. chown -R mysql:root /var/lib/mysql chmod -R 775 /var/lib/mysql also the same permissions to /etc/my.cnf. Now try to start the instance by issuing /etc/init.d/mysql start and tail -f /var/log/mysqld.log. It should start without any issues if you get any error message .

Advice Never manually apply database changes; use scripts that are in a version control system (VCS). After initial deployment, store the "delta" scripts in the VCS. When upgrading, apply all scripts that are missing. Tracking the scripts that have been applied is a standard problem. Solutions There are tools to automate this task, including: Liquibase Flyway Liquibase We are pretty satisfied with Liquibase, which stores the schema definition in XML files. A commandline tool then applies a "changelog" to the database. The changelog can be applied to all environments: development, test, staging, production, continuous build, etc. Flyway Also consider Flyway, which uses SQL text files with a naming convention. Other Considerations The downside of Liquibase and Flyway is that you basically manage an incremental script. If you need to create a database from scratch, you need to run all change sequentially. Data Modeling Tool Document your data model using an ER Modeling tool, such as: DbSchema TOAD Data Modeler Erwin We use a macro to convert TOAD-based models into a Liquibase changelog. This means we can recreate the database "from scratch" from our model documentation, as well as incremental (Liquibase) scripts that are used to maintain existing installations.