Ping !! :)
On Mon, Sep 1, 2014 at 8:27 AM, Ajay Garg ajaygargn...@gmail.com wrote:
Hi all.
We have replication set-up, where we cater to HUUGEE amounts of data.
Since quite some time, we have been facing issues wherein the slave
lags behind master quite a lot.
So, yesterday we were able
Dear Akshay,
ASFIK, normal selects are always non-locking read and they do not put any
locks.
Select..., Select..where..,Select where..between
Does above select statement will use next-key locking and/or gap locking?
I dont think so.
Please correct me if I am wrong.
Could you please put some more light on it?
Best Regards,
Geetanjali Mehra
Senior Oracle and MySQL DBA Corporate Trainer and Database Security
Specialist
On Thu, Aug 28, 2014 at 2:09 AM, shawn l.green shawn.l.gr...@oracle.com
wrote:
Hello Geetanjali,
On 8/26/2014 1:16 AM, geetanjali mehra
Hi Geetanjali,
It seems, you are confused with gap locking. Can you tell if there is a
record with value 12 and 17 in the new table?
Select count(*) from new where c1 = 17;
AFAIK, if you run this query Select * from new where c1 between 12 and 17
for update; and if you don't have value 17 in the
Thanks Akshay for the reply.
On Tue, Sep 2, 2014 at 12:25 PM, Akshay Suryavanshi
akshay.suryavansh...@gmail.com wrote:
Hello Ajay,
I tried testing the slave-parallel-workers few months ago, what I can surely
tell you its still under development, and at that time needed some critical
bug
Hello Geetanjali,
Apologies if I have confused you with the normal Select notation. I meant
to write with repeatable-read mode in mind, but looks like that is not an
issue, since you already tested this scenario with that isolation mode.
Moving further to the original issue.
Do you have an
SET @tz=@@session.time_zone ;
SET SESSION time_zone = '+0:00' ;
SELECT DATE_FORMAT(
FROM_UNIXTIME(1409304102.153) /*your epoch column here*/
,'%Y-%m-%d %a %H:%i:%s.%f GMT');
SET SESSION time_zone = @tz ;
2014-08-29 Fri 09:21:42.153000 GMT
(or)
SELECT DATE_FORMAT(
