Tag Info

New answers tagged

0

Once you create table use query below yo add first 10 records into table * job_history INSERT INTO job_history VALUES (102, '19930113', '19980724', 'IT_PROG', 60), (101, '19890921', '19931027', 'AC_ACCOUNT', 111), (103, '19931028', '19970315', 'AC_MGR', 110), (201, '19960217', '19991219', 'MK_REP', 20), (114, '19980324', '19991231', 'ST_CLERK', 51), ...


0

Roland's ideas are good. Also Turn off the query_cache; it is unused overhead. (_type=0, _size=0) Batch size of 10 is probably good. How big are the BLOBs/TEXTs? How much data is there? Sounds like terabytes? To simply read and write terabytes takes hours -- just for the disk I/O. (So 40 hours may be reasonable.) comment out log-bin (no use writing a ...


1

InnoDB Architecture (from Percona CTO Vadim Tkachenko) What are the values recommended for the batch insert size, considering the size of the columns (longtext, longblob)? Increase innodb_log_buffer_size to 256M Increase innodb_log_file_size to 2G I wrote about increasing these to accommodate TEXT/BLOB fields in the past Apr 20, 2011 : MySQL ...


0

Your statement runs in a transaction. If there is not already a transaction open, a transaction is created just for this statement and automatically committed at the end if the statement succeeds. If the statement encounters an error, the transaction is rolled back automatically, so it has no effect. Either the whole statement takes effect or none of it ...


0

I like simply catching the unique_violation exception as proposed here: Optimal way to ignore duplicate inserts? Ignore Duplicates #1 Create a transaction that catches unique constraint violations, taking no action: BEGIN INSERT INTO db_table (tbl_column) VALUES (v_tbl_column); EXCEPTION WHEN unique_violation THEN -- Ignore duplicate ...


1

Create a set of staging tables in the target database. Write rows to these as they are generated, which seems to be one or two at a time. This can be inside a transaction. Once the whole batch (200 rows?) is in these staging tables use a stored procedure in the target database to move them en masse from the staging tables to the real ones.


1

I've seen similar problems addressed by decoupling the app from the central server: Remote sites install a local SQL Server Express along with the app Apps talk to the local Express instance. Low latency, good availability. SQL Server Express uses Service Broker to deliver the updates to the central server Service Broker handles the network availability, ...


0

The answer for this simple case is Yes. Rows are inserted in the provided order in the VALUES expression. But this is an implementation detail and there are no guarantees. In particular, the order is not necessarily maintained in more complex queries with WHERE conditions or joins. And there is no order in a database table. Physical order of rows may change ...



Top 50 recent answers are included