how do I import an sql file using the command line in mysql

27. Juli 2021 at 18:35

A common use of mysqldump is for making a backup of an entire database:

shell> mysqldump db_name > backup-file.sql

You can load the dump file back into the server like this:

UNIX

shell> mysql db_name < backup-file.sql shell> zcat myfile.sql.gz | mysql -u root -ppassword mydb

The same in Windows command prompt:

mysql -p -u [user] [database] < backup-file.sql

Windows PowerShell

C:> cmd.exe /c "mysql -u root -p db_name < backup-file.sql"

MySQL command line

mysql> use db_name;
mysql> source backup-file.sql;

Please share this article von facebook & google plus or where you want, thank you!

Magento MySQL Database Error: MySQL server has gone away

7. Oktober 2015 at 15:51

sql-statement-mysql

If you get an exception error like this in the Magento Exception-Log-File:

ERR (3): exception ‚PDOException‘ with message ‚SQLSTATE[HY000]: General error: 2006 MySQL server has gone away‘ in …/lib/Zend/Db/Statement/Pdo.php:228 Stack trace:

Explanation: It is clearly visible that this is the MySQL timeout error. When you are using shared hosting and you get the huge traffic, so in this case a huge requests sends to MySQL and your request wait for a long time and finally timeout. Another case, If there is one DB connection and fetch some data from DB and do some stuff longer than DB timeout and now if you try to fetch data with same connection you will get the error MySQL server has gone away.

Solutions: You should use dedicated hosting if you are getting a huge traffic to your website instead of shared hosting. Secondly, you should close the DB connection after fetching data and create new DB connection to fetch data again and close the DB connection. If the problem remain same then you need to increase wait_timeout, connect_timeout and max_allowed_packet in my.ini or my.cnf file.

I have changed my my.ini settings as below:
max_allowed_packet = 32M
wait_timeout = 1800
connect_timeout = 120

To change these in your mysql’s my.cnf/my.ini configuration file follow below steps:
For windows: open mysql-install-dir/bin/my.ini and set wait_timeout = 1800 , max_allowed_packet = 32M and connect_timeout = 120 then save and restart mysql server.

For Linux: open /etc/mysql/my.cnf and set wait_timeout = 1800 , max_allowed_packet = 32M and connect_timeout = 120 then save and restart mysql server.

This solution solved my problem of SQLSTATE[HY000]: General error: 2006 MySQL server has gone away.

Please share this article von facebook & google plus or where you want, thank you!

Magento: Move Database Sales, Customers & Invoices

11. Mai 2015 at 16:07

sql-statement-mysql

Disabling Magento during Transfer

First disable magento in the transfer time.
create a blank file named maintenance.flag and place it on the root of your Magento install.

Transferring Customers & Sales

The first step is to transfer all the tables and data starting with „customer_“ and „sales_“, which are as follows on a Magento 1.7.0.2 – 1.9.0.1 install:

‚customer_address_entity‘
‚customer_address_entity_datetime‘
‚customer_address_entity_decimal‘
‚customer_address_entity_int‘
‚customer_address_entity_text‘
‚customer_address_entity_varchar‘
‚customer_eav_attribute‘
‚customer_eav_attribute_website‘
‚customer_entity‘
‚customer_entity_datetime‘
‚customer_entity_decimal‘
‚customer_entity_int‘
‚customer_entity_text‘
‚customer_entity_varchar‘
‚customer_form_attribute‘
‚customer_group‘

 And now export the data from the „sales_“ tables:

„sales_bestsellers_aggregated_daily“
„sales_bestsellers_aggregated_monthly“
„sales_bestsellers_aggregated_yearly“
„sales_billing_agreement“
„sales_billing_agreement_order“
„sales_flat_creditmemo“
„sales_flat_creditmemo_comment“
„sales_flat_creditmemo_grid“
„sales_flat_creditmemo_item“
„sales_flat_invoice“
„sales_flat_invoice_comment“
„sales_flat_invoice_grid“
„sales_flat_invoice_item“
„sales_flat_order“
„sales_flat_order_address“
„sales_flat_order_grid“
„sales_flat_order_item“
„sales_flat_order_payment“
„sales_flat_order_status_history“
„sales_flat_quote“
„sales_flat_quote_address“
„sales_flat_quote_address_item“
„sales_flat_quote_item“
„sales_flat_quote_item_option“
„sales_flat_quote_payment“
„sales_flat_quote_shipping_rate“
„sales_flat_shipment“
„sales_flat_shipment_comment“
„sales_flat_shipment_grid“
„sales_flat_shipment_item“
„sales_flat_shipment_track“
„sales_invoiced_aggregated“
„sales_invoiced_aggregated_order“
„sales_order_aggregated_created“
„sales_order_aggregated_updated“
„sales_order_status“
„sales_order_status_label“
„sales_order_status_state“
„sales_order_tax“
„sales_order_tax_item“
„sales_payment_transaction“
„sales_recurring_profile“
„sales_recurring_profile_order“
„sales_refunded_aggregated“
„sales_refunded_aggregated_order“
„sales_shipping_aggregated“
„sales_shipping_aggregated_order“
„salesrule“
„salesrule_coupon“
„salesrule_coupon_usage“
„salesrule_customer“
„salesrule_customer_group“
„salesrule_label“
„salesrule_product_attribute“
„salesrule_website“

Change Last Order ID for Sales

Next, a step that is fairly easy, but that is often missed is the changing of the last entity ID for orders, invoices, credit memos and shipments. Otherwise, Magento will ignore the sales data that did not exist prior to the transfer.
For example: Imagine a Magento store has 9 orders (both development and production), the last orders‘ id would probably be 100000009.

During development, your production website acquires 3 additional orders (a total of 12 orders).

After moving your live sites‘ sales_ tables, your development site will reflect the 12 orders correctly, but will still count from 9, instead of 12.

Hence, the next order will have an ID of 100000010 instead of 100000013, unless the last order ID is updated. The same applies for invoices, shipping and credit memos.

The fix is simple! Simply edit the table eav_entity_store and update the increment_last_id column with the last id used for each row. Each rows‘ entity type can be found in the table eav_entity_type. Default the entity types in Magento are:

    5 = order
    6 = invoice
    7 = creditmemo
    8 = shipment

That should be all that’s needed for a simple customer and sales update on two, otherwise identical Magento 1.7.0.2 – 1.9.0.1 sites.

Please share this article von facebook & google plus or where you want, thank you!

MySQL Query Sammlung / MySQL Query Library

8. April 2015 at 17:34

sql-statement-mysql

Some MySQL Querys which you need by the programming with php / mysql or  magento:

MySQL Update with sub-select: Update a value of an option, e.g. „price“, where option-name is like „optionname“

UPDATE catalog_product_option_type_price t1
SET t1.price='30'
WHERE t1.option_type_id in (SELECT option_type_id FROM catalog_product_option_type_title WHERE `title` like '%optionname%');

Other example with an own table where are not all product_id’s imported and must be updated by sku

UPDATE mypharmacy_stock_statistical_data t2,
(   SELECT entity_id,sku
    FROM catalog_product_entity
) t1
SET t2.product_id = t1.entity_id
WHERE t1.sku=t2.sku

Please share this article von facebook & google plus or where you want, thank you!

MySQL: Doppelte Datensätze finden

6. Februar 2014 at 17:44

Ihr müsste doppelte Datensätze innerhalb einer MySQL-Tabelle finden?

Das folgende SQL-Query hilft euch dabei (in spalte 1 werden doppelte Datensätze gesucht):

<code>SELECT COUNT(*) AS COUNT, spalte1, spalte2 FROM tabelle
GROUP BY spalte1 HAVING COUNT(*)>1;
</code>

Wenn euch der Tipp geholfen hat, bitte diesen Artikel auch bei Google+ und Facebook teilen, danke für euren Support!

Mysql: ibdata zu groß – Daten aufteilen mit „innodb_file_per_table“

8. Januar 2013 at 11:17

Per Standard Konfiguration des mySql-Servers, werden alle Daten aus allen Datenbanken, in eine einzige Datei Namens „ibdata“ im mysql-data-ordner geschrieben. Diese Datei wächst kontinuierlich, auch beim löschen von Datenbanken bleibt die Größe erhalten (schrumpfen nicht möglich).

In der Praxis ist das nicht gerade optimal, lösen könnt ihr dieses Problem durch hinzufügen des Eintrages „innodb_file_per_table“ in der my.ini bzw. my.cnf im [mysqld]-Abschnitt der Konfigurations-Datei. Danach werden (Server-Neustart) jeweils pro Datenbank entsprechende ibdata-files angelegt, diese können dann auch beim löschen einer Datenbank mit gelöscht werden.

Magento / Import in MySQL 5.0 – USING BTREE Error

19. November 2010 at 17:22

Wenn ihr ein MySQL-Datenbank-Dump in eine MySQL 5.0 importieren möchtet welche mit mysqldump auf einer 5.1 erzeugt wurde, dann bekommt ihr höchstwahrscheinlich eine Fehlermeldung wie die folgende:

Der Grund ist dass die key syntax von 5.0 auf 5.1 wie folgt geändert wurde:
mysql50
UNIQUE KEY IDX_BASE( entity_type_id, entity_id, attribute_id, store_id ) USING BTREE,
mysql51
UNIQUE KEY IDX_BASE USING BTREE ( entity_type_id, entity_id, attribute_id, store_id ),

Leider gibt es kein aktuellen Kompatabilitäts-Modus like –comptability=mysql50 in mysqldump.
Es kann zwar mysqldump –comptability=mysql40 benutzt werden, allerdings auf eigene Gefahr 😉

Mit dem folgenden Befehl könnt ihr in der Bash den dump vor dem Import bereinigen (benutzt das consolen-programm „sed“):

sed -i -r 's/\(([^)]+)\) USING BTREE/USING BTREE (\1)/g' magento.sql

MySQL Backup schneller importieren

24. August 2010 at 18:08

Problem

Falls ihr größere Backups habt, welche z.B. mit mysqldump erstellt wurden, so kann der komplette Import schon mal einige Minuten dauern.  Was die Meisten nicht wissen ist, dass der Import solcher mit mysqldump erstellten Backup Dateien viel länger dauert.

How Can I Speed Up This Process?

Bei setzen der folgenden Flags vor dem Import im Datenbank Dump, kann die Importzeit dramatisch verkürzt werden:

SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;

Wenn der auto-commit deaktiviert wurde muss am Ende ein manueller commit erfolgen:

COMMIT;

Durch deaktivieren der unique checks und foreign key kann einiges an Geschwindigkeit heraus geholt werden.

Mit dem folgenden Bash-Script könnt ihr das Szenario automatisieren:

#!/bin/bash
echo "SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;" > backup.sql
mysqldump -u myuser --password=mypassword mydatabase >> backup.sql
echo "COMMIT;" >> backup.sql

MySQL Datenbank Import ERROR 2006 (HY000) – MySQL Server has gone away – Lösung

1. Juli 2010 at 16:56

Wenn ihr beim Import eines MySQL-Datenbank-Dumps folgende Fehlermeldung erhaltet:

ERROR 2006 (HY000) at line XXX: MySQL server has gone away

dann könnt ihr das durch setzen der „max_allowed_packet = 1M“ von 1MB zu „max_allowed_packet = 32M“ lösen.
und zwar unter dem Abschnitt mysqld in der my.ini, also:

[mysqld]
max_allowed_packet=32M

Reverse Engineering mit MySQL Workbench MySQL Workbench

23. Dezember 2009 at 09:45

Zur grafisch Erstellung einer MySQL Datenbanken wird das kostenlose Programm MySQL Workbench bereit gestellt. Ebenfalls ist Reverse Engineering möglich, ihr könnt ein Datenbankmodel aus einer bestehenden Datenbank Tabelle generieren und editieren.

Ihr habt bereits eine Tabelle die ihr anpassen möchtet? Kein Problem, neben dem editieren um z.B. Erweiterung einzubauen, könnt ihr Fremdschlüsseln zuweisen. Nach dem laden der Datenbank habt ihr sofort euer Datenbankmodel und könnt dieses Bequem mit einer grafischen Oberfläche erweitern. Die Fremdschlüssel werden so gar automatisch durch das Setzen von Verbindungen generiert.

MySQL Workbench