I just installed the mageneto and added my first product. It didn't show up in the font page so I went to inventory on product information and tried to set Stock Availability to in stock but I started getting this error message:
One or more of the Cache Types are invalidated: Blocks HTML output.
Click here to go to Cache Management and refresh cache types..
I did this several times, logged and tried again but it appear every time I try to change Stock Availability.
How do I fix this?
Googling I fond that's a common issue on mageneto and found this exntension and installed following this instructions but it didn't work either.
Step:01
System==> Index Management==>Select All ==>Actions(Reindex)==>Submit
Step:02
You may delete cache directory contain all file
magento directory\var\cache\
Step:03
Another way You may clean database log table
#Must Be take Backup before do it:
TRUNCATE TABLE dataflow_batch_export;
TRUNCATE TABLE dataflow_batch_import;
TRUNCATE TABLE log_customer;
TRUNCATE TABLE log_quote;
TRUNCATE TABLE log_summary;
TRUNCATE TABLE log_summary_type;
TRUNCATE TABLE log_url;
TRUNCATE TABLE log_url_info;
TRUNCATE TABLE log_visitor;
TRUNCATE TABLE log_visitor_info;
TRUNCATE TABLE log_visitor_online;
TRUNCATE TABLE report_event;
TRUNCATE TABLE log_customer;
TRUNCATE TABLE log_quote;
In my case I had to flush the cache and after that it was fine.cache error screen
flushed cache error screen
Related
I'm using user_tab_modifications table to monitor all my table's change in DB, but sometimes the records disappeared.
For example, I updated the data in table A, and ran the following SQL to flush the table user_tab_modifications so that I can see the latest information there.
exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;
Then
SELECT * FROM USER_TAB_MODIFICATIONS;
So I can see the record about table A in there.
But then I found the record about table A disappeared after about 1 minute even though I didn't do anything in Oracle.
(other records in user_tab_modifications do not change. No problems)
That's why and can I do some settings to change it (make sure the records there will not disappear)? Thank you.
From the documentation:
USER_TAB_MODIFICATIONS describes modifications to all tables owned by the current user that have been modified since the last time statistics were gathered on the tables.
You might want to check if some stat gathering process was running in the background on the concerned table between the time when the changes were done and when you saw the stat record disappear.
The documentation is clear about how to purge an Oracle AQ:
dbms_aqadm.purge_queue_table()
However, what happens to the storage, especially the high water marks of the queue table, the indexes and of the LOB segments? Is it necessary to shrink the table, too?
In production, the queues are nearly always empty (as they should), but in our test system, they fill up to millions of rows for various reasons, so they need to be emptied sometimes.
Is it neccessary to look at the underlying tables and indexes or is this taken care of automatically?
Many thanks!
DBMS_AQADM.PURGE_QUEUE_TABLE it is equivalent for truncate table. Also look at this error message when you try truncate queue table
ORA-24005: Inappropriate utilities used to perform DDL on AQ table %s.%s
*Cause: An attempt was made to use the SQL command DROP TABLE or TRUNCATE
TABLE or ALTER TABLE on queue metadata or tables.
*Action: Use the DBMS_AQADM.DROP_QUEUE_TABLE to DROP TABLE,
DBMS_AQADM.PURGE_QUEUE_TABLE to TRUNCATE TABLE.
ALTER TABLE redefinition based on only ALTER_TABLE_PROPERTIES and
ALTER_TABLE_PARTITIONING clauses are allowed.
Tom Kyte has already written info about often truncating table https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:47911859692542
One of the tables in my db has to be updated daily. A web server actively queries this table every 5 seconds. Now I can't simply UPDATE the table rows because of some constraints, so I need to clear all the rows and repopulate the table. How can I safely do this without affecting the functioning of web server?
The repopulation is done by an other web service isolated from the web server. I am using Spring framework.
The table has approx. 170k rows and 5 columns.
Truncate and re-populate the table in a single transaction. The truncate isn't visible to concurrent readers, who continue to see the old data. Correction per #AlexanderEmelianov and the docs:
TRUNCATE is not MVCC-safe. After truncation, the table will appear empty to concurrent transactions, if they are using a snapshot taken before the truncation occurred. See Section 13.5 for more details.
so after the TRUNCATEing txn commits , concurrent txns started before the TRUNCATE will see the table as empty.
Any transaction attempting to write to the table after it's truncated will wait until the transaction doing the truncate either commits or rolls back.
BEGIN;
TRUNCATE TABLE my_table;
INSERT INTO my_table (blah) VALUES (blah), (blah), (blah);
COMMIT;
You can COPY instead of INSERT too. Anything in a normal transaction.
Even better, there's an optimisation in PostgreSQL that makes populating a table after a truncate faster than if you do it otherwise.
I have this website http://www.hageredskap.no. If you try to add any product to cart, you will see it automatically adds one more random product. This only happens at the first add to cart action, not after that.(so you can clear cookie to try again). In admin, these products have no connection. no related, crossell or upsell. Each time it random adds one different product, usually out of stock ones.
So far, what i have tried :
- Disabled all 3rd extensions, all keep core Magento
- Change template to RWD (default)
But it still happens.
I want to hear your theories, please. What might cause this super strange issue? This site has been upgraded from Magento 1.5 to 1.9.1 but i don't remember if this ever happened before upgrading.
I find out the solution, just truncate those quote tables
SET FOREIGN_KEY_CHECKS=0;
truncate sales_flat_quote;
truncate sales_flat_quote_address;
truncate sales_flat_quote_shipping_rate;
truncate sales_flat_quote_address_item;
truncate sales_flat_quote_item;
truncate sales_flat_quote_item_option;
truncate sales_flat_quote_payment;
SET FOREIGN_KEY_CHECKS=1;
Had the same situation with Magento 2.3.3
This solution works on Magento 2. Just need to change table names accordingly.
SET FOREIGN_KEY_CHECKS = 0;
TRUNCATE TABLE `quote_address`;
TRUNCATE TABLE `quote`;
TRUNCATE TABLE `quote_address_item`;
TRUNCATE TABLE `quote_id_mask`;
TRUNCATE TABLE `quote_item`;
TRUNCATE TABLE `quote_item_option`;
TRUNCATE TABLE `quote_payment`;
TRUNCATE TABLE `quote_shipping_rate`;
SET FOREIGN_KEY_CHECKS = 1;
The SQL command TRUNCATE in Oracle is faster than than DELETE FROM table; in that the TRUNATE comand first drops the specified table in it's entirely and then creates a new table with same structure (clarification may require in case I may be wrong). Since TRUNCATE is a part of DDL it implicitly issues COMMIT before being executed and after the completion of execution. If such is a case then, the table that is dropped by the TRUNCATE command is lost permanently with it's entire structure in the data dictionary. In such a scenario, how is the TRUNCATE command able to drop first the table and recreate the same with the same structure?
(Note that I work for Sybase in SQL Anywhere engineering and my answer comes from my knowledge of how truncate is implemented there, but I imagine it's similar in Oracle as well.)
I don't believe the table is actually dropped and re-created; the contents are simply thrown away. This is much faster than delete from <table> because no triggers need to be executed, and rather than deleting a row at a time (both from the table and the indexes), the server can simply throw away all pages that contain rows for that table and any indexes.
I thought a truncate (amoungst other things) simply reset the High Water Mark.
see: http://download.oracle.com/docs/cd/E11882_01/server.112/e17118/statements_10007.htm#SQLRF01707
however in
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:2816964500346433991
It is clear that the data segment changes after a truncate.